Scaling Remote Teams¶

There's a moment in every growing remote team when things start to feel different. Communication that used to flow naturally becomes effortful. Decisions that happened quickly now stall in ambiguity. People who used to know everyone start asking "who's working on that?" New hires take longer to ramp, and the institutional knowledge that once lived in everyone's head begins to fragment.

This case study is about those inflection points—the moments when what worked at one size stops working at another—and how to navigate them without losing the culture, cohesion, and velocity that made the team successful in the first place.

I've scaled remote engineering teams from small founding groups to organizations of over a hundred people. The patterns repeat. The friction points are predictable. And the solutions, while not always easy, are knowable if you watch for the signals early.

The problem this solves¶

Scaling is not just "more people doing the same thing." It's a series of phase changes where the system itself needs to evolve.

In co-located teams, many coordination problems solve themselves through proximity: overhearing conversations, walking to someone's desk, spontaneous whiteboard sessions. In remote teams, none of that exists. Every coordination mechanism must be intentional. When you add people, you add communication overhead that scales non-linearly.

Without deliberate intervention, several failure modes emerge:

Communication overload. Channels proliferate. Important information gets lost. People spend more time reading Slack than doing work—or they give up and miss critical context.

Coordination costs explode. Meetings multiply. Handoffs between teams require more effort. Work gets blocked waiting for decisions or information that used to be immediate.

Cohesion fragments. New hires form bonds only with their immediate team. Cross-team relationships weaken. The sense of "one team" dissolves into silos.

Onboarding slows. The implicit knowledge that tenured people carry doesn't transfer to new hires. Ramp time increases. Early attrition rises.

Decision-making becomes unclear. At small scale, everyone knew who could decide what. At larger scale, authority becomes ambiguous. Decisions stall or get made in the wrong places.

The job of a leader during scaling is to rebuild the structures that make coordination, communication, and cohesion possible at the new size—before the pain becomes acute.

When to use this approach¶

This playbook applies when:

• You're growing headcount significantly (doubling or more) over 6–12 months.
• You're splitting a single team into multiple teams.
• You're adding new functions (platform, infrastructure, new product areas) that require cross-team coordination.
• You notice that communication patterns that worked before are starting to break.
• Onboarding is taking longer than it used to.
• People are asking "who owns this?" more often than before.

The specific numbers vary by context, but rough inflection points tend to occur around:

• 5–8 people: The "pizza team" limit. Beyond this, you need explicit structure.
• 15–25 people: A single manager can't maintain deep 1:1 relationships with everyone. You need to split.
• 50+ people: You're now operating multiple teams that need coordination mechanisms. Middle management becomes necessary.
• 100+ people: Cultural coherence requires intentional effort. Default-to-async becomes load-bearing.

When this approach is not enough¶

This playbook assumes:

• You have the authority to change team structures, communication norms, and processes.
• You have at least basic remote infrastructure (async tools, video conferencing, documentation systems).
• The business is actually growing—not just adding headcount without commensurate work.

If you're dealing with:

• A fundamental mismatch between hiring and actual workload, address that first.
• Deep cultural dysfunction predating the scaling challenges, start with Culture: Engineering Culture.
• Individual performance issues masked as scaling problems, those need direct management.

Roles and ownership¶

Scaling is a leadership responsibility distributed across multiple roles:

The approach: navigating scale inflection points¶

Inflection 1: From founding team to structured team (5–15 people)¶

At very small scale, structure feels like overhead. Everyone knows everyone. Communication happens naturally. Decisions are made in real-time conversation.

Then you hire a few more people. Suddenly, not everyone was in the room when that decision was made. The new hire doesn't know the context behind why you chose that architecture. Implicit agreements start to conflict.

What needs to change:

Explicit working agreements. What was implicit becomes written. How do we communicate? When do we meet? How do we make decisions? See Team Ops: Working Agreements.

Defined ownership. Every system, every area of the codebase, every type of work has a clear owner. Not to restrict contribution—but to clarify accountability.

Onboarding structure. The new hire who could previously "just pick it up" now needs a real plan. First week goals, a buddy, documented context. See Team Ops: Onboarding 30/60/90.

Regular rituals. Weekly syncs, planning sessions, retrospectives. Not because you need them for coordination (yet), but because building the muscle early makes scaling smoother later.

Inflection 2: From one team to multiple teams (15–40 people)¶

This is where most remote teams hit their first serious pain. A single engineering team splits into two or more. Each team develops its own context, its own velocity, its own relationships. Cross-team communication that used to be free becomes expensive.

What needs to change:

Team topology clarity. Each team needs a clear mission, clear boundaries, and clear interfaces with other teams. Stream-aligned teams (owning user journeys) vs. platform teams (providing capabilities) vs. enabling teams (supporting others) all have different shapes. The book Team Topologies by Skelton and Pais offers a useful vocabulary.

