How to Apply Team Topologies to a Startup Engineering Team

Team Topologies, the framework from Matthew Skelton and Manuel Pais, defines four team types and three interaction modes that between them describe how a well-functioning engineering organisation should be structured. The book is excellent. It is also written primarily with enterprise engineering organisations in mind. Applying it directly to a startup engineering team of ten or twelve people is not straightforward, and applying it without adjustment produces structures that are expensive to maintain and wrong for the scale.

This how-to covers what to use, what to skip, and what to adapt when applying Team Topologies at startup scale.

When to use this

This guide is for CTOs and engineering leaders at companies with 8–20 engineers who are starting to feel the friction of a flat team but are not yet large enough to run a full Team Topologies implementation. The framework is most useful when: delivery has started slowing down because too many people are involved in too many decisions; there is a shared infrastructure layer that multiple product areas need but no one clearly owns; or you have engineers who are working across everything rather than owning something specific.

The four team types — and which ones apply at startup scale

Stream-aligned teams are the main delivery teams in the framework. They own a product flow end-to-end — a user journey, a business capability — and can ship changes to that area without requiring significant coordination with other teams. At startup scale, these are your product squads. At 8–12 engineers, you will typically have one or two stream-aligned teams, not five.

If you only have enough engineers for one coherent squad, you effectively have one stream-aligned team. That is fine. The principle still applies: give the team clear ownership over a specific product area, and design their work so they can deploy independently. The Team Topologies label matters less than the practice of clear ownership and autonomous deployment.

Platform teams build internal capabilities that stream-aligned teams consume as a product. The critical distinction: a platform team reduces cognitive load for stream-aligned teams by abstracting infrastructure, deployment, observability, and shared services behind a clean internal interface. They do not take requests from stream-aligned teams — they publish capabilities.

At startup scale, a dedicated platform team is only warranted when: you have at least two stream-aligned teams with overlapping infrastructure needs; the infrastructure complexity is high enough to justify specialisation; and you have at least three or four engineers to dedicate to platform work. At eight engineers, a "platform team" is usually one engineer maintaining shared infrastructure as a secondary concern, which is fine to do without the formal structure.

Enabling teams work temporarily alongside stream-aligned teams to help them build a capability they currently lack, then move on. In practice at startup scale, this is usually a specific engagement rather than a permanent team — a consultant, an advisory relationship, or a TechTek engagement that up-skills the core team before stepping back.

Complicated-subsystem teams own technically complex areas that require specialised knowledge most engineers on stream-aligned teams should not need to carry. At startup scale, this is rare. If you have a machine learning subsystem, a real-time pricing engine, or a security-critical cryptographic component that genuinely requires deep specialisation to maintain, a dedicated owner makes sense. Most startups at 12–15 engineers do not have enough subsystems at that level of technical complexity to warrant this structure.

Step 1 — Map your current ownership

Before defining any team structure, spend an hour with your team documenting current ownership. For each major area of the system, answer: who makes decisions here? Who reviews changes? Who gets paged when something breaks?

The gaps — the areas where the answer is "everyone" or "whoever is available" — are where you need clarity most. These are the places where the flat team model has broken down and where Team Topologies language will help you assign genuine ownership rather than distributed accountability.

Step 2 — Identify your stream-aligned candidates

What are the distinct product areas in your system where end-to-end ownership would let a small team ship independently? At most early-stage startups, this maps closely to customer journeys rather than technical layers. The key question: could a team of three or four own this area from database to frontend without routinely depending on other teams to ship a feature?

If the answer is no because the area shares too much infrastructure with other areas, that shared infrastructure is your platform team candidate. Document it rather than trying to assign it to one of the squads.

Step 3 — Define your interaction modes

Team Topologies defines three interaction modes: collaboration (two teams working closely together on a shared problem), X-as-a-Service (one team consuming another team's output as a product), and facilitating (one team helping another build a capability). Getting these explicit prevents the most common failure mode: stream-aligned teams treating the platform team as a request queue rather than as a product they consume.

Write down, explicitly, how stream-aligned teams should interact with the platform capability. How do they request access? How do they raise issues? What is not the platform team's responsibility? These decisions prevent bottlenecks before they form.

Step 4 — Keep structures lightweight until you need formality

The most common mistake when applying Team Topologies at startup scale is implementing the full structural ceremony before you have the team size to support it. You do not need a formal platform team charter, a written interaction protocol, or team-specific Slack channels until the informal version has stopped working.

Start with the principles: clear ownership per area, a named person responsible for the platform capability, explicit documentation of how teams should interact. Add formality as the team grows and the informal version shows strain. The goal is to apply the thinking in Team Topologies, not to replicate the structure without the scale to justify it.

Common mistakes

Creating too many teams too early. If you have twelve engineers and you create three stream-aligned teams and a platform team, each team has two or three people — not enough to operate independently in practice. The minimum viable team to operate with genuine autonomy is usually four engineers. Below that, you are imposing overhead without the benefit.

Treating the platform team as a service team. A platform team that takes requests and produces bespoke solutions for stream-aligned teams is not a platform team — it is a shared services team, and it will become a bottleneck. The platform team's output must be a product with a defined interface, not a service with a ticket queue.

Defining teams before defining ownership. Team structure without clear ownership definitions produces the same problems as no structure at all. The ownership conversation must come first.

Summary

At startup scale, Team Topologies is most useful as a vocabulary and a set of principles rather than as a directly implementable structure. Use it to have clear conversations about ownership, to name the distinction between stream-aligned delivery and platform capability, and to define how teams should interact. Skip the formal structures until you have the team size to make them work.