Scaling Architecture.
Grow the system and the org together. Service boundaries that match team boundaries that match business boundaries. Neither becomes the bottleneck.
The practices that get you to twenty engineers actively harm you at fifty.
Why teams stall at twenty.
The problem isn't hiring. It's what happens to decision-making, communication, and ownership.
At ten engineers, everyone knows everything. Coordination happens in Slack. Decisions happen in hallways. Culture is what the founders do. It feels scrappy, fast, aligned.
At thirty, the same patterns break. Slack becomes noise. Hallway decisions exclude half the team. New hires don't understand "how we do things." Velocity drops. Politics emerge. Good people leave.
The practices that get you to twenty engineers actively harm you at fifty.
Four answers to predictable failure modes.
Growth creates predictable failure modes. These four pillars address them systematically.
Team topology
Define how teams form, own domains, and interface with each other. Move from functional teams (frontend / backend) to product teams with clear outcomes.
Decision rights
Who decides what, and when. Predictable cycles for planning, review, and coordination. Minimise meetings while maximising alignment.
Documented decisions
Shift from synchronous tribal knowledge to documented decisions and architectural records. Information becomes discoverable, not dependent on who you know.
Values that scale
Encode values into systems: promotion criteria, code review standards, incident response. Culture can't rely on osmosis when new hires never meet the founders.
Counterintuitive, made explicit.
Scaling rewards the rules that feel wrong at first. These five make the implicit explicit.
Topology before talent
Get the team structure right before hiring. A great engineer on a poorly-scoped team will either leave or become ineffective. Define ownership, interfaces, and success metrics first.
Ownership over consensus
At ten engineers, everyone weighs in. At fifty, that's paralysis. Clear ownership beats democratic debate. Assign DRIs. Gather input, one person decides.
Document the why
Decisions need context to survive team growth. "We decided X" isn't enough. Write down the problem, the alternatives considered, the tradeoffs accepted. Future you will thank you.
Explicit over implicit
What worked with ten people breaks with fifty. Make implicit norms explicit. How do we prioritise? When do we refactor? Document the unspoken rules while they still work.
Culture through systems
Values get encoded in process. If you value quality, what does code review enforce? If you value ownership, how do promotions reflect it? Culture is what you reward and tolerate.
Useful for, and not.
A framework earns its keep by being clear about what it doesn't do.
Use it when
- You're between fifteen and thirty engineers and velocity is dropping.
- New hires ask "how do things work here" and get different answers.
- Cross-team coordination is becoming a bottleneck.
- You're planning to double engineering in twelve months.
- Good engineers are leaving citing chaos.
Don't use it when
- You're still under ten engineers, structure will slow you down.
- You're not planning growth beyond your current size.
- Your business model is still unproven, solve that first.
- Leadership lacks buy-in for organisational change.
- You want a template to copy-paste, context matters.
Is this the wall you're hitting?
If velocity has dropped and the same patterns keep breaking, the next move is structural, not tactical.