The Magic of Self-Managing Teams, Part III

Scale with Care: Platform Teams, Governance Teams, and Strike Teams

In Part II of this article, we discussed how to make self-managing teams successful, including how to get them to work together. Now, in Part III, we’ll talk about when you need to form centralized teams that support these teams and keep them on the road and going fast.

Platform Teams: Lean and Mean is the Recipe

It’s a common pattern in a software engineering organization to look for common technology / code / infrastructure that is “core” to the product or business, and to call it a “platform”. These efforts are often premature, and what is really the most common, highest value layer on the stack is still evolving. However, over time, it is important to identify any lurking “platforms” in your domain, and to create teams around them.

Here are a few simple rules of thumb:

• Applications are built on top of platforms. End users use applications. If end users are hitting your code directly, it’s not a platform. If other applications are built on top of it, then it might be.
• If developers outside of your company are building on top of your APIs to create their own applications, then you have a platform.
• If multiple engineering teams in your company are building applications on top of a common set of APIs, then you also have a platform, even if it’s “just an internal platform.”

In either of these cases, you should consider whether it is time to form a team directly responsible for the platform. But let’s focus on the second case (“internal platform”) given that it is much more nuanced.

If you create platform teams too early, your platform team will focus on optimizing a layer in the stack that isn’t stable yet. In an effort to be forward looking, they will build things that no one needs. You will create a dependency between teams that isn’t worth the cost.

If you create platform teams too late, your various domain teams will start hitting similar problems, and despite their efforts to collaborate, may reinvent the wheel. They might not invest enough in the platform since it won’t be any team’s top priority.

Social factors play into these outcomes as well. Often, the formation of a platform and the “high leverage” work that serves multiple teams will attract some of the strongest engineers in the team. However, unless those engineers are building platform capabilities that significantly enhance the domain aligned teams, it would be better if they stayed on teams directly delivering value to users.

To mitigate these risks, I’ve come up with the following best practices:

• Let the platform emerge collaboratively from your current teams before pulling the trigger. Keep new platform teams lean, until it is very clear that there is a durable need for them.
• Seed platform teams with engineers from the domain-aligned teams, who have business context and user empathy from their previous work. The platform team might eventually require specialized skills from outside the company, but don’t start there.
• Measure platform teams on how well they are enabling their customers. In the case of an internal platform team, that means how much value they are creating for the domain-aligned teams that are using the platform.
• Lastly, build bridges to these customer teams via “champions” from those teams, who articulate their needs and validate what the platform is building, in an agile manner.

It’s time for a few more nods to the authors of Team Topologies, who coined the term “Thinnest Viable Platform” as the goal for the organization. Build the thinnest platform possible, give it to your customers, get feedback, and iterate. In short, be Agile.

Governance Teams and Enabling Teams: A blend of enforcing high standards and enabling other teams to hit them

There is another type of centralized team that, when implemented properly, fits nicely into the domain-aligned team model. I called these teams “Governance teams”. They consist of a certain capability for the organization that is “horizontally” applied to all of the other teams. They are typically composed of experts in that discipline, and bring in the latest and greatest knowledge from the industry. They set standards for the organization, and assess how all of the various teams are doing.

Common disciplines for these teams are Security, Quality, and Site Reliability. I’ve also seen them for Usability and Performance.

These teams often are a point of significant friction in software engineering organizations. They can be viewed as teams of “experts” or “czars” that tell all the other teams how they aren’t doing a good enough job, and seek to restrict the flow of product development in order to maintain a certain standard done “their way”. They become process creators and enforcers. They can also become bottlenecks. This is exactly what we’re trying to avoid with an organization of self-managed teams. Often, this friction is high enough that organizations give up on having these types of teams all together.

Instead, we should look for these governance teams to not only set standards and provide expertise, but to seek to enable and support the other teams. They can do so with common tooling and infrastructure, but must also have the “connective tissue” we described earlier, either the “champion” model with reps from the other teams, or by embedding their own team members into the other teams, or both.

Team Topologies calls these “Enabling teams”. I’ve also heard them called “Advisory teams”. Those are fine terms, but I prefer the term “Governance teams” to acknowledge the reality that someone in the organization needs to be setting “what good looks like” for these areas. While we are shooting for self-managing teams to hold themselves accountable for things like quality, security, etc. we also need a consistent way to measure them, and to provide a safety net if a team is struggling.

