How to Structure Your Engineering Team as You Scale

Most engineering team structure decisions get made by accident. The team grows from two to five to ten, and whatever pattern of working emerged in the early days calcifies by default into the structure that runs as the company scales — until it stops working. This guide covers how to structure an engineering team deliberately: the right models by stage, the principle that governs all of them, and the mistakes that make restructuring harder than it needs to be.

The problem

The moment a flat team starts breaking is almost always the same: you have more engineers than you can fit in one decision-making conversation.

At three or four people, everyone knows what everyone is building. Blockers surface immediately. The whole team can align on a change in one Slack message. At eight or nine, that stops being true. Decisions slow down because everyone expects to be consulted on everything. Ownership gets blurry because multiple people feel entitled to weigh in on every area of the codebase. Shipping slows — not because the engineers are less capable, but because the coordination overhead has become the bottleneck.

That inflection point, usually somewhere between five and ten engineers, is when team structure stops being an afterthought and starts being a delivery problem.

The governing principle: Conway's Law

Before choosing a team model, it is worth understanding why any structure matters in the first place.

Mel Conway observed in 1967 that organisations design systems that mirror their communication structures. However your team is divided, your software will eventually reflect those divisions.

This cuts both ways. A team structured around technical layers — frontend team, backend team, infrastructure team — will tend to produce systems with sharp technical boundaries, and business features that require cross-team coordination will move slowly. A team structured around product areas or user journeys will tend to produce systems with product-shaped boundaries: faster for features, messier for shared infrastructure.

Neither is inherently right. But choosing a team structure without understanding this is how you end up with a software architecture you did not mean to build. There is a separate piece in this series that covers Conway's Law in more depth.

The main models

Functional teams group engineers by discipline: a frontend team, a backend team, a data team, a platform team. Technical ownership is clear. This works well when specialisation matters more than speed and when features rarely require all disciplines to coordinate on the same thing at the same time. It breaks down when shipping a feature means scheduling meetings across multiple teams every sprint.

Cross-functional product squads are small teams — typically three to seven people — with all the skills needed to own and ship a specific product area end-to-end. They can make decisions and deploy without depending on another team. Associated with the Spotify model, though Spotify itself moved away from pure squads as it grew beyond a certain size. Works well when speed and product ownership matter more than deep technical specialisation. Breaks down when too many squads need to touch the same shared infrastructure, or when you do not have enough senior engineers to staff each squad credibly.

Team Topologies, the framework from Skelton and Pais, takes a more precise approach. It recognises that not all teams serve the same purpose, and conflating them creates invisible friction. Four types:

• Stream-aligned teams own a product flow end-to-end. They are the primary delivery units.
• Platform teams build internal products that stream-aligned teams consume, reducing cognitive load rather than creating dependencies.
• Enabling teams work temporarily alongside stream-aligned teams to build a capability those teams currently lack, then move on.
• Complicated-subsystem teams own technical areas that require specialised knowledge most stream-aligned teams should not need to carry.

The most common structural mistake at scale is treating a platform team as a dependency rather than a product. A platform team that stream-aligned teams have to wait on reproduces the bottleneck the structure was supposed to remove. See the guide on applying Team Topologies at startup scale for the practical steps.

Choosing by stage

3–6 engineers: Structure almost does not matter. Everyone knows everything. The coordination overhead of a formal model costs more than it saves at this size. Focus on clear code ownership, not org design.

7–12 engineers: Flat is starting to break. This is where explicit ownership — who is responsible for which part of the system and who has the final say — matters more than which org model you choose. Define ownership before you define teams.

12–20 engineers: You need a deliberate structure. If you are shipping features across multiple product surfaces and speed is the constraint, cross-functional squads. If you are building technical depth and your product areas share a lot of infrastructure, functional teams with clear interface contracts are easier to maintain.

20+ engineers: The Team Topologies framework is worth learning properly at this stage. The distinctions between stream-aligned, platform, enabling, and complicated-subsystem teams start to matter in ways the functional vs cross-functional question does not fully capture.

The AI-native dimension

Most team design frameworks were written before AI-assisted development became standard practice. When a senior engineer with Cursor or Claude Code can cover what previously required three mid-level engineers, the headcount assumptions that underpinned a lot of team design thinking start to shift.

Smaller teams with higher average seniority and AI tooling are becoming a credible alternative to larger teams at earlier stages. This does not change the underlying principles — Conway's Law still holds, ownership still matters — but it changes where the inflection points are and what a "small team" can actually produce. A separate piece in this series covers the implications for hiring and team composition in more detail.

The decision framework

Before restructuring, answer three questions:

1. Where is the delivery bottleneck? Coordination? Unclear ownership? A capability your team does not have? Structure only fixes coordination problems. It does not fix capability gaps or unclear priorities.
2. What does your software architecture look like today? Your team structure and system design need to be consistent with each other, or you will fight both simultaneously. Conway's Law means you cannot restructure the team without also thinking about what the restructure will do to the system over time.
3. What are you optimising for in the next 12 months? Speed of shipping features, technical depth, or scaling infrastructure? The right team structure follows the answer to this, not the other way around.

What to do next

If the bottleneck is unclear — whether it is the team structure, delivery practices, or velocity generally — the Engineering Velocity Scorecard identifies where time is actually being lost before you commit to a restructure that might not address the real problem. Free, takes about ten minutes.

If the structure is not the issue but the team feels like it is outgrowing its current technical leadership, that is a different problem. The Engineering Advisory service page covers what TechTek does in that space.