When a software company grows, the first reaction is to hire. More people, more speed: it sounds logical. Yet past a certain point, adding developers doesn't just fail to speed up delivery; it slows it down. Estimates get worse, releases become more complicated, and teams spend more time coordinating than writing code.
The problem isn't the people. It's the structure. And Team Topologies, the model created by Matthew Skelton and Manuel Pais, offers a concrete language for tackling it.
This article translates those principles into operational decisions for anyone running a company: not organisational theory, but choices that directly affect the speed of your software.
Why team structure determines the speed of your software
Conway's law, formulated in 1967 and confirmed by decades of practice, says that the structure of software reflects the structure of the organisation that produces it. It isn't a suggestion; it's a physical constraint.
If teams are organised by technology (a frontend team, a backend team, an infrastructure team), the software will end up with three coupled layers. Every feature will require coordination across all three. Every release will become a multi-team project.
If teams are organised by business domain (a payments team, a catalogue team, a logistics team), the software will naturally tend towards independent modules. Each team will be able to release independently, because it owns the entire flow from the user interface through to the data.
Organisational structure isn't an administrative detail: it's an architectural decision.
The four team types
Team Topologies defines four fundamental team types, each with a precise purpose:
- Stream-aligned teams: the main delivery teams. Each one is responsible for a stream of value to the business (a product, a feature, a customer segment). They own everything needed to release: code, tests, deployment, monitoring. Most teams in an organisation should be this type.
- Platform teams: build and maintain the internal platforms that give stream-aligned teams their autonomy. CI/CD pipelines, infrastructure, monitoring tools. Their product is the developer experience of the other teams.
- Enabling teams: work alongside stream-aligned teams temporarily to transfer specific skills. They don't do the work for others; they make others capable of doing it. They're temporary by design: once the team has picked up the skill, the enabling team steps back.
- Complicated-subsystem teams: manage parts of the system that require deep specialist expertise (calculation engines, complex algorithms, security components). They exist because the cognitive load of that subsystem would exceed what a generalist team could handle.
The fundamental rule: every team needs to know clearly which type it is. If it doesn't, it's probably doing a bit of everything, and that's part of the problem.
Cognitive load: the invisible limit
Every team has a limited cognitive capacity. That's the amount of knowledge it can hold at once: the codebase, the tools, the processes, the business domains. When that capacity is exceeded, productivity collapses, mistakes increase, and onboarding new people slows to a crawl.
Three types of cognitive load weigh on teams:
- Intrinsic load: the complexity of the business domain itself. It's unavoidable, and has to be accepted.
- Extraneous load: complexity the team is lumbered with but shouldn't have to manage. Badly configured tools, bureaucratic processes, infrastructure that needs manual upkeep. This load should be eliminated: that's the job of platform teams.
- Germane load: the complexity of the technical choices the team has to make to solve business problems. This load needs to be handled well.
Reducing cognitive load is more effective than adding people. A team with a manageable load delivers faster than a team twice the size carrying an excessive one. That's why adding developers often doesn't improve speed: if cognitive load stays the same, more people just means more coordination.
The three interaction modes
Team Topologies doesn't just define team types: it also defines how they should interact. Three modes, each with a specific purpose:
- Collaboration: two teams work together, side by side, for a limited period. It's useful when exploring a new domain or building something neither team could do alone. It's temporary: if it goes on for more than a few weeks, something isn't working.
- X-as-a-Service: one team provides a service to another through clear, documented interfaces. The team consuming the service doesn't need to know how it works internally. It's the target mode for most interactions.
- Facilitating: an enabling team works alongside a stream-aligned team to transfer skills. It doesn't do the work; it teaches others to do it. Facilitating has an end date: once the team is self-sufficient, the interaction ends.
If two teams need to coordinate constantly without fitting into any of these modes, that's a signal: the boundaries between the teams (and between the software modules they own) are in the wrong place.
How to apply these principles in an SME
Team Topologies grew out of experience with large organisations, but the principles apply just as well with 3 or 4 teams. The scale changes; the constraints stay the same.
With our Embedded Teams service, we often join as an extra team in organisations that haven't yet adopted any organisational design framework. What we see almost every time is the classic version of the problem: teams organised by technology — frontend, backend, mobile, data — rather than by business domain. Every feature needs coordination across every team. Moving to domain-based teams looks simple on paper. In practice it takes 6 to 12 months, not because of technical difficulty, but because it means redesigning ownership, responsibilities and interfaces between teams — while the product keeps being built.
In an SME with 15 to 30 developers, the concrete actions are:
- Organise teams by business domain, not by technology: the "payments" team owns the entire flow (frontend, backend, data); there's no separate "frontend team". Every team can release independently.
- Set up a minimal platform team: even just one person dedicated to maintaining the CI/CD pipeline, monitoring and development tools. The aim is that stream-aligned teams don't have to worry about infrastructure.
- Measure cognitive load: if a team manages more than 2 or 3 independent components, the load is probably excessive. Reducing it, even by redistributing responsibilities, is more effective than hiring.
- Make interaction modes explicit: every pair of teams needs to know whether they're collaborating, consuming a service, or in a facilitating relationship. Ambiguity generates implicit coordination, which is the most expensive kind.
If your current team structure doesn't reflect these principles, restructuring doesn't have to be a big bang. You start with one team, confirm it works, and expand from there. It's the same incremental approach we apply with our Embedded Teams service.
What to do in practice
Three things to do this week:
- Draw the current map: which teams exist, what they own, how they interact. Put it all up on a whiteboard. If the drawing is confusing, so is the organisation.
- Identify the team with the most dependencies: it's the one that gets blocked most often waiting on other teams. Dependencies between teams are the most visible symptom of a misaligned structure.
- Reduce one team's load: pick a team and take away a responsibility it shouldn't have. A component that could belong to another team, a tool the platform team could manage instead. Just one change, to see the effect.
Team structure isn't an org chart to update once a year. It's an architectural decision that needs revisiting every time the product, the market or the organisation changes. Design it with intent and you move faster; leave it to chance and you slow down.