Team Topologies · Manuel Pais and Mathew Skelton · 2019
Essential reading if you need or want to learn a little more about organisational design. The model in this book is a simplification of a messier reality, but it’s a useful frame of reference. It establishes a limited number of team types and interaction types between teams. The authors then explain how fracture planes and sensing/triggers can help you identify the best team topologies.
Key Points
Traditional org charts create two persistent problems. Firstly they are often out of date, shaped by office politics and legacy systems. Secondly they hide the interactions and communication that actually determine how work gets done.
Evaluating org design through a systems-thinking lens helps: optimise for the whole, understand flow and bottlenecks, and treat the organisation as a complex adaptive system that will need ongoing review and iteration. Structures should flex and adapt to new conditions.
In knowledge work, success hinges on the quality of interactions between people and teams. Every organisation operates across three overlapping structures: the formal structure that facilitates compliance (the org chart), the informal structure of influence between individuals, and the value-creation structure where work moves based on inter‑personal and inter‑team reputation.
Key Principles:
Make interaction expectations explicit: agree on clear interaction models with other teams to set expectations and build trust.
Team Topologies clarifies team purpose and responsibilities so that inter-team relationships become more effective. Design software architecture and organisational structure together to account for Conway's Law. Clean Conway's Law (Ruth Malan) states: if the architecture of the system and the architecture of the organisation are at odds, the architecture of the organisation wins. Use the Reverse Conway Manoeuvre to change team and org structure in service of the architecture you want, rather than mandating architecture in isolation. Technology leaders must understand the necessary architecture before organising teams. The goal is an architecture that enables teams to deliver without needing high‑bandwidth communication between many teams.
Restrict unnecessary communication. Minimise the number of communication paths between teams; low‑ or zero‑bandwidth communication is desirable when appropriate. Use fracture plane patterns to split software into smaller, well-bounded parts. Limiting paths to well‑defined interactions produces modular, decoupled systems. Tooling also shapes communication patterns; teams that must collaborate closely should share tools.
Define Team APIs and actively facilitate team interactions. A Team API is the description and specification for how to interact with a team. Teams should define, advertise, test, and evolve their Team API to ensure it remains fit for other consumers.
Keep each team's cognitive load within manageable limits. Design system boundaries to fit cognitive load, not the other way around, and restrict responsibilities accordingly. Dan Pink's autonomy, mastery, and purpose are undermined when teams carry too many domains. Ask whether the team feels effective and able to respond in a timely fashion. Identify the domains a team must handle, classify them by difficulty, and divide them appropriately.
- Assign each domain to a single team.
- A single team can usually handle 2–3 simple domains.
- A team responsible for a complex domain should not take on additional domains.
- Avoid assigning two complicated domains to one team.
- When in doubt, prioritize how the team feels about the load.
Optimise for flow of change, rapid feedback from running systems, and the removal of bottlenecks. Fast flow usually requires restricting communication paths and reducing dependencies. The fewer dependencies the better. Stream‑aligned teams are the preferred default, and the number of team dependencies in the org design strongly affects delivery speed.
Approach:
Adopt a team‑first, humanistic approach to system and org design. Use small, long‑lived teams as the standard and make work flow to them. Teams take time—often 2–12 weeks—to become effective; keep stability so they can reach high performance. The ideal size of teams, groups, and divisions depends on organisational trust. As a guide: single teams of 5–15 people; groups of teams (tribes/families) of 50–150; and P&L/divisions of 150–200. Establish crisp ownership: every part of the system is owned by exactly one team, with no shared ownership of components, libraries, or code. Encourage a team‑first mindset—put the team's needs above individual preferences—and reward the team as a whole, including allocating training budgets to teams. Invest time, space, and money to facilitate interactions that build trust, awareness, and learning.
Consciously design teams into a small set of Team Topologies and shape inter‑team communication for flow and sensing. When selecting a topology, consider technical maturity, cultural maturity, organisational size, software scale, and engineering maturity. Reduce or eliminate dependencies on "central" teams by splitting their responsibilities and empowering other teams to take on capabilities. Detect and track dependencies and wait times between teams.
The four fundamental team types are a simplifying pattern that reduces ambiguity and clarifies purpose:
- Stream‑aligned teams own a continuous flow of work aligned to a business domain, product, service, feature, persona, or user journey; they work from idea to deployment as independently as possible and form the primary team type.
- Enabling teams are specialists who bridge capability gaps for stream‑aligned teams, increasing autonomy by growing their capabilities; they often focus on build engineering, continuous delivery, deployments, or test automation, and typically engage temporarily for knowledge transfer.
- Complicated‑subsystem teams build and maintain subsystems that require deep specialist knowledge; this reduces the cognitive load on stream‑aligned teams where it would not be feasible or cost‑effective for them to own such systems.
- Platform teams provide self‑service APIs, tools, services, knowledge, and support as an internal product that enables stream‑aligned teams to deliver with autonomy; the platform's value is measured by the value it enables for product teams. Avoid grouping functional expertise (e.g., UX, architecture, data processing, DBA, testing) into separate functional silos; that model impedes safe, rapid change. Over time, aim for most teams to be stream‑aligned.
Choose software boundaries using fracture planes: natural seams that allow a system to split cleanly. Align boundaries with business‑domain bounded contexts to improve prioritisation, flow, and user experience, and to reduce terminology mismatches so everyone speaks the same language. Common fracture planes include regulatory compliance, team location, change cadence, risk, performance isolation, technology, and user personas.
Simplify inter‑team communication with three core interaction modes. Not every team should talk to every other team to achieve its goals; choose the right mode for the right purpose.
- Collaboration: high‑intensity joint work that drives innovation and rapid discovery; it blurs boundaries, requires strong alignment and joint accountability, and should be time‑boxed and focused on high‑value outcomes.
- X‑as‑a‑service: clear provider/consumer responsibilities where a team offers a code library, component, API, or platform that "just works" with minimal collaboration; it demands strong product management and a compelling developer experience.
- Facilitating: active coaching and enablement that senses and reduces capability gaps; experienced staff help multiple teams learn, remove common impediments, and unblock flow.
Associate behaviours with each mode: in collaboration, emphasise high interaction and mutual respect; in X‑as‑a‑service, emphasise the user experience; in facilitating, emphasise helping and being helped.
There are typical pairings: stream‑aligned teams commonly use collaboration and X‑as‑a‑service and occasionally benefit from facilitation; enabling teams typically operate in facilitating mode with occasional collaboration; complicated‑subsystem and platform teams are typically consumed X‑as‑a‑service, with occasional collaboration.
Use awkwardness in interactions as a sensing mechanism: it often signals missing capabilities or misplaced boundaries.
Expect team structures to evolve. Common triggers include software growing too large for one team, slowing delivery cadence, and multiple business services relying on a large underlying set of services.
Continuously sense and respond: check whether you've misunderstood user needs or behaviours, whether interaction modes should change, whether to build or buy a capability, whether collaborations are still effective, whether flow is smooth and what hampers it, and whether promises across team boundaries are still valid and achievable. Anchor this evolution in the three ways of DevOps: systems thinking to optimise fast flow across the whole organisation, feedback loops so development is informed and guided by operations, and a culture of continual experimentation and learning that brings sensing and feedback into every team interaction.
Full Book Summary · Amazon
Subscribe Button Quick Links
Taking Pride in What You Ship · Article
The Unhappy Path of Product Strategy · Article
Easy vs Simple in System Design · Article
User Journeys ≠ Customer Journeys · Article
Why startups should deliberately choose hard problems · Article
The 7 Deadly Myths of Autonomous Systems
JM. Bradshaw, Hoffman, Johnson, and Woods 2013. (View Paper → )
In this article, we explore some widespread misconceptions surrounding the topic of "autonomous systems."….to set the stage, in this essay we bust some "myths" of autonomy.
The Seven Myths:
- Autonomy is unidimensional. It's a mistake to view autonomy as a single property; instead, real autonomy involves at least two distinct dimensions—self‐sufficiency (the ability to take care of oneself) and self‐directedness (freedom from outside control)—that must be balanced in any human–machine system.
- Levels of autonomy provide a useful roadmap. The idea that machine capabilities can be ordered on a simple scale (from low to high autonomy) oversimplifies the complex, context-dependent nature of tasks, failing to capture the multifaceted interplay of functions in real-world systems.
- Autonomy is a widget. Treating autonomy as a discrete, pluggable component ignores that true autonomous behavior emerges only through integrated interactions between machines, humans, tasks, and the surrounding context.
- Autonomous systems are autonomous. Even when a system is designed to operate 'autonomously,' no machine is truly independent in every situation; all systems have operational limits and often require human oversight or context-specific adjustments.
- Full autonomy eliminates the need for human collaboration. The belief that a fully autonomous system can operate without human involvement overlooks the reality that effective performance in complex, dynamic environments always benefits from—and sometimes depends on—coordinated human–machine teamwork.
- Increased autonomy simply substitutes or multiplies human capabilities. Rather than being a straightforward replacement or amplifier of human work, adding autonomy can fundamentally change how tasks are performed, often introducing new challenges in coordination and interdependence.
- Full autonomy is both possible and always desirable. The notion that achieving full autonomy is the ultimate goal ignores the trade-offs involved—such as stretched system capacities and new forms of complexity—which means that even highly autonomous systems require careful integration with human oversight.
/w=3840,quality=90,fit=scale-down)
Book Highlights
In an OKR system, the most junior staff can look at everyone’s goals, on up to the CEO. Critiques and corrections are out in public view. John Doerr · Measure What Matters
Poker players live in a world where that risk is made explicit. They can get comfortable with uncertainty because they put it up front in their decisions. Annie Duke · Thinking in Bets
While no driver would undertake a journey in a car with no instrument panel, when they’re actually driving good drivers spend most of their time looking through the windscreen at the road and the other traffic, and react fast to what they see. Stephen Bungay · The Art of Action
/w=3840,quality=90,fit=scale-down)
Quotes & Tweets
Clutter and confusion are failures of design, not attributes of information. Edward R. Tufte
“The smartest person in the room, I’ve learned, is usually the person who knows how to tap into the intelligence of every person in the room.” Scott Kelly