I grew an engineering organisation from five people to more than a hundred while the platforms it built stayed live. The code was rarely what broke. What broke was who owned what.
Mel Conway put it in 1968: an organisation designs systems that copy its own communication structure (Conway, 1968). Hire fast without deciding that structure, and your architecture decides it for you, usually badly.
1. Draw the teams before you draw the services
Split teams along business flows, such as orders, payroll or onboarding, not along layers like "frontend" and "database". Team Topologies calls these stream-aligned teams, and warns that overloaded teams make poor decisions and move slowly (Team Topologies, 2026). If one change needs three teams to agree, your boundaries are in the wrong place.
2. Give every role one clear job
At five people everyone does everything. Past twenty, that becomes nobody doing the unglamorous parts. These are the role splits that worked for me:
| Role | Owns | Does not own |
|---|---|---|
| Engineering manager | People, hiring, delivery health | Technical design calls |
| Tech lead | Design, code standards, risk | Performance reviews |
| QA lead | Release quality, test strategy | Writing every test |
| Product manager | What gets built, and why | How it gets built |
3. Don't hire your way out of a deadline
Fred Brooks observed that adding people to a late software project makes it later (Brooks, 1975). New engineers need weeks of help from your busiest people. Hire ahead of the work, not into the middle of it.
4. Measure delivery, not activity
DORA tracks five delivery metrics, including change lead time, deployment frequency and change fail rate (DORA, 2026). Commits and tickets closed rise with headcount whether or not anything got better. If lead time grows as the team grows, your structure is the bottleneck.
5. Budget for debt on purpose
Rapid growth produces shortcuts. In my experience, reserving a fixed slice of every sprint for paying them down beats a "cleanup quarter" that never arrives.
Check your organisation
Score each 0 (no), 1 (partly) or 2 (yes):
- Boundaries: most changes ship from one team.
- Roles: each lead can say what they don't own.
- Hiring: new joiners land before the deadline, not during it.
- Metrics: lead time and change fail rate are tracked monthly.
- Debt: a fixed share of each sprint goes to it.
| Score | Next move |
|---|---|
| 8–10 | You can keep hiring; review boundaries every quarter. |
| 5–7 | Fix roles and boundaries before the next hiring round. |
| 0–4 | Pause hiring. Structure first, headcount second. |
Your next step
List your last ten production changes and count the teams each one needed. If the average is above one, redraw a team boundary before you open another job post.
Sources
- Conway (1968). Conway's Law, from "How Do Committees Invent?", Datamation, April 1968.
- Team Topologies (2026). Key concepts: team types and cognitive load.
- Brooks (1975). The Mythical Man-Month, chapter 2. Addison-Wesley.
- DORA (2026). DORA's software delivery performance metrics. Updated 5 January 2026.