Quick Navigation
- Start here — the limit nobody put in the plan
- What a team is actually carrying
- Four team shapes that respect the limit
- Three interaction modes — the interface is the design
- The platform as the load-absorbing interface
- Golden paths, dirt roads, and the museum problem
- Measuring whether the interface works
- Putting it all together
- Cheat sheet
Before we start — the one thing to hold onto
Team capacity is usually discussed as headcount and velocity. Neither measures the thing that actually runs out first: how much a team can understand well enough to change safely.
A team can only hold so much. The interfaces between teams — what each team has to know about the others to get work done — are what decide whether that limit is respected or quietly exceeded.
That reframes overload. It stops being a staffing conversation and becomes an interface design conversation, which is the only kind that can be fixed without hiring.
Keep it in mind.
1. Start here — the limit nobody put in the plan
Here is what exceeding the limit sounds like from inside a team:
- "We own eleven services and can explain four of them."
- "Nobody here knows how that integration works any more — we just restart it."
- "Half the sprint is answering other teams' questions."
- "We can't take that on. But we also can't say no."
None of that is a performance signal. It is a load signal.
A team's cognitive load is the total set of things it must hold in mind to do its job: the domains it owns, the systems it operates, the tooling it maintains, the interfaces it must understand to integrate, and the questions other teams route to it. Headcount says nothing about that total. You can add two engineers to a team and increase its load, because you have also added the coordination surface that comes with them.
The load a team carries is not a number anyone chose. It accumulates. A service gets added because there was nowhere else to put it. A legacy system stays because the team that built it dissolved. A tool becomes theirs because they were last to touch it. Nobody decided to overload the team — which is exactly why nobody notices when it happens.
flowchart TD
D["🧭 Domains owned"] --> LOAD["🧠 Team Cognitive Load"]
S["⚙️ Systems operated"] --> LOAD
T["🔧 Tooling maintained"] --> LOAD
I["🔌 Interfaces to understand"] --> LOAD
Q["💬 Questions routed in"] --> LOAD
LOAD --> OVER["Beyond the limit:\nslow change, fragile knowledge,\nrestart-and-hope operations"]
Cognitive load is finite, it is not chosen, and it is the first thing to overflow.
Try it yourself — The load inventory
For one team, list everything it must hold in mind.
| Category | List it | Could a new joiner learn this in a month? |
|---|---|---|
| Domains owned | ||
| Systems operated in production | ||
| Tooling maintained | ||
| Interfaces it must understand to integrate | ||
| Questions other teams route to it |
Now ask the team the same question you just answered on their behalf. Where the two lists differ is where the load is invisible to leadership — which is the load that never gets designed against.
2. What a team is actually carrying — Overloaded, under-bounded, or holding the wrong things
A cognitive load assessment sorts teams into three conditions, and they need different responses.
Overloaded. The team owns more than it can sustainably hold. Teams everyone assumed were high performing turn out to be carrying three times what is sustainable — which finally gives the delivery drag a structural explanation rather than a people one. The fix is subtraction: move ownership, not add engineers.
Under-bounded. The team's boundary does not enclose a complete flow of change, so it cannot finish anything without reaching outside. Its load is not large, it is leaky. Every piece of work requires understanding somebody else's system. The fix is boundary redesign — the subject of Conway's Law & Team Boundaries.
Carrying the wrong things. The team's load is the right size but the wrong shape: it maintains tooling that should be platform capability, or holds a complicated subsystem that belongs to specialists, or absorbs questions that a self-service interface should answer. The fix is to move the load to a team type designed to hold it.
All three present identically in a status report: slow delivery, missed commitments, an exhausted team. Diagnose the condition before choosing the intervention, or you will hire into an under-bounded team and make its coordination surface bigger.
3. Four team shapes that respect the limit
Team Topologies gives four team types. Each exists to hold a different kind of load.
Stream-aligned teams own a flow of change end to end — a product, a service, a customer journey. They are the default. Everything else exists so that these teams can hold less.
Platform teams provide internal capability that stream teams consume rather than build. Their entire justification is load removal: every concern the platform absorbs is a concern a stream team no longer holds in mind.
Enabling teams help other teams acquire a capability, then leave. They are a temporary load transfer, not a permanent dependency. If an enabling team becomes a standing part of another team's workflow, it has become an interface problem.
Complicated-subsystem teams hold a domain that genuinely requires specialist knowledge — the kind where spreading it across stream teams would raise total load rather than lower it. This type is a deliberate exception and should be rare.
The topology is not an org chart in different clothing. Each type is a claim about where load should sit.
Try it yourself — The topology placement
Take four teams. Place each against the type its actual work matches — not its title.
| Team | Type its work matches | Type its charter claims | What load would have to move for these to agree? |
|---|---|---|---|
A team whose work and charter disagree is carrying load that the design never accounted for.
4. Three interaction modes — the interface is the design
Team types alone do not control cognitive load. How teams interact does.
Two teams working on the same problem carry each other's context. Two teams connected through a stable service interface carry almost none. Same teams, same work, different load — the difference is the interaction mode.
There are three, and choosing one is a design decision, not an accident of who knows whom.
Collaboration. Two teams work closely together on a shared problem. High bandwidth, high discovery — and high cognitive load for both, because each must hold enough of the other's context to be useful. Collaboration is expensive by design. It is right when the problem is genuinely novel and the interface is not yet known, and it should be time-boxed, because its cost does not fall over time.
Facilitating. One team helps another acquire a capability, with the explicit intent of ending. This is how an enabling team should operate. The measure of success is that the interaction stops.
X-as-a-Service. One team consumes something another team provides, through a defined interface, with minimal conversation. This is the lowest-load mode: the consumer holds the contract, not the implementation. It is the right target for anything stable and well understood.
flowchart LR
COLLAB["🤝 Collaboration\nShared problem\nHigh bandwidth"] -->|"once the interface\nis understood"| XAAS["📦 X-as-a-Service\nDefined contract\nMinimal conversation"]
FACIL["🧑🏫 Facilitating\nCapability transfer\nDesigned to end"] -->|"capability acquired"| XAAS
COLLAB --> COST["High load\non both teams"]
XAAS --> LOW["Load held only\nby the provider"]
The direction of that diagram is the point. Collaboration and facilitating are transitional states. If either persists indefinitely, it has stopped being a mode and become a permanent tax.
Which leads to the most useful reframe in this module: a cross-team dependency is not an inevitability to be managed. It is a design failure to be eliminated — or, where it cannot be eliminated, converted into a service interface so that only one team holds the complexity.
Note the overlap with authority. An interaction mode only stays low-load if the consuming team can actually decide within its own boundary; if every use of a service requires an approval conversation, the interface has become a collaboration mode wearing a service contract. That is the seam with Decision Rights & Delegation.
5. The platform as the load-absorbing interface
The platform team is the clearest case of an interaction mode expressed as an organisation. Its whole purpose is to hold complexity so that stream teams do not have to.
Which means the platform needs a charter that says what it exists to do — and what it does not. The scope question is not administrative tidiness. An unbounded platform team absorbs whatever is unclaimed, becomes overloaded itself, and then becomes the bottleneck it was created to remove.
The charter also has to draw a line between enabling and controlling. A platform that enables removes load. A platform that controls adds it, because now every stream team must understand and negotiate with the platform's rules on top of doing its own work.
There is a clean test for which side of the line a platform sits on: a platform team is doing well when stream teams rarely need to ask it for help. Not when it is busy. Not when its ticket queue is full. When the interface is good enough that the conversation is unnecessary.
6. Golden paths, dirt roads, and the museum problem
Most teams think they need a platform. Often what they need is fewer obstacles.
The failure mode is well known: platform teams build genuinely good internal tools, and product teams do not use them, because the golden path is harder than the dirt road. Organisations invest heavily in internal platforms that teams work around — not because the platform is bad, but because nobody asked the developers what they actually needed.
A platform is not technology. It is a product, and your developers are the customers. If they do not choose to use it, you do not have a platform. You have a museum.
That reframing turns platform engineering from a build exercise into a product discipline, and changes the question from "is this the right way?" to "would a developer choose this?"
A golden path is the standardised, secure, observable route through a common task — creating a service, shipping to production, adding an integration. It earns its name only if it is genuinely the path of least resistance. The moment the paved road is slower than the dirt road, developers take the dirt road, and every standard the platform encoded leaves with them.
Try it yourself — The golden path test
Look at your current standard way to create a new service.
| Question | Your answer |
|---|---|
| How many steps is it? | |
| How long does it take a developer who has never done it? | |
| Would you choose it if you had a choice? | |
| What is the dirt road, and why is it faster? |
Then ask a developer the friction question directly: "What's the hardest part about getting your code into production?" Not the technical part — the frustrating part, the part that makes them sigh. If the answer is not "writing the code," you have found where the load actually sits.
7. Measuring whether the interface works
Cognitive load is not directly countable, but the interface around it leaves measurable traces.
Developer experience measures. A DevEx baseline — pain points, bottlenecks, satisfaction — is the closest direct read on whether teams are carrying more than they can hold. It is also the measure platform teams most often skip, because uptime is easier to collect. Measuring platform success by uptime instead of developer satisfaction is how a museum gets a green dashboard.
DORA metrics. Deployment frequency and change failure rate tell you whether teams can actually move inside their boundaries. Higher deployment frequency with lower failure rate is the signature of load that has been genuinely removed rather than relocated.
Onboarding time. How long before a new engineer is productive is a direct proxy for how much a team must hold. Load that has been well designed shows up as faster onboarding; load that has accumulated shows up as a six-month ramp nobody can explain.
Coordination overhead. Features scoped inside a single team's boundary rather than across several, and fewer cross-team dependency surprises in planning, are the signals that interaction modes are doing their job.
Two more things belong in the measurement picture because they change what teams have to hold. Guardrails — technical standards enforced by the path rather than by review — remove the load of remembering the rules. And observability-driven development means teams can understand production behaviour without holding it all in their heads, which is load reduction by instrumentation rather than by reorganisation.
Putting it all together
flowchart TD
LIMIT["🧠 A team can only hold so much"] --> ASSESS["Assess the load\nOverloaded · Under-bounded ·\nCarrying the wrong things"]
ASSESS --> TYPE["Choose the team type\nStream-aligned · Platform ·\nEnabling · Complicated-subsystem"]
ASSESS --> MODE["Choose the interaction mode\nCollaboration · Facilitating ·\nX-as-a-Service"]
TYPE --> PLAT["Platform charter\nWhat it owns\nWhat it does not"]
MODE --> PLAT
PLAT --> PATH["Golden paths better\nthan the dirt road"]
PATH --> SIG["📈 DevEx · DORA ·\nonboarding time ·\ncoordination overhead"]
The foundation:
Cognitive load is finite and accumulates without anyone deciding. Overloaded, under-bounded and carrying-the-wrong-things look identical from outside and need different fixes. Team types are claims about where load should sit; interaction modes are what actually control it, and collaboration and facilitating are transitional by design. The platform team is a load-absorbing interface whose charter must say what it does not own — and it is working when nobody needs to ask it for help. Golden paths only count if developers would choose them.
Cheat Sheet — All the key terms
| Term | What it names | The signal to watch |
|---|---|---|
| Cognitive load | Everything a team must hold in mind to work safely | Systems the team owns but cannot explain |
| Overloaded team | Owns more than it can sustainably hold | Delivery drag with no people explanation |
| Under-bounded team | Boundary does not enclose a complete flow of change | Nothing finishes without reaching outside |
| Wrong-shape load | Right size, wrong contents | Tooling or questions that belong elsewhere |
| Stream-aligned team | Owns a flow of change end to end | The default team type |
| Platform team | Provides capability so stream teams hold less | Stream teams rarely need to ask for help |
| Enabling team | Transfers a capability, then leaves | The interaction is designed to end |
| Complicated-subsystem team | Holds genuinely specialist domain knowledge | Deliberate exception, should be rare |
| Collaboration | Shared problem, high bandwidth, high load | Time-box it; cost does not fall over time |
| Facilitating | One team helps another acquire capability | Success is the interaction stopping |
| X-as-a-Service | Consumption through a defined interface | Lowest-load mode; the target for stable work |
| Golden path | The standardised, paved route through a common task | Must beat the dirt road or it is unused |
| Platform charter | What the platform owns and does not own | Prevents the platform absorbing the unclaimed |
How to know if this landed
You will know this has landed when someone stops asking "why aren't teams using the platform?" and starts asking "what do teams actually need?" When a proposed new responsibility triggers the question "what does this team stop holding in exchange?" When cross-team dependencies get treated as design failures rather than facts of life. And when the platform team's success is discussed in terms of how rarely it is needed, not how busy it is.
What changes when the mental model clicks
Platform teams range from startups with no platform at all to enterprises with platforms nobody uses. The gap at the start is rarely engineering quality — it is not treating developers as customers, and not treating team capacity as a designed quantity.
The cognitive load assessment tends to be the moment things click: teams everyone assumed were high performing turn out to be carrying far more than they can sustainably own. The interaction model design changes planning immediately — cross-team dependencies stop being inevitable and become design failures to be eliminated. And "developer resistance" stops being the diagnosis when the real problem was that nobody made the right way the easy way.
Where this comes from
This module runs alongside the Team Topologies & Organisational Design Workshop and the Platform Engineering & DevEx Strategy Workshop.
Book a Workshop
Ready to find out what your teams are actually carrying — and redesign the interfaces that put it there?
or
1-day intensive workshop includes a cognitive load assessment per team, team topology placement, interaction mode design, platform team charter drafting, golden path review, and a DevEx baseline.