On Teams & Problem Spaces

Teams are most effective when they are organized around problem spaces and are explicitly named after the problem space that they’re solving. Unfortunately, if my experience is representative, this isn’t the norm. If I think back on the organizations that I’ve been a part of as an individual contributor or inherited as a manager at Microsoft, Amazon, and Riot, I’ve frequently seen teams organized around products, solution spaces, and code names. To explain each option, consider a fictitious team with the following properties:

  • The team is part of a larger organization that builds tools for feature teams to deploy, operate, and scale backend services on the company’s private cloud.
  • The team previously decided that its mission is “to make it easier for feature teams to operate deployed services” and its vision is that “services are highly available and easily scalable with virtually no operator intervention”.
  • The team’s current flagship product is an alerting and monitoring system called Brometheus.
  • The team happens to be obsessed with Star Wars (who isn’t?).

Now suppose you’re tasked with naming the team. You could name the team the Brometheus Team after it’s most important product. Alternatively, you call them the Monitoring Team, since the solutions that they currently own are in the monitoring space. You could accept the suggestion of a couple of team members that believe that names don’t matter and have pushed to be called the Jedi Order. Or, you could name the team after the broader problem space and call it the Operability Team.

The final option is superior to the others for several reasons:

  • Unlike the product and solution space options, it doesn’t constrain thinking and imply a particular solution. If you’re the Brometheus Team, your work will always revolve around improving that product (you have a hammer and everything will look like nails). Similarly, the Monitoring Team will always focus on building monitoring products. The Operability Team is free to decide that they can make it easier to operate services by working on auto-scaling, service call-tracing, or debuggability instead.
  • Unlike the code name option, it’s immediately obvious what your team does and what sandbox you play in. The Jedi Order may sound cute and the team may rally around that identity in the short term, but at scale, it becomes difficult for customers to keep a mental map of who is working on what. Further, the team’s new identity is not rooted in being a team and not the problem they’re solving; the former tends to fizzle much more quickly.

Reorganizing or renaming teams can be hard work, particularly if the team’s current identity is tightly wound around their current name or organizational structure. But in the long run, doing the work to identify problem spaces, organize teams around those problem spaces, and to explicitly name teams after the problem space they’re tackling is worth it.