Scaling Teams¶

Growing a team is not the same as adding headcount.

Headcount is a number. Growing a team is a systems problem: how do you add people in a way that increases capacity without fragmenting culture, slowing decisions, or drowning everyone in coordination overhead?

The teams that scale well understand this: every new person is an opportunity and a cost. The opportunity is obvious—more hands, more perspectives, more capacity. The cost is hidden—more communication paths, more onboarding burden, more implicit knowledge that needs to become explicit, more chances for misalignment.

Scaling well requires investing in the boring stuff that makes the exciting stuff possible: onboarding, documentation, role clarity, team structure, and decision rights. It requires saying no to things that worked before but won't work anymore.

What problem this solves¶

When teams scale without intention:

• Communication breaks down. People don't know what other people are doing, who to ask, or where to find information.
• Decisions slow down. Everything requires more alignment, more meetings, more people saying "I should probably be involved in this."
• Culture fragments. New hires inherit different versions of "how we do things here" depending on who onboarded them.
• Bottlenecks emerge. The same few people become critical paths for everything, and they burn out.
• Quality suffers. Standards that were maintained through osmosis degrade when there are too many people to osmose.

Intentional team scaling addresses these problems before they become crises.

When to use this playbook¶

Use this when:

• You're planning to grow the team significantly (more than 25–30% increase).
• You're about to split one team into two or more.
• You're adding new leadership roles (tech leads, managers).
• You're noticing coordination problems that didn't exist six months ago.
• New hires are taking longer to become productive, or they're leaving early.

Don't use this when:

• You're adding one or two people to a stable team. Normal onboarding suffices.
• You're shrinking. Different playbook.
• The problem is performance, not scale. Adding people to a struggling team makes it worse.

Roles and ownership¶

The EM is the primary owner, but scaling is a collaborative effort. No single person can see all the dimensions.

The scaling process¶

Phase 1: Assess current state¶

Before adding anyone, understand what you have.

Map current team structure:

• How many people? What roles and levels?
• What are the current responsibilities and ownership boundaries?
• Who depends on whom? Where are the informal experts?

Identify current pain points:

• What's slow? What's fragile?
• Where are the bottlenecks (people, systems, decisions)?
• What knowledge exists only in one person's head?

Document current practices:

• How do we onboard? How long until someone is productive?
• How do we make decisions? Where does authority live?
• How do we coordinate? What rituals do we have?

Phase 2: Define target state¶

Where do you need to be, and by when?

Headcount and timeline:

• How many people do you expect in 6 months? 12 months?
• What's the hiring pace? (This determines how much onboarding load you'll carry.)

Team structure:

• Will you need to split teams? At what size?
• What ownership boundaries make sense?
• What leadership roles will you need?

Capabilities:

• What skills are you missing?
• What skills will become more critical at scale?

Guardrails:

• What must stay consistent across teams (coding standards, deployment practices, on-call)?
• Where can teams diverge?

Phase 3: Plan the transition¶

Scaling is not a single event. It's a series of changes, sequenced deliberately.

Sequence matters:

1. First, invest in infrastructure: Documentation, onboarding, shared standards. These enable scale.
2. Then, add people gradually: Onboard in cohorts if possible, but not so many that existing team members are overwhelmed.
3. Then, evolve structure: Split teams, add roles, clarify ownership—only when the team is stable enough to absorb the change.

Budget for onboarding load:

• Each new hire costs existing team members time. Plan for 10–20% productivity hit per new hire for the first month.
• Stagger hires if possible. Four people in one week is harder than one person per week for four weeks.

Communicate clearly:

• Why are we scaling?
• What will change, and when?
• What will stay the same?
• Who should people talk to if they have concerns?

Phase 4: Execute and iterate¶

Scaling plans rarely survive first contact with reality. Build in feedback loops.

Monthly check-ins:

• How is onboarding going? Time to first meaningful contribution?
• Where are the bottlenecks now?
• What coordination problems are emerging?
• How is team health? (Survey, skip-levels, informal signals)

Quarterly structural reviews:

• Is the current team structure still right?
• Are ownership boundaries clear?
• Are we ready for the next scaling step?

Be willing to adjust:

• Pause hiring if onboarding is failing.
• Split teams earlier or later than planned based on actual dynamics.
• Add leadership roles when needed, not on a schedule.

Team structure patterns¶

Single team (up to ~6–8 engineers)¶

• One manager, one tech lead (may be the same person).
• Everyone knows everyone's work.
• Communication is informal.
• Decisions are fast.

When it breaks: Too many people to stay aligned informally. The manager is spread too thin. Context-switching is constant.

Pod model (8–15 engineers)¶

• One manager, multiple tech leads or senior engineers leading work streams.
• Work is organized into pods or focus areas, but people are still on "one team."
• Shared rituals, shared backlog, shared ownership.

When it breaks: Pods start to feel like separate teams. Coordination between pods becomes expensive. Manager can't go deep with everyone.

Multiple teams (15+ engineers)¶

• Separate teams with clear ownership boundaries.
• Each team has its own manager (or tech lead acting as team lead).
• Cross-team coordination is explicit (shared rituals, dependency management).

When to split: When coordination within the team is harder than coordination between teams would be. When ownership is contested or unclear. When the manager can't maintain meaningful relationships with everyone.

The team split playbook¶

Splitting a team is high-risk, high-reward. Done well, it creates clarity and focus. Done poorly, it creates confusion, resentment, and gaps.

Before the split¶

