Scaling teams without scaling chaos
Headcount is the easy part. Keeping decision latency low as a team grows is the real work.
Most scaling pain is not technical. It is the growing distance between the person who notices a problem and the person allowed to fix it.
Optimise for decision latency
Track how long it takes for a small decision — a schema change, a dependency bump, a rollback — to be made and executed. When that number grows, velocity falls no matter how many engineers you hire.
The fix is ownership with a clear blast radius: each team owns services end to end, including deploys and on-call, and can move inside that boundary without asking.
Hire for the seam, not the stack
The hardest roles are rarely 'a senior React developer'. They are the people who can hold two systems in their head at once and design the seam between them. Those hires unlock everyone else.
Keep the platform boring
A predictable platform — one build, one deploy path, one observability story — buys back more capacity than any framework migration. Novelty belongs in the product, not the pipeline.