Explicit dependency management. When teams depend on each other, those dependencies need visibility. Regular sync points, shared backlogs for interface work, and documented API contracts.

Cross-team communication norms. How do teams communicate with each other? Which channels, which meetings, which documents? Without norms, you get either over-communication (everyone in every channel) or under-communication (critical context missed).

Middle management. Beyond ~8 direct reports, an EM can't maintain the depth of relationship that good management requires. You need to split—either by promoting from within or hiring. The first layer of engineering management is a critical inflection.

Consistent practices, not uniform practices. Teams need autonomy to work in ways that fit their context. But some things need consistency: how we deploy, how we handle incidents, how we do code review, how we run postmortems. Identify what must be consistent and let the rest vary.

Inflection 3: From multiple teams to an organization (40–100+ people)¶

At this scale, you're no longer managing a team—you're managing a system of teams. Individual relationships between every pair of people become impossible. Culture must be deliberately maintained, not assumed.

What needs to change:

Leadership development. Your EMs are now managing other managers, or managing teams that used to be led by seniors who are now TLs. Leadership skills need to be taught, not assumed. See Leadership: Leadership Development.

Communication layers. Not everyone needs every piece of information. Design communication for different audiences: all-hands for company-wide context, team-specific channels for day-to-day work, cross-team channels for coordination points, and escalation paths for urgent issues.

Cultural rituals at scale. The all-hands, the demo day, the hackathon, the virtual social event—these become load-bearing. They're how people outside their immediate team maintain connection to the broader organization.

Governance without bureaucracy. Decisions that affect multiple teams need a way to be made. Architecture Decision Records (ADRs), an architecture forum, explicit escalation paths. The goal is not to slow things down—it's to make cross-cutting decisions visible and intentional.

Async by default, sync by exception. At scale, synchronous communication doesn't fit. Time zones diverge. Meeting load becomes untenable. Default to async (written updates, documented decisions, recorded context). Reserve sync time for alignment, conflict resolution, and creative collaboration. See Team Ops: Async Communication.

What good looks like¶

People know who owns what. When someone has a question, they know where to go. Ownership is documented and up-to-date.

Communication scales without drowning people. Channels are organized. Important information surfaces. People can opt in to detail without being forced into noise.

New hires ramp effectively. Onboarding has structure. New hires feel productive within their first month. Early attrition is low.

Teams coordinate without constant meetings. Interfaces are clear. Dependencies are visible. Most coordination happens async.

Culture is consistent across teams. Teams have local flavor, but the core values—psychological safety, clarity, ownership—show up everywhere.

Leaders develop. Senior ICs become TLs. TLs become EMs. People grow into roles without the organization becoming dependent on any single person.

Failure modes and mitigations¶

Copy-pastable artifacts¶

Team charter template¶

Use this when spinning up a new team or clarifying an existing team's mission.

# Team Charter: [Team Name]

## Mission

One sentence: what does this team exist to do?

## Scope

What's in scope for this team? What's explicitly out of scope?

## Key responsibilities

- [Responsibility 1]
- [Responsibility 2]
- [Responsibility 3]

## Interfaces

- **Teams we depend on:** [list with primary contact]
- **Teams that depend on us:** [list with primary contact]
- **How we communicate with other teams:** [channels, cadence]

## Working agreements

- Core hours: [X-Y in timezone]
- Async response time: [expectation]
- Meeting norms: [e.g., cameras optional, agendas required]

## Rituals

- [Ritual 1]: [cadence, duration, purpose]
- [Ritual 2]: [cadence, duration, purpose]

## Success metrics

- [Metric 1]: [target]
- [Metric 2]: [target]

## Decision-making

- Day-to-day decisions: [who]
- Technical decisions: [who]
- Process changes: [who/how]
- Escalation path: [who]

## Team members

- EM: [name]
- TL: [name]
- Engineers: [names]

Last updated: [date]

Cross-team communication norms¶

# Cross-Team Communication Norms

## Channels

- **#eng-announcements:** Read-only for org-wide announcements. All engineers expected to follow.
- **#eng-random:** Social, off-topic. Optional but encouraged.
- **#team-[name]:** Team-specific channels. Outsiders welcome to join but not required.
- **#proj-[name]:** Time-bound project channels. Archive when project completes.

## When to sync vs. async

| Situation                      | Default                                |
| ------------------------------ | -------------------------------------- |
| Status update                  | Async (written update)                 |
| Decision with clear owner      | Async (proposal → feedback → decision) |
| Disagreement that's escalating | Sync (video call)                      |
| Creative exploration           | Sync (working session)                 |
| Blocking issue                 | Sync (immediate call or quick huddle)  |