It’s also worth calling out that sometimes, these teams are simply “enabling” without any standard or practice setting. They provide a “shared service” that can optionally be used by other teams if they need it. Internationalization and localization teams are often in this category. Teams focused on improving developer experience are often in this category as well. Teams can use the shared service or consult with the enabling team, but can also choose to do things their own way, and the enabling team doesn’t worry about it. Of course, if no one chooses to leverage the enabling team, that is a failure in its own right.

Call them what you will, these types of teams are a huge leverage point if implemented properly, and a major source of organizational stress if not!

Strike Teams: When to break things

In Part II, we talked about having patience with your team formation, and resisting the temptation to either “beg and borrow engineers” or to blow things up and start over. However, there are times when you do want to consciously (and temporarily) break your model: When you want to drive a big change across the organization.

Strike teams, also called “Tiger teams”, are formed around either a crisis or a critical change initiative, and involve selecting people from your existing teams and temporarily pulling them out of their existing work. These teams have a very tight focus and should come up with “exit criteria” so they know when they are no longer needed. Since they are composed of engineers from the regular teams, they can go back to their “home teams” and help those teams adopt whatever changes or gain whatever learnings are appropriate.

It’s very important to have full organizational buy-in when forming a Strike team, including the “outcome based” approach to when the team disbands. Many teams like this falter when management chooses instead to simply timebox the effort, or when they provide short term air cover but then pull back people to their home teams when a high product priority comes along.

Examples of when Strike teams are appropriate:

• Nagging production issues that don’t have a clear owner, and no one has enough time to investigate in depth. The breadcrumbs may lead to process changes or deep changes in the system.
• A new technology approach may be required, and needs to be vetted with a thoughtful POC. It’s a lot of work, and would affect all teams, but no one has time for it.

In a way, Strike teams are a safer, more conservative approach to forming Platform or Governance teams, yet provide more dedicated focus and effort than merely forming a Community of Practice across teams. Depending on how your Strike team goes, you’ll likely want to follow it up with one of those more permanent approaches.

Scaling Up!

How does this overall approach to organizations scale with continued growth? There are a few key factors: How you split teams, and how you build up higher level structures beyond your working teams.

The best way to add new engineers to your organization is to put them onto existing teams, so that they can learn and get context from those with more experience in the domain. This goes for junior and senior engineers alike. Then, when teams become too big and unwieldy, you can split them into two smaller teams which can then continue to grow on their own. I call this “cell division”.

Initially, the two smaller teams can still report to the same engineering manager, perhaps with a strong technical lead for one or both of the teams. It is also a good time to consider creating a new staff engineer role in this area, working closely with these teams but not necessarily solely embedded with any of them. See The Manager Manifesto and The Staff Engineer Statute for more on these roles and how they work with each other.

One issue that can happen with domain-aligned teams is that initial partitioning of the teams can be fairly clean, but then when one of those teams needs to split, the domain boundaries can become fuzzier. All this means is that the coarse domain model you started with needs refinement, at least for this one area. It should be a worthy investment, if you are staffing multiple teams against it!

Often, the highest level domain partition is still very useful in organizational structure, and therefore also in system design, goal setting, etc. Sometimes called “pillars” or “product areas”, these areas would each have a number of domain-aligned teams within them, and in addition to having good coverage of engineering managers and staff engineers, each would also have a single senior leader (potentially Director or even VP level) who can look after the entire area, set strategic direction, etc. often in conjunction with peers in Product and Design.

In short, this approach can scale up in a “self-similar” or fractal fashion. But don’t forget what the “atoms” are … not the individual engineer, but the self-managed team.

Taking The Pitch

Now, let’s return to the sports analogy from Part I, the formation of soccer players on the pitch. Hopefully, you’re now convinced that a domain-aligned formation is the best balance between competing factors, and you know how to build out your teams in this way. You know that you can thoughtfully use platform and governance teams to complement your core set of teams who are directly focused on user value.

I’ve attempted to distill as many best practices as possible into a (not so) short article, but nothing is a substitute for actual experience. Just like soccer players in a game situation, the combined unit must be flexible given different conditions, figuring out when it is OK to get out of position and when to get back into shape, playing a bit differently based on the actual human beings involved on a given day.

The fundamental concept here is the title of this series, “The Magic of Self-Managing Teams”. No matter what exact shape your organization takes, pay close attention to how autonomously your working teams can achieve their goals, while still staying aligned with each other, and you’ll be in the game. Good luck!