Scaling Engineering Teams: From 10 to 100

November 12, 2018

Growing from a small engineering team to a larger organization requires intentional changes. Communication patterns, decision-making processes, and cultural practices that work at 10 people break down at 50 or 100.

Here’s what changes as you scale, and how to navigate the transitions.

Stages of Scale

10 Engineers: Everyone Knows Everything

Characteristics:

What works:

30 Engineers: Teams Emerge

Characteristics:

Challenges:

50 Engineers: Structure Required

Characteristics:

Challenges:

100 Engineers: Organization Design Matters

Characteristics:

Challenges:

Team Structure

Two-Pizza Teams

Amazon’s rule: teams fed by two pizzas (6-10 people):

Team Types

Stream-aligned teams: Deliver customer value directly

Platform teams: Enable stream-aligned teams

Enabling teams: Help other teams overcome obstacles

Complicated subsystem teams: Own complex components

Clear Ownership

Each area of the codebase has a clear owner:

services/
├── orders/       # Orders team owns
├── payments/     # Payments team owns
├── users/        # Users team owns
└── platform/     # Platform team owns

Ownership includes:

Communication at Scale

From Implicit to Explicit

At 10 people, information flows naturally. At 50+, it requires effort:

Documentation:

Regular communication:

Reducing Communication Overhead

Minimize required coordination:

Make coordination efficient:

Conway’s Law awareness: Your organization’s communication structure will be reflected in your system architecture. Design both intentionally.

Cross-Team Coordination

For technical decisions:

For product decisions:

For execution:

Process Evolution

What to Formalize When

Team SizeFormalize
10Deployment, code review
20On-call, incident response
30Planning process, team charters
50Architecture decisions, engineering levels
100Career development, performance management

Process Principles

Just enough process:

Clear but flexible:

Decision-Making

Small decisions: Team autonomy Medium decisions: Team lead + stakeholders Large decisions: Broader consultation, formal RFC

# RFC: Migrate to PostgreSQL

## Problem
Current MySQL setup has scaling issues...

## Proposal
Migrate to PostgreSQL using...

## Alternatives Considered
1. Shard MySQL
2. Stay with MySQL and optimize
3. Migrate to PostgreSQL ← Recommended

## Impact
- 3 teams affected
- 4 week migration
- Retraining required

## Decision
[After review period]

Culture at Scale

What Scales

Values and principles:

Rituals:

Shared practices:

What Doesn’t Scale

Founder-dependent culture:

Informal apprenticeship:

Preserving Culture

Explicit documentation:

Hiring for culture:

Leadership modeling:

Hiring at Scale

Structured Hiring

At 10 people, you interview as it comes. At 50+, you need:

Defined interview process:

Candidate experience:

Sourcing:

Onboarding

Week 1: Environment setup, meet team, understand context Month 1: Deliver meaningful work, understand domain Quarter 1: Fully productive, shipping independently

Buddy system: Pair new hires with experienced engineers Documentation: Onboarding checklists, learning paths Feedback loops: Regular check-ins, 30/60/90 day reviews

Technical Practices at Scale

Shared Infrastructure

Platform teams provide:

Stream-aligned teams focus on business logic.

Standards and Autonomy

Standardize:

Allow autonomy:

Technical Debt

At scale, tech debt compounds:

Prevention:

Remediation:

Key Takeaways

Scaling engineering teams is organizational design. Invest in it intentionally.