How to Structure Teams for Building Better Software Products

Team Topologies Book Summary

Matt Lane
Matt Lane
Jun 25, 2020 · 8 min read
Book by Manuel Pais and Matthew Skelton

he team topology approach treats humans and technology as a single sociotechnical ecosystem, and thus it takes a team-sized architecture approach (people first) rather than a technology-first approach, e.g., the monolith vs microservices debate. NOTE: If you have microservices but are still waiting to do end-to-end testing of a combination of services, you have a distributed monolith (a distributed monolith is when all changes in a service require updates to other services).

If you know you need to deploy different parts of the system independently, you need to decouple services. In this environment, you should make your teams small and decoupled with clear boundaries. These boundaries should represent the business context and always be designed with the user in mind. These small decoupled team models also help to minimize intrinsic cognitive load and eliminate extraneous cognitive load.

With well-defined and stable communication pathways between teams, organizations can detect signals from across the organization and outside it, becoming something like an organism. This helps to adjust team interaction patterns, which are much easier to adjust than via conducting reorg after reorg.

The roots of success are not in creating organizational structures but in developing capabilities and habits in teams, in people. We should design the shape of decision rules and heuristics used to adapt to new challenges. This is important because a team is the most effective means of software delivery, a team is an indivisible part of the product.

And, when it comes to measuring performance, teams matter more than individuals when building and evolving modern software. An organization should assign objectives to teams, not individuals and consider team-scoped flow and design architecture to fit it. The team topology approach enables this.

See more team concepts in my other article here, and read Marty Cagan’s work on empowered product teams.

High-level Takeaways:

  • There should be no shared ownership of components, libraries, or code. Every subsystem is owned by only one team. Why? You must ensure the cognitive load is not exceeded by the size of the subsystem.
  • Create stable team APIs, e.g., code (runtime endpoints), versioning, documentation, etc. Git Repos are owned by a team and pull requests are done through cross-team pairing.
  • Use software boundaries defined by business-domain bounded contexts (these boundaries can be aligned to stream-aligned teams).
  • DevOps is not simply about addressing automation and tooling. Organizations that can address misalignments between teams can take full advantage of DevOps. DevOps should be building self-service capabilities that application teams can rely on autonomously. They look at live service problems and ensure flow is good for dev teams, and they must understand how application changes affect customers.
  • Non-blocking dependencies often take the form of self-service capabilities, e.g., provisioning test environments, creating deployment pipelines, monitoring, etc.
  • Stream-aligned teams need autonomy to provision their environments and resources in the cloud, creating new images and templates where necessary, e.g., split between cloud team designing cloud infrastructure and product teams provisioning and updating application resources.
  • Teams composed of only people with single functional expertise should be avoided at all costs.
  • Tooling teams should be reorganized into enabling teams, and you should convert architects into enabling teams to focus on APIs between teams and those interactions.
  • Regardless of your business operations, break monoliths up into platform teams.

Fracture Planes (software responsibility boundaries):

Fracture planes are the natural divisions that exist between teams, and where team and value stream architects can start when looking to optimize the organization to be mapped in a business domain bounded context (DDD).

You can do this for example with regulatory aspects in industries where that is impactful. For example, in a fintech enterprise, you might see natural fracture planes between payments and transaction reporting.

Perhaps, PCI DSS is a dedicated subsystem for card management (but, does not apply to an entire monolith that happens to include payment functionality). Splitting along these regulatory-compliance fracture plane simplifies auditing and compliance, as well as reduces the blast radius of regulatory oversight. Eventually, when a subsystem gets split off, it then might make sense to design a compliance-focused team.

We can also map technologies with different risk profiles. For example, if you have more users in a paid tier, it might make sense to build more stable services and methodical updates to the product than with the free tier where it is less of an issue if errors to occur.

Teams can also be defined around differences in frequency, i.e., release schedule differences.

And, there might also merge natural fracture planes around performance demands, i.e., some services need to scale where another does not need to load balance traffic/bandwidth for demand as much.

At the end of the day, the goal always has to be: Does this support more autonomous teams to be less dependent? If yes, you are doing the right thing.

When you are ready to start designing team structures, consider asking the following questions.

What does the team need in order:

  • Act and operate as an effective team?
  • Own part of the software effectively?
  • Focus on meeting the needs of users?
  • Reduce unnecessary cognitive load?

The first thing you should do is to identify stream-aligned teams and map the existing value streams of your organization and how teams need to interact with each other to best serve customer needs.

