Framework
What happens when your team grows from 10 to 50?
A structured framework for scaling engineering teams through the 20-engineer ceiling. Navigate team growth with proven patterns for structure, process, communication, and culture.
The 20-engineer ceiling.
Most teams hit a wall between 15 and 25 engineers. The problem isn't hiring—it's what happens to decision-making, communication, and ownership.
At 10 engineers, everyone knows everything. You coordinate in Slack. Decisions happen in hallways. Culture is what the founders do. It feels scrappy, fast, aligned.
At 30 engineers, 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 20 engineers actively harm you at 50.
Scaling Architecture provides the structure, process, communication patterns, and cultural systems that make growth sustainable instead of chaotic.
Four pillars of scale.
Growth creates predictable failure modes. These four pillars address them systematically.
Structure
Team topology, ownership boundaries
Define how teams form, own domains, and interface with each other. Move from functional teams (frontend/backend) to product teams with clear outcomes.
Process
Decision rights, meeting rhythms
Establish who decides what and when. Create predictable cycles for planning, review, and coordination. Minimize meetings while maximizing alignment.
Communication
Documentation, async patterns
Shift from synchronous tribal knowledge to documented decisions and architectural records. Make information discoverable, not dependent on who you know.
Culture
Values that scale, not just vibes
Encode values into systems—promotion criteria, code review standards, incident response playbooks. Culture can't rely on osmosis when new hires never meet the founders.
Five principles.
Scaling is counterintuitive. These principles make it explicit.
-
1
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 boundaries, interfaces, and success metrics before adding headcount.
-
2
Ownership over consensus.
At 10 engineers, everyone can weigh in. At 50, that's paralysis. Clear ownership beats democratic debate. Assign DRIs (Directly Responsible Individuals). Gather input, but one person decides.
-
3
Document the why.
Decisions need context to survive team growth. "We decided X" isn't enough. Write down what problem you were solving, what alternatives you considered, what tradeoffs you accepted. Future you will thank you.
-
4
Explicit over implicit.
What worked with 10 people breaks with 50. Make implicit norms explicit. How do we prioritize? When do we refactor? What deserves a meeting? Document the unspoken rules while they still work.
-
5
Culture through systems.
Values need to be encoded in processes. If you value quality, what does your code review process enforce? If you value ownership, how do your promotion criteria reflect it? Culture is what you reward and tolerate, not what you say in all-hands.
When to use this.
This applies when:
- You're between 15-30 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 your engineering team in 12 months
- Good engineers are leaving citing "too much chaos"
This doesn't apply when:
- You're still under 10 engineers (structure will slow you down)
- You're not planning to grow beyond your current size
- Your business model is still unproven (solve that first)
- You don't have executive buy-in for organizational change
- You want a template to copy-paste (context matters)
Ready to scale?
I help engineering leaders design team structures, communication patterns, and cultural systems that scale from 10 to 50+ engineers.
Let's talk about your team →