Team Topologies in Practice: What the Four Team Types Look Like at 60 Engineers

Team Topologies by Matthew Skelton and Manuel Pais is the most useful organizational framework for engineering leaders at Series A–C companies. It is also written with enterprise-scale case studies in mind, which makes direct application difficult when you have 60 engineers and three layers of management instead of six.

The framework is worth working through anyway. The concepts are sound and apply regardless of org size. The translation work is figuring out what each team type means at your scale, where the right simplifications are, and which patterns the book describes that you genuinely do not need yet.

The four team types

Skelton and Pais define four team types, each with a different primary purpose. At smaller scales, these categories often blend or are filled by partial headcount, but understanding the distinct purposes clarifies the organizational goals.

Stream-aligned teams own a flow of work end-to-end, from user-facing feature through deployment and on-call. They are responsible for the outcome, not just the output. In a 60-engineer organization, stream-aligned teams are most of your teams — typically five to seven teams of four to eight engineers, each owning a product area or service domain. They build, ship, and operate their own services.

Platform teams reduce cognitive load on stream-aligned teams by providing self-service internal capabilities: deployment tooling, observability, testing infrastructure, local development environments. Their customers are the stream-aligned teams. They operate as an internal product team with a backlog and internal customers. At 60 engineers, one platform team of three to four engineers is the appropriate scale.

Enabling teams accelerate adoption of a new practice or capability across stream-aligned teams. They are temporary by design — they work alongside stream-aligned teams to raise a specific capability, then exit. An enabling team is not a permanent fixture of your org chart. It is a time-bounded investment in acceleration. At Series A–C, this is often where an external engagement fits: a team that comes in, raises the platform capability, and leaves.

Complicated-subsystem teams own a part of the system that requires specialist knowledge that stream-aligned teams cannot reasonably maintain. A payments engine, an ML inference layer, a real-time data pipeline — systems where the domain complexity is high enough that general-purpose engineers cannot context-switch in and out safely. At 60 engineers, you may have one of these or none. Most Series B companies do not have a genuinely complicated subsystem yet. If you are building one to seem sophisticated rather than because the problem demands it, that is a warning sign.

What this looks like at 60 engineers, specifically

Five to seven stream-aligned teams is the right shape at this scale. Each team owns its domain, runs its own deployments, carries its own on-call rotation, and has the product and engineering judgment to make decisions within its area without escalation. The autonomy is the point — it is what lets five teams work in parallel instead of in sequence.

One platform team of three to four engineers. Their job is to make the stream-aligned teams faster, not to control them. The platform team builds and maintains the golden paths: the documented, automated, reliable ways to build, test, deploy, and observe. Stream-aligned teams can use the golden paths without asking. If they have to ask, the platform team has a new product requirement.

Complicated subsystem: one team if you have something genuinely warranting specialist ownership. Payments and ML are the two most common cases at Series B. Neither requires a dedicated team unless the internal complexity is high enough that having general-purpose engineers maintain it creates real risk. Be honest about whether the system is complicated or whether it is complex because it was not designed carefully.

Enabling: this is not a permanent organizational structure. It is a temporary engagement pattern. An external team that spends three to six months working with your platform team to build a foundational capability is operating in the enabling role. When the capability is built and adopted, the enabling team exits. A Clouditive engagement fits this pattern — it is designed to produce a capability that the organization then owns, not a dependency on the external team.

The interaction modes in practice

Team Topologies also defines three interaction modes — the ways teams work with each other — which are as important as the team types.

X-as-a-service is the default interaction between platform teams and stream-aligned teams. The platform team delivers self-service capabilities. Stream-aligned teams use them. There is no ticket. There is no coordination. The platform team's job is to make the interaction as close to zero-cost as possible.

Facilitating is the enabling team interaction mode. A temporary team works alongside stream-aligned teams to help them adopt a new practice or capability. The goal is to transfer the capability, not to create a dependency. When facilitating is done well, the enabling team has worked itself out of a job.

Collaboration is a time-bounded mode where two teams work together on something that neither can own alone. A new service that requires deep platform knowledge and deep product knowledge simultaneously. A security redesign that crosses platform and product boundaries. Collaboration mode is expensive — it requires significant coordination overhead — so it should be deliberate and time-limited. The default is X-as-a-service, and collaboration is the exception when X-as-a-service breaks down.

The mistake that appears most often

The most common Team Topologies mistake in growing engineering organizations is treating the platform team as a service desk rather than as a product team with internal customers.

The service desk model says: the platform team responds to platform requests. Engineers open tickets. The platform team does the work. This model seems safe because it is familiar and controllable. The platform team does not ship anything the business has not explicitly asked for. In practice, it is the bottleneck model described above — the platform team's queue grows proportionally with the engineering organization, and the stream-aligned teams are only as fast as the platform team's ticket throughput allows.

The product model says: the platform team owns a product whose customers are internal engineers. They do discovery by talking to internal customers. They prioritize a backlog by impact. They ship self-service capabilities that reduce tickets rather than responding to tickets. They measure success by adoption, not throughput. The difference is structural and intentional, not just a matter of framing.

When you apply Team Topologies in the product model, the platform team has an explicit backlog, internal customer interviews, and a roadmap. The stream-aligned teams have a clear, stable interface for getting platform capability — and they mostly do not need to interact with the platform team at all for routine operations. The cognitive load reduction that Team Topologies promises depends on this model working.

The detailed treatment of platform team sizing, ownership boundaries, and the product mindset requirement is in platform team structure. The cognitive load concept that Team Topologies builds on is covered in the cognitive load glossary entry. For organizations working through whether to build this internally or work with an external enabling team, platform engineering consulting covers the decision in practical terms.