Engineering Org Maturity Model: 0→25, 25→150, 150→500, 500+ — and the Predictable Break Points

60-Second Summary

Engineering organisations don't grow smoothly; they break at predictable sizes — ~25, ~150, ~500 engineers — for predictable reasons.
At ~25, the founder can no longer hold the whole context. First managers must be hired.
At ~150, Dunbar's number is reached and informal communication breaks. Platform, written decisions, and explicit org structure become non-negotiable.
At ~500, the central function model (HR, security, infra) reaches its limits. Federation begins.
The break points are not failures; they are transitions. Spotting them early is the leader's job.

Engineering organisations break in predictable ways at predictable sizes. ~25 engineers, ~150 engineers, ~500 engineers — these are not arbitrary numbers but reflections of human cognitive limits (Dunbar), communication complexity (Brooks's Law), and the limits of central functions. Founders and CTOs who can name the break points before they arrive can prepare. Those who can't experience them as a string of inexplicable, expensive failures. This article is the field-tested maturity model and the HR / leadership implications at each stage.

Why think in stages

Will Larson's An Elegant Puzzle (2019) and Camille Fournier's The Manager's Path (2017) both describe versions of this model. The shared insight: at each stage, the organisation works because of one specific operating logic. The logic that worked in the previous stage actively harms the next one. The CEO's habit of reviewing every PR works at 10 engineers and breaks at 30. The single platform team that owned everything works at 100 engineers and is a bottleneck at 400. Naming the stage is the precondition for designing the right intervention.

Stage 1: 0–25 engineers

Stage 1 characteristics

Dimension	What it looks like
Org structure	Founder is CTO. Everyone is an IC. Maybe one Tech Lead emerging.
Decisions	Made in chat or hallway. Speed is high, memory is short.
Hiring	Founder hires every person. Bar is implicit but consistent.
Tools	Whatever each engineer brings. Heterogeneous and rapidly evolving.
HR	Founder + first People Ops generalist if any. Recruiting outsourced or founder-led.
Failure mode	Founder bottleneck on every decision; specific team members essential and burnout.

Stage 1 trap

Building too much process too early. At 15 engineers, an ADR template, a promotion rubric, and a quarterly OKR cycle is over-engineered. Buy the books, read them, don't implement them yet.

Stage 2: 25–150 engineers

Stage 2 characteristics

Dimension	What it looks like
Org structure	First managers hired (often promoted from within). 3–6 stream-aligned teams emerging.
Decisions	Mix of chat, doc, and meeting. Increasing confusion about who decides what.
Hiring	Recruiters hired. Loops formalising. First debrief disagreements happen.
Tools	Platform team begins (often 'DevOps'). Consolidation pressure.
HR	First HRBP hired. Compensation bands drafted. Performance reviews formalised.
Failure mode	Inconsistent quality across teams; first major attrition wave; founder loses context.

Stage 2 must-haves (do these or break)

1
Levelling rubric
Written, with specific behaviour examples. Without it, the next 30 promotions are political.
2
First-time manager training
First-time managers fail at 50%+ rate without explicit support. Budget for it.
3
Promotion packet process
Even rough. The artefact is more important than the rubric in early days.
4
On-call rotation design
Not 'whoever is awake'. Explicit, with secondary, with paid or comp-time recognition.
5
ADR practice
Lightweight. Stop losing institutional memory each time someone leaves.

Stage 3: 150–500 engineers

Stage 3 characteristics

Dimension	What it looks like
Org structure	Engineering directors layer. Platform group formalised. Cross-team coordination roles.
Decisions	RFCs and ADRs mandatory for org-level decisions. Decision speed slows; decision quality rises.
Hiring	Bar-raisers introduced. Calibration meetings formalised. Diversity reporting starts.
Tools	Paved-road platform. Heterogeneity reduced. Internal developer platform investment.
HR	HRBP per ~150 engineers. Comp committee. Talent management as a discipline.
Failure mode	Org structure debt; layers proliferating; Senior+ ladder unclear; siloed knowledge.

Dunbar's number arrives

Around 150 engineers, the informal trust network breaks. The CTO no longer knows everyone. Engineers no longer know each other across teams. Communication that worked organically must now be designed deliberately. This transition is the single biggest structural shock in the model.

Stage 4: 500+ engineers

Stage 4 characteristics

Dimension	What it looks like
Org structure	Multiple engineering VPs. Engineering councils. Federated platform model (multiple platform groups).
Decisions	Strategic decisions at exec/council level; tactical decisions devolved deeply.
Hiring	Sophisticated talent function; multiple sourcing channels; structured employer brand work.
Tools	Internal Developer Platform mature; production-grade. Platform-as-product is real.
HR	HR centres of excellence (talent, comp, L&D, DEI) separated from HRBP partner model.
Failure mode	Central functions become bottlenecks; federation tension; cultural variance across BUs.

Diagnosing a transition

Most break points announce themselves with the same symptoms 6–12 months ahead. The leader's job is to spot them.

Symptoms of an approaching break point

Symptom	Likely stage you are leaving	What to do next
Founder/CTO can no longer name every engineer	Stage 1	Hire managers; design teams; introduce levelling rubric
Same conversation happens repeatedly across teams	Stage 2	Introduce written decisions (ADRs); name a platform team owner
Cross-team launches take 3+ quarters	Stage 3	Federate; redesign team boundaries; invest in internal platform
Engineering quality varies by BU	Stage 4	Engineering council; shared standards with local autonomy
Promotion debates dominate calibration	Any stage	Tighten rubric; publish past packets; train calibration chairs

HR implications by stage

Stage 1: HR is recruiting + the basics. Don't over-build.
Stage 2: HRBP partnership is the highest-leverage hire. First-time manager training is non-negotiable.
Stage 3: Calibration, compensation, and DEI become formal disciplines. HR-to-engineer ratio matters; aim for 1 HRBP per 100–150 engineers in engineering.
Stage 4: Centres of excellence emerge. Federation tension between central HR and BU HR is real and predictable; design for it.

Monday-morning checklist

Identify the stage you are in (or transitioning out of). Disagreement is the data.
Identify the one missing must-have from this stage. Build it this quarter.
Identify the one habit from the previous stage that is now hurting you. Stop it this month.
Schedule an annual maturity-model review with the engineering leadership team.

FAQ

Frequently asked questions

What about platforms / specific industries with different numbers?

The numbers shift modestly (regulated industries break earlier; consumer apps later) but the structural transitions are remarkably consistent across SaaS, fintech, marketplaces, and consumer.

Can we skip a stage by hiring leadership from a later-stage company?

Partially yes. A VP eng from a Stage 4 company brings the vocabulary and instincts of a later stage. They cannot, however, install Stage 4 mechanics into a Stage 2 org without breaking it. Pace matters.

What about remote-first companies?

Same stages, but transitions are slightly earlier (the informal trust network breaks before 150 in fully-remote orgs). Invest in explicit communication earlier.

How does AI tooling change the model?

Probably compresses Stage 1 and Stage 2 (smaller teams can build more) but does not change the structural break points themselves. Dunbar's number is a brain limit, not a productivity one.

References

Will Larson — An Elegant Puzzle: Systems of Engineering Management (2019) — lethain.com
Camille Fournier — The Manager's Path (O'Reilly, 2017) — O'Reilly
Fred Brooks — The Mythical Man-Month (1975) — Wikipedia summary
Skelton & Pais — Team Topologies — Team Topologies

Written by Pawan Joshi.Sources cited inline.

First published 15 Jun 2026See site changelog →