What's in a name?

Picture this. You’ve just joined a new company as a manager. You’re inheriting a team.

Your first day finds you getting the lay of the land, surveying your organizational structure, trying to understand how your adopted team fits into the big picture. The org chart seems pretty straightforward. Lines are drawn along familiar divisions, territorial ownership proclaimed through self-evident monikers that are reminiscent of heraldic titles. The Backend Team. The Frontend Team. Devops! Finance! Sales! The Middle Eastern Global Partnerships and Strategy Team! ^{wait for the fanfare…}

And there at the bottom, your own fiefdom of plucky and endearing misfits: The Security Team. Struggling valiantly to vanquish insecurity wherever it may rear its ugly head.

Ah yes. You nod your head sagely. This makes sense, you think. I now know our place in the realm; our duty is clear. Then a glimmer of doubt.

Do you? Is it?

Team names are powerful and subtle. They’re present in everyday conversations around the office, and they’re one of the first things a prospective hire sees upon reading your job posting. Within and without, they’re a tool of identity. You belong to a team. No, not just any team. That team.

When your team was formed, someone made a decision on what to call it. They had to, or someone else (or worse, multiple someone elses with conflicting ideas) would have decided for them. Absent anything to the contrary, a name like “John’s team” might become the official name de facto.

A growing organization will go through a natural progression of team naming conventions.

First, there is just the founder or founders. A single team, whose name is simply the company’s name.

A few hires later and teams begin to form around separate concerns. The team is still small enough and the product still in too much flux to allow for discrete chunks of identity among the mess of half-baked features and experiments. Everybody works together on all the things. So identity is refined from other sources, usually by grouping people by the type of work they typically do. The Backend, Frontend, Design, and Business teams begin to form.

After a certain point, the product matures into several closely related features. The people who built each feature continue to work on that feature and hire more people to help them. Stratified, job-based team names don’t really mesh with how people are actually organizing and discussing themselves or their work. So the structure moves towards a feature-based naming scheme. Enter “The Payments Team,” or your own Security outfit.

It’s a natural, evolving progression that meets the needs of the company at each stage. It works. Yet with just a bit more intentionality when we choose a name for our team, we can harness the inherent value of identity to also drive purpose.

Consider a name like “The Payments Team.” It conveys identity, sure. It may even suggest the types of features the members of the team will likely work on. But it doesn’t inspire. When someone says they work on The Payments Team, you learn nothing about what drives that group of people, what they’re hoping to accomplish, or what pride they take in their work.

Instead, imagine if the person naming the team had decided upon “The Payment Accuracy Team.” Subtle, right? What do members of this team care about? You can’t miss it, it’s right there in the name: They care about ensuring that the payments are accurate. Identity and purpose, expressed together as one and the same.

Notice that going from “Payments” to “Payments Accuracy” implies a narrowing of scope. That’s a good thing. While a Payments team could work on all things payments – speed, accuracy, auditability – can they truly focus on all of them at the same time?

For all the fretting we do as managers, wondering whether we’re doing enough to keep our team aligned, what if we co-opted every mention of our team’s name as an opportunity to align on our goals? Every mention of the team’s name could also be an affirmation of its reason for existing. It’s an aspirational call to its members, and a badge of honor to others in the company.

The cause-effect relationship between values and identity is a lot more fluid than we might have previously thought. What we decide to call ourselves can have a profound impact on what we believe. Why not take advantage of that powerful effect to drive progress, especially since the act of naming a team is so trivial?

Going back to your first day as the new team lead. Your manager comes up to you asking you to put together a presentation for the rest of the kingdom.

“Hey, could you put together the Security Team’s roadmap for the next quarter to present to the company?”

Or,

“Hey, could you put together the Trust and Safety Team’s roadmap for the next quarter to present to the company?”

Which team would you rather be a part of?

Dan Applegate is a software engineering manager living in Brooklyn. Connect with him on LinkedIn.