Fundamental Team Topologies

Stream Aligned Team

The Stream-Aligned Team is the classic product/feature team: a cross functional team of 5-8 people responsible for end-to-end ownership of a value stream. Roughly 80-90% of the teams in an organization should follow this pattern.

Enabling Team

The Enabling Team is a team of specialists that exists to transfer knowledge to stream-aligned teams.

Note they explicitly transfer knowledge and empower other teams, rather than becoming silos of knowledge:

If an enabling team does its job well, the team that it is helping should no longer need the help from the enabling team after a few weeks or months; there should not be a permanent dependency on an enabling team.⊕ (Skelton and Pais 2019, chap. 5)

For some examples:

Often they are focused on more specific areas, such as build engineering, continuous delivery, deployments, or test automation for particular client technology (e.g., desktop, mobile, web). For example, the enabling team might set up a walking skeleton of a deployment pipeline or a basic test framework combining automation tools and some initial scenarios and examples.⊕ (Skelton and Pais 2019, chap. 5)

One pattern is for these enabling teams to be ephemeral:

I felt strongly that an engineering enablement team should plan for its own extinction from the very first day to avoid other teams becoming dependent.⊕ (Skelton and Pais 2019, chap. 5)

Platform Teams

The goal of Platform Teams is to provide systems that reduce the cognitive load of stream-aligned teams.

Given the goal of reducing cognitive load:

“Ease of use” is fundamental for platform adoption and reflects the fact that platform teams must treat the services they offer as products that are reliable, usable, and fit for purpose,⊕ (Skelton and Pais 2019, chap. 5)

Interestingly, a large platform organization should likely be split up internally using these fundamental components: stream-aligned subteams addressing different use-cases of the rest of the company and an internal platform subteam supporting them.

Complicated Subsystem Teams

The goal of a Complicated Subsystem team is to reduce the cognitive load of stream-aligned teams a particular complicated subsystem.

The team handles the subsystem complexity via specific capabilities and expertise that are typically hard to find or grow. We can’t expect to embed the necessary specialists in all the stream-aligned teams that make use of the subsystem; it would not be feasible, cost-effective, or in line with the stream-aligned team’s goals.⊕ (Skelton and Pais 2019, chap. 5)

(Editorial note): Nearest I can tell, the difference between a “platform team” and a “complicated subsystem” is merely a matter of domain. For the author, “platform teams” are in the domain of running production code while “complicated subsystem teams” are in other domains, e.g. video processing codec, machine learning, etc. I personally think this distinction hides the fact that they have the same goal (reduce cognitive load for stream-aligned teams) and the same approach (create usable services that abstract complexity).

Quotes

The mission of an enabling team, for instance, is to help stream-aligned teams acquire missing capabilities, taking on the effort of research and trials, and setting up successful practices.⊕ (Skelton and Pais 2019, chap. 5)

The mission of a platform team is to reduce the cognitive load of stream-aligned teams by off-loading lower level detailed knowledge (e.g., provisioning, monitoring, or deployment), providing easy-to-consume services around them.⊕ (Skelton and Pais 2019, chap. 5)

Tooling teams are typically better run either as enabling teams–with a short-lived and highly focused remit–or as part of the platform (with a clear, well-informed roadmap).⊕ (Skelton and Pais 2019, chap. 5)

What kind of behaviors and outcomes do we expect to see in an effective enabling team?

• An enabling team proactively seeks to understand the needs of stream-aligned teams, establishing regular checkpoints and jointly agreeing when more collaboration is needed.
• An enabling team stays ahead of the curve in keeping abreast of new approaches, tooling, and practices in their area of expertise, well before an actual need is expected from stream-aligned teams. In the past, this has been the mission of architecture or innovation teams, but the focus on enabling other teams creates a better dynamic.
• An enabling team acts as a messenger of both good news (e.g., “There’s a new UI automation framework that can reduce our custom test code by 50%.”) and bad news (e.g., “Javascript framework X, which we’re using extensively, is no longer actively maintained.”). This helps with management of the technology life cycle. ​
• Occasionally, the enabling team might act as a proxy for external (or internal) services that are currently too difficult for stream-aligned teams to use directly. ​
• An enabling team promotes learning not only inside the enabling team but across stream-aligned teams, acting as a curator that facilitates appropriate knowledge sharing inside the organization (supporting what Tom DeMarco and Tim Lister call a “key learning function.”⊕ (Skelton and Pais 2019, chap. 5)
  
  

What kind of behaviors and outcomes do we expect to see in an effective platform team?

• A platform team uses strong collaboration with stream-aligned teams to understand their needs. ​
• A platform team relies on fast prototyping techniques and involves stream-aligned team members for fast feedback on what works and what does not.
• A platform team has a strong focus on usability and reliability for their services (treating the platform as a product), and regularly assesses if the services are still fit for purpose and usable. ​
• A platform team leads by example: using the services they provide internally (when applicable), partnering with stream-aligned teams and enabling teams, and consuming lower level platforms (owned by other platform teams) whenever possible. ​
• A platform team understands that adoption of internal new services, like new technologies, is not immediate, but instead evolves along an adoption curve.⊕ (Skelton and Pais 2019, chap. 5)