The way you structure your engineering team is one of the most consequential and least-discussed decisions in a growing technology organisation. Get it right and you have a high-velocity, autonomous organisation that scales delivery as headcount grows. Get it wrong and you have a coordination nightmare where adding engineers makes you slower, not faster.
The core insight from Melvin Conway's 1967 observation — still known as Conway's Law — is that "organisations which design systems are constrained to produce designs which are copies of the communication structures of those organisations." Your architecture will mirror your team structure. Your team structure will mirror your product. Design your team deliberately or it will design itself — usually poorly.
The Structure for Each Growth Stage
Stage 1: The Early Team (1–8 Engineers)
At this stage, the team is essentially a single-cell organism. Everyone does everything. There's usually one tech lead (the founding engineer or CTO) who makes most of the technical decisions and has a small number of full-stack engineers.
What works at this stage:
- Daily informal syncs (Slack is enough)
- No formal process beyond a shared backlog
- Flat hierarchy — everyone can talk to anyone about anything
- One codebase everyone knows well
What starts to break as you approach 8:
- The tech lead or CTO becomes a bottleneck — all decisions route through one person
- "Tribal knowledge" — critical knowledge lives in individuals' heads, not documentation
- Onboarding new engineers takes too long because there's no structured process
- Codebase complexity starts to exceed what everyone can hold in their head simultaneously
The intervention needed: Begin writing things down. Architecture decision records (ADRs). A proper README. A runbook for your most critical processes. Invest in this before you need it.
The 5-person documentation debt
At five people, your documentation debt is small. At fifteen, it's crippling. The cost of writing an ADR now is an hour. The cost of not writing it — when you have 12 engineers who all understand the system differently — is weeks of misalignment and rework.
Stage 2: First Team Splits (8–20 Engineers)
At some point between 8 and 12 engineers, the single team becomes untenable. Too many people are working on too many things for effective coordination.
The transition: Split into two or three teams, each with clear ownership of a product domain or technical area. The structure that works best at this stage depends heavily on your product:
Product domain teams (recommended): Each team owns a bounded slice of the product — e.g., Onboarding, Core Product, Platform. Teams are full-stack (front-end, back-end, often QA). They have end-to-end ownership of their domain and can ship independently without coordinating with other teams.
Functional teams (common but often problematic): Front-end team, back-end team, DevOps team. This creates handoff points and coordination overhead on every feature. It is the natural-looking structure and frequently the wrong one.
Who should lead each team: Engineering managers (EMs) or Tech Leads. At this stage, the EM and Tech Lead are often the same person, but as you approach 20 engineers, you'll need to separate these roles — engineering management (people, process, delivery) from technical leadership (architecture, quality, technical direction).
What breaks at 20:
- The coordination overhead between two or three teams grows — shared codebases, shared infrastructure, shared APIs become coordination points
- You need a principal engineer or VP of Engineering level to own cross-team technical decisions
- Hiring quality becomes critical — one wrong hire in a 15-person team is far more damaging than in a 150-person team
Stage 3: Scaling to Product Teams (20–50 Engineers)
This is where most high-growth scaleups operate and where team topology decisions have the most dramatic impact on delivery velocity.
The Team Topologies approach (from the book by Skelton and Pais) provides a useful framework:
- ✓End-to-end product ownership
- ✓Full-stack capability
- ✓Flow of work from idea to production
- ✓Most of your engineering capacity
- ✓Shared infrastructure
- ✓Internal developer platform
- ✓CI/CD, observability, security
- ✓Reduces cognitive load on stream teams
- ✓Temporarily helps other teams
- ✓Security, ML, data engineering
- ✓Builds capability then steps back
- ✓Avoids permanent dependencies
- ✓Requires deep specialist knowledge
- ✓Payments, ML engine, regulatory
- ✓Small, highly specialised
- ✓Used sparingly
Stream-Aligned teams own product domains. The Platform team reduces friction. Enabling teams temporarily up-skill. Complicated-subsystem teams handle genuinely complex technical components.
The stream-aligned team model is the engine of delivery. Each team owns a product stream end-to-end — user research through production monitoring. They have the capability to work independently without depending on other teams for most changes. Coordination is by exception, not default.
The platform team is the force multiplier. A team of 3–5 engineers who build the internal developer platform: the CI/CD pipelines that work the same way for every team, the observability stack that every team uses, the infrastructure abstractions that mean stream teams can deploy without becoming cloud experts. The platform team's KPI is reducing cognitive load on other teams.
What breaks at 50:
- The informal communication networks that coordinated teams at 20 break down
- Architecture divergence — teams make different technical decisions because there's no coordination mechanism
- The platform team is overwhelmed if underinvested — don't make the platform team 3 people for a 50-engineer organisation
The Roles You Need at Each Stage
| Headcount | Roles needed |
|---|---|
| 1–5 | Technical co-founder / Lead engineer |
| 5–15 | Engineering manager (first hire), senior engineers |
| 15–25 | VP of Engineering or CTO, Principal/Staff engineer |
| 25–50 | Engineering directors, multiple senior ICs, Data engineer, Platform engineer |
| 50+ | Chief Architect, multiple EMs, Dedicated security/compliance engineering |
The EM vs. Tech Lead distinction
Many companies conflate engineering management (running the team, career development, delivery) with technical leadership (architecture decisions, technical quality). These are different jobs requiring different skills. Great engineers often make poor EMs, and great EMs often don't want to be the technical authority. As you scale past 15 engineers, you usually need both roles to be filled explicitly.
Common Structural Mistakes
1. Keeping everyone on one team for too long
The coordination overhead of 15 people on one team is enormous. Splitting into two teams of 7–8 actually accelerates delivery — less time coordinating, more time building. Most founders resist the split because it "feels like splitting the team." It actually splits the work, not the culture.
2. Creating functional silos
"Front-end team, back-end team, DevOps team" creates coordination overhead on every feature. The front-end team finishes their work and waits for the back-end team, who waits for DevOps, who has a queue. End-to-end feature delivery becomes a project management challenge.
Full-stack product teams — owning a domain from front to back — eliminate most of this coordination overhead.
3. Scaling the team before scaling the process
Doubling the team without doubling the clarity about how decisions are made, how code is reviewed, how incidents are handled, and how priorities are set creates chaos. The new engineers can't be effective because the organisation doesn't know how to absorb them.
The fix: For every 2–3 engineers you hire, invest one sprint in process: update documentation, improve onboarding, clarify decision-making, strengthen CI/CD.
4. The hero culture
When your organisation has heroes — individual engineers who are the only people who understand critical systems, who are always the person called during incidents, who are a bus-factor-of-one for key capabilities — you have a structural problem disguised as an individual performance one.
Heroes feel valuable. They're actually a risk: when they leave, get sick, or burn out, the organisation is exposed. The fix is not to reduce their contribution but to systematically eliminate single points of knowledge: pair programming, documentation, rotating incident response, knowledge-sharing sessions.
The DORA Metrics as Structural Health Indicators
DORA (DevOps Research and Assessment) metrics — Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Mean Time to Recovery — are the best available proxy for engineering team structural health.
| Metric | Elite | High | Medium | Low |
|---|---|---|---|---|
| Deployment Frequency | Multiple/day | Daily | Weekly | Monthly |
| Lead Time | <1 hour | <1 day | <1 week | >6 months |
| Change Failure Rate | <5% | <10% | <15% | >30% |
| MTTR | <1 hour | <1 day | <1 day | >1 week |
If your deployment frequency is weekly and your lead time is months, the problem is almost never the engineers — it's the structure, process, and tooling. Fix those before adding more engineers.
Team structure is one of the most impactful levers a technology leader has. If you're navigating a growth inflection point and want an experienced perspective on how to structure your engineering organisation, let's talk.