You can apply Team Topologies at twenty engineers without turning it into a transformation programme. Most of the advice you'll find treats the framework as something that requires six months of workshops, a consulting engagement, and a steering committee. That is wrong, and it serves the consultants more than the engineering teams.
I've introduced Team Topologies concepts at organisations ranging from 12 to 60 engineers. The useful parts of the framework are immediately applicable at twenty people. The parts that become overhead before you're ready will slow you down. Here's the distinction.
What the Framework Actually Says
Team Topologies, for those who haven't read it, is a framework by Matthew Skelton and Manuel Pais for organising engineering teams to reduce cognitive load and improve flow. The core insight is that how you structure teams determines how information flows and what your software architecture will look like — Conway's Law as org design principle.
The framework defines four team types:
| Team Type | Primary Job | Interaction Style |
|---|---|---|
| Stream-Aligned | Own a domain end-to-end, from idea to production | Long-lived, autonomous, minimal dependencies |
| Platform | Provide shared capabilities that reduce stream teams' cognitive load | X-as-a-Service — self-serve tooling and infrastructure |
| Enabling | Temporarily upskill other teams, then step back | Short-lived engagement, coaching mode |
| Complicated-Subsystem | Own genuinely complex technical domains requiring deep specialisation | Limited interface, well-defined API |
At scale, this is a powerful framework. At twenty engineers, you don't have enough people to run four distinct team types simultaneously. The question is what to borrow, and what to defer.
What to Take Immediately
The stream-aligned team concept
The single most valuable idea in Team Topologies is the stream-aligned team: a small, cross-functional team that owns a product domain end-to-end. Not a frontend team. Not a backend team. A team that owns "payments," or "onboarding," or "the customer portal," and has all the skills needed to design, build, test, and deploy within that domain.
At twenty engineers, you probably have one or two of these, even if you haven't named them that way. The value of naming it is that it makes the team's mandate clear — they are not just executing tasks from a backlog; they are responsible for outcomes in their domain.
If you're still organising by technical layer (frontend / backend / infrastructure), and you have 15 or more engineers, now is the right time to reconsider. Layer-based teams create constant coordination overhead, handoffs at every ticket boundary, and a diffusion of accountability that makes it genuinely difficult to answer the question "who is responsible for the checkout experience?"
Domain teams answer that question cleanly. At twenty people, you can typically form two to three stream-aligned teams of four to six engineers, each owning a coherent product domain with a clear user-facing outcome.
Cognitive load as a design criterion
The other idea worth immediately importing is cognitive load as a concrete constraint on team design. Every team has a finite amount it can hold in context: the domain it owns, the codebase it operates, the dependencies it manages, the on-call surface it carries.
When a team's cognitive load exceeds what it can carry, throughput drops, quality drops, and engineers burn out. The symptom is usually misdiagnosed as "the team is underperforming," when the actual problem is "the team owns too much."
At twenty engineers, the question to ask of every team is: can two engineers, on-call on a Friday evening, understand the system well enough to diagnose and resolve a production issue without needing to wake up four other people? If the answer is no, the team's scope is too large or its knowledge too siloed.
The cognitive load test is more useful than the headcount calculation
The right team size is not six or eight people, as a rule. It's the size at which the team can own its domain without exceeding manageable cognitive load. A five-person team with a simple, well-documented domain is fine. A six-person team that owns authentication, payments, user permissions, and third-party integrations is overloaded regardless of headcount.
What to Defer Until You Actually Need It
A dedicated Platform team
The Platform team concept — a team that builds and maintains shared infrastructure, CI/CD, observability, and developer tooling as an internal product — is one of the most valuable ideas in the framework. It is also premature at twenty engineers.
A Platform team makes sense when you have enough stream-aligned teams that the duplication and inconsistency of each team owning its own tooling is costing more than the overhead of a dedicated team to standardise it. In my experience, that crossover happens somewhere around 40–60 engineers, not 20.
Before that, the right approach is to designate a senior engineer or technical lead who is responsible for shared tooling as part of their role — not as their full-time job. They define the CI/CD standard, own the observability setup, and are the person teams go to when they have infrastructure questions. This is not a Platform team. It is an individual with a clear mandate for shared concerns.
The reason this distinction matters is cost. A Platform team of three engineers at twenty total engineers means 15% of your engineering capacity is building internal tooling for the remaining 85%. That math only works when the 85% are producing enough value that standardised, self-serve tooling multiplies their output significantly. At twenty people, your stream-aligned teams can coordinate directly, and the overhead is low.
Enabling teams
At twenty engineers, you do not have the population to form dedicated Enabling teams — temporary teams that come alongside other teams to build capability and then step back.
What you do have, if you're deliberate about it, is senior engineers and technical leads who can play the enabling function informally. When a team is trying to introduce observability practices for the first time, a senior engineer who has done it before pairs with them for two to three weeks, helps them establish patterns, and then returns to their own work. That is the enabling function without the formal team structure.
The enabling function matters. The formal team structure does not, until you have the population to support it.
Complicated-Subsystem teams
These are specialised teams that own technical domains of genuine complexity — a machine learning engine, a regulatory reporting system, a custom payments processor. At twenty engineers, you probably don't have a true Complicated-Subsystem team need, and if you do, you likely have it already: it's the two or three people who are the only humans on earth who understand your core proprietary system.
The value of naming this pattern is making explicit that these people are not a general-purpose engineering resource. Their job is to maintain and evolve a system that others depend on, with a clean interface so that dependents don't need to understand the internals. If you have this situation, name it. It changes how you think about on-call rotation, documentation obligations, and what "moving someone to another team" means for organisational risk.
The Interaction Modes That Matter Now
Team Topologies defines three interaction modes between teams: Collaboration (working closely together to figure something out), X-as-a-Service (consuming a capability with a clean interface), and Facilitating (one team helping another build capability).
At twenty engineers, the interaction mode that most organisations get wrong is defaulting to Collaboration for everything. Two teams that should be operating as X-as-a-Service — one team consuming a stable API from another — instead have joint stand-ups, shared backlogs, and ad-hoc communication that creates coordination overhead without the accountability that comes from a clean interface.
The diagnostic question is: does this team need to understand the internals of that team's work, or do they just need a reliable, documented interface? If the latter, treat it as X-as-a-Service and enforce the interface discipline. Set a service-level expectation. Stop the joint stand-ups. Define the API.
At twenty engineers the interaction map typically looks like this:
Collaboration mode has a cost
Teams in permanent Collaboration mode with other teams are not stream-aligned in any meaningful sense. They're a component in a larger team that hasn't been structured as one. The symptom is that neither team can make a decision or ship independently. If this describes a pair of your teams, you have an org design problem that coordination overhead will not fix.
A Practical Starting Point for a 20-Person Org
Here's what I would actually do in the first 30 days if I were helping a 20-person engineering organisation apply this framework, without making it a programme:
For each team or informal group, list everything they are responsible for: features they own, systems they operate, on-call surfaces they carry, cross-team dependencies they manage. Make it visible. Most teams discover they own 30–40% more than they thought when they write it down.
Identify the two to four product domains that your engineering organisation serves. Assign clear ownership. If a domain is unclear or contested, that is the first design problem to solve — not who reports to whom.
For any two teams that depend on each other, decide whether the relationship is Collaboration (temporary, for a specific goal) or X-as-a-Service (stable interface, producer team owns reliability). If it's X-as-a-Service, document the interface and set an SLA. Stop the joint stand-ups.
Identify the senior engineer or technical lead who will own CI/CD, observability, and shared infrastructure as a responsibility — not as a full-time role, but as a clear mandate. This is your Proto-Platform function.
Revisit the cognitive load map. Is any team consistently slow, frequently blocked, or carrying on-call burden that requires more than two people to resolve? If yes, that team's scope is too large. Split the domain before you split the team.
The Part Nobody Says Clearly
Team Topologies is a vocabulary, not a prescription. The framework gives you language for conversations that organisations routinely have in the worst possible way — "why is team X so slow?", "why do we keep stepping on each other's toes?", "why does every feature require six teams to coordinate?"
The value at twenty engineers is that vocabulary. You don't need to implement the full topology. You need your engineering and product leaders to share a common model for how teams should relate to each other, what clear ownership means, and what an appropriate cognitive load looks like.
If you can align on those three things, you will have done more for your team's delivery performance than any structural reorganisation.
The reorganisation comes later, when you have the population to support it. At twenty engineers, you're planting the patterns that will scale. That's enough.
If you're thinking through how to structure your engineering organisation at this stage — or you're hitting coordination problems that feel structural — let's talk. Book a 30-minute discovery call and let's figure out what's actually broken and what just needs to be named.