Why weird team names make sense

I've managed teams named, among other things, Python-Brug, and Banpo. Named for bridges in different cities, while we worked on a product named Bridge. A lot of people look at those names and think, why name teams after bridges? Why name them at all? And if you are going to name them, why not name them something logical?

First, let's remember that naming things is hard. Very hard.

Second, let's think about what a name is, and why it might make sense to have names that don't make sense.

The initial inclination would be to name teams after the thing that they work on or maintain. Not a bad inclination, but one that quickly falls apart in the face of the realities of fast moving organizations and rapidly shifting architectures. For example, if you name a team "The Payments Team", you need to be confident that, 1) they will always own the payment system 2) that they won't own anything else of significance 3) that the payments system will only be owned by them and 4) that all of the previous three things will be largely static into the future.

For me the uncertainty around at least number 4 makes me reach for names as a layer of abstraction on top of what teams do. Python-Brug might own payments today, but if they also need to own session management or authentication, not a problem. It's easy to say "Oh yeah... sessions are owned by Python-Brug" and less easy to say "Oh yeah... sessions are owned by the Payments Team". The second one starts to codify seemingly architectural decisions, while the first doesn't. It acknowledges that sessions and payments are only related in that they are owned by the same team.

Abstractions, drawn carefully, can be extremely useful in organization design, as well as software design.

Third, fun names impact team culture positively.

I want to just write "yep" here. That doesn't really help the conversation though so here is a more substantive discussion.

Fun names are a reinforcement of team identity. That identity is aided by things like, team specific swag, slack emojis for the team name, and more. In research on mimicry and it's role in building trust Alexa S.Clerke and Erin A. Heery found that, "people trust others more when they are highly objectively similar and when they engage in high levels of mimicry, meaning that both variables are likely to be important precursors to the feelings of trust that underpin relationship development."

While team identity, expressed in logos and other ephemera, is not the be-all-end-all of mimicry and trust building, having a shared set of icons would seem to reinforce trust building according to their research. Building trusting teams is critical to getting the work of software engineering done.

On top of that Guy Winch points out that there are additional benefits to the belonging to a group with a strong identity. These include common purpose, support, reduced loneliness, and greater resilience. All of which are critical to high functioning teams, and to reducing burnout.

Could you get those benefits from being The Payments team? Sure... but there's a reason we don't have sports teams named after The Payments. Yet. Mascots and memorable names and branding, help us engage more fully.

So, name your teams something memorable. Better yet, give them a theme, and let them choose their name themselves. Then it will be their identity, and they can hold onto it.

PS: Some ideas for themes if you need them

If you enjoyed this article please share it! Also, I have a newsletter that you might enjoy as well. Thanks! -Daniel

Published: 5 February 2023 | Tags: culture