## Expectations

- Async messages: respond within [X] hours during working hours.
- Meeting invites: include agenda and purpose. Decline meetings without agendas.
- Cross-team requests: use [request template/form] for visibility and tracking.

## Escalation

If a cross-team issue is blocking and normal channels aren't resolving it:

1. Escalate to your EM
2. EMs connect to resolve
3. If still blocked, escalate to [Director/VP]

Org-wide all-hands agenda template¶

For remote teams, the all-hands is often the primary touchpoint for the full organization.

# Engineering All-Hands — [Date]

**Duration:** 45 minutes
**Recording:** [link after the meeting]

## Agenda

### 1. Context (5 min)

What's happening in the business that engineering should know about?

### 2. Wins (5 min)

What shipped this period? Who should we celebrate?

### 3. Focus areas (10 min)

What are the 2-3 things leadership is paying attention to right now?

### 4. Deep dive (15 min)

One topic explored in more depth. Rotate ownership across teams.

### 5. Q&A (10 min)

Questions from the pre-submitted form + live questions.

---

**Norms:**

- Cameras encouraged but optional.
- Questions: submit in advance via [form] or ask live in chat.
- Recording available within 24 hours.
- Notes published in [location].

Scaling health check (quarterly)¶

Run this async survey or discussion quarterly to identify scaling pain early.

# Scaling Health Check

For each statement, rate 1-5 (1 = strongly disagree, 5 = strongly agree):

## Communication

- I know where to find the information I need to do my job.
- Important decisions are communicated clearly.
- I can get answers to cross-team questions without excessive effort.

## Ownership

- It's clear who owns the systems and processes I interact with.
- I know how decisions are made that affect my work.
- I know how to escalate when I'm blocked.

## Onboarding

- New team members are productive within their first month.
- Institutional knowledge is documented, not just in people's heads.
- Our onboarding process has kept pace with our growth.

## Cohesion

- I feel connected to people outside my immediate team.
- I understand how my work connects to the broader org goals.
- I'd describe our culture as consistent across teams.

## Capacity

- My meeting load is sustainable.
- I have enough focus time to do deep work.
- I'm not constantly context-switching between unrelated tasks.

## Open questions

- What's working well that we should keep doing?
- What's not working that we should change?
- What's a signal of scaling pain we should watch for?

A reflection: what I've learned about scaling remote teams¶

The hardest part of scaling isn't the process or the structure. It's the identity shift.

When a team is small, the leader is a player-coach. You're in the code, in the decisions, in the details. You know everyone. You can feel the team's health intuitively. Your impact is direct and visible.

As the team scales, that changes. Your impact becomes indirect. You're no longer the one making the decision—you're the one making sure the right person can make the decision. You're not writing the code—you're creating the conditions for good code to be written. You're not building the culture—you're tending it, reinforcing it, protecting it.

This shift is uncomfortable. It requires letting go of things you're good at and probably enjoy. It requires trusting people to do things differently than you would. It requires accepting that you'll be wrong sometimes about who to trust, and being willing to course-correct without blame.

The leaders who struggle with scaling are often the ones who can't make this shift. They hold on to control past the point where control is possible. They become bottlenecks. The team's growth is limited by their capacity instead of amplified by their leverage.

The leaders who thrive at scale are the ones who find meaning in the indirect work. Who take genuine satisfaction in seeing others succeed. Who build systems that work without them, and find that freeing rather than threatening.

It's not for everyone. And that's okay. There's valuable work to be done at every scale. But if you're going to lead through scale transitions, the sooner you internalize this shift, the less painful the journey will be.

Further reading¶

• Team Topologies by Matthew Skelton and Manuel Pais — A practical framework for organizing teams at scale.
• An Elegant Puzzle by Will Larson — Systems thinking for engineering management, including scaling challenges.
• The Manager's Path by Camille Fournier — Career progression in engineering leadership, including the skills needed at different levels.
• Remote: Office Not Required by Jason Fried and DHH — Foundational thinking on remote work, though written for smaller scale.
• High Output Management by Andy Grove — Classic on organizational leverage, still relevant for scaling leaders.

Related chapters¶

• Scaling: Scaling Teams — The structural mechanics of team growth.
• Scaling: Scaling Systems — How architecture scales alongside teams.
• Team Ops: Working Agreements — Foundational agreements for team coordination.
• Team Ops: Async Communication — Communication patterns that scale.
• Team Ops: Onboarding 30/60/90 — Structured onboarding for growing teams.
• Leadership: Leadership Development — Building the leadership pipeline that scale requires.
• People: Coaching New Tech Leads — Developing the first layer of technical leadership.