Team identity is the first place a team takes ownership. Everything else about a team can be handed to it (the goals, the problem, the people, the place in the org chart), but the identity is the one thing the team can claim for itself. Choosing a name is the first step into taking your destiny into your own hands and starting to take care of your own. It is the first thing that creates a sense of belonging, and it is so often ignored even though it is such a multiplier. The thing to understand up front is that belonging cannot be dictated. A sense of being part of the team has to be adopted, not assigned. It has to be organic. The rest of this post is about how that ownership gets built, and why it has to stay local to work.

My path ran the opposite way from most people's: I started in open source before I ever took a full-time software engineering role. The first thing I noticed in open source was that nobody there talks about a "team." They talk about a community. When I was deep in the Swift world, we even tried to give ourselves a name: Swifties. It never really stuck (people kept trying, and there were always jokes about how it borrowed from a certain pop star's fan base). But the attempt is the interesting part. We had a common language, a common set of rules, and a common way of communicating (the forums, the GitHub issues). The community was the team, and the glue showed up on its own. Everyone was already there because they liked the thing.

When I later started working full time as an engineer, the word "team" meant something completely different. Inside a big company you get an org, and that org has sub-orgs, and those have sub-sub-orgs, all arranged by the reporting structure. At the bottom of that tree is your team, which usually means the group of people who report to the same person (sometimes it means a group that shares a common skip-level instead). The container looks similar to a community, but the thing that brought everyone together is not the same. You are not gathered around a shared love of the work. You are gathered around a problem someone needs solved.

From Community to Team

A company team is problem-and-solution based. You are handed a set of goals and asked to go solve them, and most of the time you do not get to choose who you solve them with. You can occasionally move teams, but you rarely get to assemble one. So you can wake up one day surrounded by people who do not have much in common with you. They may not like the same language. They may not think the same way. And that is fine. But it means the cohesion that open source gets for free is something you now have to build on purpose.

That part is genuinely hard, and how hard it is depends a lot on the style of the company and the org you sit in. Like it or not, every organization rewards some functions more than others, and a lot of the time the best thing to do is not the best rewarded thing to do. The two often line up, because aligning them usually makes sense, but they do not line up all the time. So you are trying to forge a group out of people who did not pick each other, working toward goals they did not choose, inside a system that does not always reward the right move. That is the situation. The question is how you create an identity strong enough to hold up inside it.

In open source the identity is easy because you are already attracted to the work. Inside a company you are being paid to do something that may or may not be exciting on its own. So the first job is to make it exciting, and I think that starts with the team deciding it has an identity at all.

Start With a Name

Build the identity together, regardless of what you have been assigned to work on. The single most useful move is to let the team call itself something it actually likes, rather than wearing the label that got handed down from above. Having your own name helps more than people expect, especially when the name is something specific and a little bit yours. It is hard to rally around the "software update team," or the "networking team," or the "compute team," or the "tools team," or the "support team." Those are descriptions of a function, not an identity. Nobody feels anything when they say them out loud.

A name you chose is different. It is the first artifact the team makes together, and it signals that this group is a thing, not just a row in an org chart. It costs nothing and it gives people something to belong to before any of the hard work has even started.

Write Down How You Work

The next layer is a way-of-work document: a plain description of the mechanical things, how you actually do work day to day. How do you track work? Where do the artifacts live, and how do you create them? What are the small, ordinary routines that a new person would need to learn in their first week? Write those down. Keep it a living document and update it as the team changes. It sounds bureaucratic, but it does real work for alignment and cohesion, because it turns "how we do things here" from folklore into something you can point at.

You can go one step further and write an alignment document, or a short set of principles the team believes in. Most companies already have principles, and the ones handed down from above tend to get espoused and then quietly ignored. The homegrown ones are the ones that stick. On a team I was on, one principle was that a design document is simply something you always write (that one came from above, but we adopted it). Another was that each person sits on a single on-call rotation, never two or three. That second one matters more than it looks: a single rotation can be planned around and kept at a sane level, while stacking two or three rotations on one person quietly means they are effectively always on call. There are dozens of principles like that, and the value is not in the list, it is in the fact that the team forged the list together. That is part of the identity, and it has to be built as you go, not received.

Keep It Local

The most important thing about a team identity is that it has to be local. It cannot be a remote identity, the kind where leadership tells hundreds of people "we are all one big team." The human mind does not wrap itself around hundreds of people. The two-pizza rule applies here for a reason: an identity is something a small group can actually feel, and it falls apart at scale. Yes, you still need some alignment on what the larger org is doing and where it is headed, and that direction has to exist. But the thing worth striving for, the thing that becomes a real multiplier, is the local identity of the small group you sit with.

Team identity is the foundation you build everything else on. In open source it arrives for free, carried in on the shared interest that brought everyone together. Inside a company you have to make it yourself: pick a name you like, write down how you work, agree on the few principles you actually believe in, and keep all of it local enough that the people on the team can feel it. That is the part I would fight for.