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.

  1. Marcus Blankenship

    Why not let teams choose their own names?

    • Tyson Trautmann

      I do, as long as they choose a name that is a problem space. 🙂 I’m all about empowering teams. But as an organizational leader, part of my job is to bring my SME to the table and define the boundaries of the sandbox that the empowered team plays in.

  2. This all rings very true, from my experience across many teams. Naming is important. It’s often part of the foundational narrative the people tell themselves about the team.

    I also think many teams are too long-lived. They form an identity around, as you say, a particular product, feature, capability, etc, which may only temporarily need to be worked on. It would perhaps be better to name that team after the outcome being sought. For example, ‘Dashboard Alpha’, to indicate that once the alpha is built, the team’s job is done. This would also help people to feel a sense of direction and something to rally around.

    Disbanding a team, of course, doesn’t have to mean firing people. If those people work well together, they could all be moved to a new team, new project, etc.

    • Tyson Trautmann

      Totally agree with your assertion that teams are overly long-lived (we start with status quo and then talk delta versus questioning everything that we’re doing), although I view this as a pendulum. There’s a significant cost associated with teams going through the storming-norming-performing cycle, so there is often good reason to keep a high-functioning team together beyond just completing a single project or launching a product. The sweet spot is probably somewhere in the middle.

Trackbacks for this post

  1. New top story on Hacker News: Organize Teams Around Problem Spaces, Not Products – Tech + Hckr News
  2. New top story on Hacker News: On Teams and Problem Spaces – ÇlusterAssets Inc.,

Leave a Reply