1. Define ownership boundaries. Each team should have clear responsibility for a part of the product or system. Avoid shared ownership of critical components.

2. Identify leadership. Each team needs someone who can lead—whether that's a new manager, a promoted tech lead, or an existing person with expanded scope.

3. Map dependencies. What will the teams need from each other? How will they coordinate?

4. Communicate the why. Teams that understand the reasoning are more likely to support the change.

During the split¶

1. Move people deliberately. Consider skill balance, relationships, and individual preferences. Don't just split alphabetically.

2. Transfer knowledge. The people who know the most about each area should be on the team that owns it—or should spend time transferring context.

3. Establish new rituals. Each team needs its own cadence (standups, planning, retros). Cross-team rituals should be light.

4. Clarify decision rights. Who decides what? Where does authority live?

After the split¶

1. Monitor for gaps. Things will fall through the cracks. Watch for orphaned work, unclear ownership, and duplicated effort.

2. Expect some thrashing. The first few weeks will be awkward. That's normal.

3. Check in frequently. Both with the teams and with individuals. Some people will struggle with the change.

Preserving culture through growth¶

Culture is not a poster on the wall. It's the sum of how people actually behave—what gets rewarded, what gets tolerated, what gets discussed.

When teams scale, culture becomes harder to maintain because:

• New hires haven't experienced the formative moments that shaped the culture.
• Implicit norms become diluted as more people interpret them differently.
• The people who carry the culture are spread thinner.

How to preserve what matters¶

Write it down. Values, working agreements, decision principles—anything important should be documented. "We all just know" doesn't scale.

Onboard intentionally. Culture is transmitted through onboarding. Make sure new hires understand not just what we do, but why we do it and how we make decisions.

Model consistently. Leaders set the tone. If you say you value work-life balance but send emails at midnight, you're teaching the opposite.

Create rituals. Shared experiences build shared culture. All-hands, demos, celebrations, retrospectives—these are where culture is reinforced.

Protect psychological safety. This matters more at scale, not less. As teams grow, people are less likely to speak up unless safety is actively maintained.

Address drift. When you see behaviors that contradict the culture, name it. "That's not how we do things here" is a cultural intervention.

Signals that scaling is working¶

• New hires become productive within their first month.
• Teams have clear ownership and don't fight over boundaries.
• Decisions are made at the appropriate level—local decisions are local.
• The team feels like one organization, not a collection of silos.
• Senior people have time to think, not just fight fires.
• Voluntary attrition is stable or improving.

Failure modes and mitigations¶

Copy-pastable artifacts¶

Team scaling readiness checklist¶

## Team Scaling Readiness Checklist

### Before hiring

- [ ] Current team structure and responsibilities documented
- [ ] Pain points and bottlenecks identified
- [ ] Onboarding process documented and tested
- [ ] Key knowledge captured in documentation (not just in heads)
- [ ] Target state defined (headcount, timeline, structure)

### Before team split

- [ ] Ownership boundaries defined for each team
- [ ] Leadership identified for each team
- [ ] Dependencies mapped and coordination plan in place
- [ ] Communication plan ready (why, what changes, what stays)
- [ ] Decision rights clarified

### Ongoing monitoring

- [ ] Time to first meaningful contribution tracked
- [ ] Monthly scaling check-in scheduled
- [ ] Quarterly structural review scheduled
- [ ] Team health signals monitored (survey, skip-levels, attrition)

Team split announcement template¶

## [Team Name] is becoming [Team A] and [Team B]

### Why we're doing this

[Explain the reasoning: growth, focus, clarity, etc.]

### What's changing

**Team A** will own [scope]. Led by [Name].
**Team B** will own [scope]. Led by [Name].

### What's not changing

[Shared standards, rituals, values, etc.]

### Timeline

- [Date]: Announcement 'today'
- [Date]: Teams start operating separately
- [Date]: Check-in to assess how it's going

### How we'll coordinate

[Cross-team rituals, dependency management, etc.]

### Questions?

[Who to ask, where to discuss]

Monthly scaling check-in agenda¶

## Monthly Scaling Check-In

**Date:** [Date]
**Attendees:** [EM, Tech Lead, HR partner]

### Onboarding

- New hires this month: [Number]
- Time to first PR: [Average]
- Time to meaningful contribution: [Average]
- Onboarding feedback themes: [Summary]

### Coordination

- New bottlenecks emerging? [Y/N, details]
- Ownership conflicts? [Y/N, details]
- Communication gaps? [Y/N, details]

### Team health

- Recent team health survey results: [Summary]
- Skip-level feedback themes: [Summary]
- Attrition signals? [Y/N, details]

### Structural decisions

- Is current structure working? [Assessment]
- Changes needed? [Proposals]
- Ready for next scaling step? [Assessment]

### Actions

- [Action 1 — Owner — Due date]
- [Action 2 — Owner — Due date]

Related pages¶

• Scaling Overview — Context and principles for scaling.
• Scaling Systems — The technical side of growth.
• Team Ops: Onboarding 30/60/90 — Getting new hires productive.
• People: Hiring Playbook — Hiring process and quality.
• Team Ops: Working Agreements — Explicit team norms.
• Culture: Engineering Culture — Building and maintaining culture.
• Case Studies: Scaling Remote Teams — A worked example.

Further reading¶

• An Elegant Puzzle by Will Larson — Systems thinking for engineering management and organizational design.
• The Manager's Path by Camille Fournier — Growth paths in engineering organizations.
• Team Topologies by Matthew Skelton and Manuel Pais — Patterns for organizing teams around flow.