The second thing you should is identify the thinnest viable platform. It is important to remember that the platform technology is only one part of this layer. Roadmaps, guided evolution, clear documentation, a concern for DevUX, are all part of the delivery of a platform for stream-aligned teams. Doing this helps to avoid the platform from dominating discourse. The goal is to help accelerate and simplify software delivery for teams building on the platform.

If these two steps are achieved, you are well on your way to not pushing against Conway’s Law (how the conscious design of teams and intercommunications can help improve the software architecture of the system being built by restricting the solution search space and saving time and effort for everyone. A design effort should be organized according to the need for high-bandwidth communication).

Four Fundamental Team Topologies:


Sometimes called full-stack, cross-functional, or product teams. Stream-aligned teams are aligned to the main flow of business change with cross-functional skills and the ability to deliver significant increments of value without waiting on other teams. These teams might be oriented around a single product, a user journey, a set of features, etc.

Ways to identify:

  • Role-oriented stream types, e.g., online money management, automation of banking transactions, etc.
  • Activity stream types, e.g., search for tickets.
  • Task-oriented stream types, e.g., apply for credit.


Teams that work on the underlying platform supporting stream-aligned teams in delivery. The platform team simplifies otherwise complex technology and reduces cognitive load for teams that use it.

  • Treat services as products and are consumed by product teams via API, e.g., container provisioning, network config, etc.
  • Value can be measured by services they provide to product teams.
  • Can be several distinct teams in a platform team, e.g., network, CD environments, metrics, etc.
  • Always serves the needs of consuming apps, not the other way around.
  • Treat as a live or production system, where we define hours of operation, define response time for incidents and support, on-call rota, etc.
  • Must take into account the direction of changing needs of the organization.

NOTE: A DBA team should be decomposed into a platform specializing in performance, config, availability, but not schema changes or app level DB concerns.

Enabling team:

A team that assists other teams in adopting and modifying software as part of a transition or learning period.

  • They take a servant leadership approach to understand the shortcomings of stream-aligned teams, e.g., they might set up a walking skeleton of a deployment pipeline. They work with stream-aligned teams temporarily, like setting up containers, or long-term when setting up faster test execution.
  • They switch focus and move around to different teams to help solve the next set of evolving problems.
  • Communities of practice (like Guilds at Spotify) are different than enabling teams in that they are longer-term and care about sharing widespread knowledge.

Complicated subsystem:

Teams with a special remit for a subsystem that is too complicated to be dealt with by a normal stream-aligned team or platform.

  • Optional and only used when necessary.

Interaction Modes Between the Four Fundamental Team Topologies:

Collaboration mode:

When two teams work together, particularly during the discovery of new technology approaches. The overhead is valuable due to the rapid pace of learning.

X-as-a-Service mode:

When one team consumes something provided by another team (such as an API, a tool, or a full software product). Collaboration is minimal, which is why they are great for clarity, and when predictability is more important than discovery.

Facilitating mode:

When one team, usually an enabling team, facilitates another team in learning or adopting a new approach.

here is also the concept of discovery: Collaboration first (to validate Viable-as-a-Service boundaries) and eventually to an X-as-a-Service (lightweight) phase. Event storming and context mapping can help establish these boundaries.


It is worth revisiting the Allen curve before making any big decisions about splitting teams across geographies.

It takes less effort to communicate when people are physically located near each other. But communications speed is only one of the benefits of colocation. As the effort to communicate decreases we see increases in interpersonal communications.

Non-task-related interpersonal communications that come from colocation is central to developing high-performance teams. Social expectancy theory tells us that we can work effectively with people when we can predict their behaviour. Since trust is primarily based on experience, and trust is accrued more readily via face-to-face communication, it follows that we can increase trust by maintaining continuity in our teams.

At the very least, reduce large time zone differences within and between teams that regularly interact with each other.

The Startup

Get smarter at building your thing. Join The Startup’s +787K followers.

Sign up for Top 10 Stories

By The Startup

Get smarter at building your thing. Subscribe to receive The Startup's top 10 most read stories — delivered straight into your inbox, once a week. Take a look.

By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.

Matt Lane

Written by

Matt Lane

Product management leader focusing on culture, organizational performance, and strategy.

The Startup

Get smarter at building your thing. Follow to join The Startup’s +8 million monthly readers & +787K followers.

Matt Lane

Written by

Matt Lane

Product management leader focusing on culture, organizational performance, and strategy.

The Startup

Get smarter at building your thing. Follow to join The Startup’s +8 million monthly readers & +787K followers.