Naming Software Teams

Forming a new software team is easy to get wrong in many ways, including:

• Making a B team
• Making a low context team

Here, however, we’ll focus on one of the most important and often bungled aspects of team formation - the team name.

Let’s review how to avoid the common trap of naming teams poorly.

What’s In A Name?

Let’s assume that you have a team with a good mission (this talk is good inspiration for crafting high-quality team missions).

Now you’re ready to name the new team, which is when things commonly go awry. Even if you have a great team mission, you can shoot yourself in the foot with the name.A strong name:

• Blocks mission creep
• Lets 80% of the org route 95% of questions the right way, instantly

Names Imply Mission

Names are sticky. Missions live in docs nobody reads; names live in brains.

It is incredibly easy for a broad team name to lead to mission expansion down the line. When asked if it is appropriate to upscope a team’s mission, people always say “well we are the _____ team after all!”

People often mildly upscope their name to be more ambitious than their mission. Then, over time two teams who have upscoped their mission end up believing they both own some hot new area of technology.

Then people fight viciously.

A good team name doesn’t overlap with any other team and doesn’t allow for major upscoping of ownership.

Team Names Are Routers

People in large organizations burn thousands of hours just finding the right Slack channel to get answers they need. Asking questions to the proper team, finding the right people for projects and incidents, and all other routing activities are a massively expensive set of endeavors when compounded over hundreds or thousands of people. If a team is named properly, you can create major efficiency every time someone needs to figure out who owns what.

There are a couple big failures in team naming as it pertains to routing:

• Ambiguous names leave everyone unsure. This leads to inefficiency, hot-potatoing of questions, and the team often being left out of conversations. e.g. The Blue Team gets mad when people don’t bring them into the Redis conversations. They own redis gosh darnett! Well, they’re named the Blue Team so who the heck would know.
• Overly broad names make people throw everything at you. If you name yourself something like “The Platform Team”, don’t be surprised when literally every possible question and everything that other people don’t want to do gets sent your way.

Examples

Let’s make these ideas real with an example. Let’s create a fake team that has the following properties:

• Its core mission is to own a vertical slice of functionality of Widget A
• It owns areas B and C that are tiny frontend infrastructure libraries and have nothing to do with its core mission.

Here are good and bad team names.

Bad

• “Widgets” — another team owns a widget. Turf war in 3…2…
• “Frontend Experience” — congrats, you now own every pixel that nobody else wants.

Good

• “Widget A” — crystal clear. B and C routing is a rounding error.
• “ABC” — if you must, but brevity beats cleverness.

Final Thoughts

Teams often want to avoid tightly scoped team names so they can expand in the future. They’ll also claim that it allows them to think more broadly about a problem space. However, in general:

• You can always expand a team name in the future. Having a name change as a requirement for team mission expansion prevents unintentional scope creep.
• Many teams regret making their scope too broad from the start, because they find they can’t accomplish that scope but they get all the accompanying support and questions.
• People that are going to think broadly are mostly going to do it anyway.

Team names are contracts that define who does what. Getting them right up front is an incredibly important piece of scaling software organizations.