Team Topologies

Team structures are too often decided by executives disconnected from the daily work. This situation becomes especially problematic when those execs do not understand the system architecture implications of their decision.

People communicate to get work done but those communication paths do not follow an org chart. I think this makes the manager’s job easier – you aren’t responsible for funneling all communications. But it also increases the need to train and provide feedback to your staff on cross-functional communications.

The authors distinguish between team types and interaction modes between those teams. Where your team interacts with another team you should ask, “What is the current interaction mode and what should it be?”

You may find that collaborations which currently feel like dependencies or blockers can be transformed into X-as-a-service or facilitating relationships.

Your team members should have a similar mental model of the software system you’re building together. This shared mental model arises and strengthens as you put teams at the forefront of your software boundaries, dividing the work and systems not by technology but by business domain.

Dependencies on other teams kill production speed. Producers also find those dependencies frustrating and demotivational.

Non-technical managers and junior engineers often make the same mistake of optimizing for batches and economies of scale because they perceive software development like an assembly line.

They mistakenly focus on efficiency where they should focus on effectiveness.

In many orgs, DevOps teams are just a rebranding of system admin teams. Rather than facilitating enabling other teams, they inject themselves in the critical function path and function as a blocker.

The authors go into great detail on the four team types and suggest that all teams should gravitate toward one, not float between types.

1. Stream-aligned: Cross-functional teams focused on a single valuable stream of work like a product, feature, or user persona
2. Enabling: Specialists that help bridge a technical or product domain gap
3. Complicated-subsystem: Builders and maintainers of a system depending on highly specialized knowledge
4. Platform: Provide APIs, tools, services, and knowledge which function as an internal product

The authors refer to the division points as “fracture planes” and identify most technology based teams as an anti-pattern that ultimately impedes the flow of work because no team can complete work front to back – collaboration is always required and cross-team dependencies are high.

There is such a thing as too much collaboration. We should aim to collaborate as necessary but no more because collaboration is expensive and slows the flow of work.