Skip to content

Scaling

Scaling is where good habits go to die.

The practices that worked for a team of six rarely survive the jump to thirty. The architecture that handled ten thousand users becomes a liability at a million. The informal coordination that felt so natural turns into confusion, bottlenecks, and people asking "wait, who owns this?"

This section addresses both sides of growth: scaling teams and scaling systems. They are different problems, but they interact constantly. A system that can't scale forces the team into firefighting mode. A team that can't scale becomes the bottleneck for every technical decision.

The hardest part of scaling is not the mechanics—it's recognizing when you've outgrown what used to work and having the discipline to change it before it breaks.

What this section covers

Topic Focus When to use
Scaling Teams Growing from a handful of engineers to multiple squads without losing culture, clarity, or execution speed. When you're about to hire significantly, split teams, or add new leadership layers.
Scaling Systems Evolving architecture, infrastructure, and operational practices to handle growth in users, data, and complexity. When you're hitting performance limits, reliability is degrading, or changes are getting slower and riskier.

The scaling paradox

Scaling requires standardization, but innovation requires flexibility. Scaling requires delegation, but quality requires consistency. Scaling requires process, but speed requires cutting through process.

There's no way to resolve these tensions permanently. The goal is to be intentional about where you standardize and where you allow variance, what you delegate and what you control, which processes you add and which you remove.

Good scaling isn't about adding more. It's about adding the right things at the right time and being willing to remove what no longer serves.

Signals that you need to scale differently

Team signals

  • Decisions that used to take a day now take a week because too many people need to weigh in.
  • New hires take months to become productive—or they leave before they do.
  • The same few people are bottlenecks for everything.
  • Teams are stepping on each other's code, competing for shared resources, or duplicating work.
  • Communication breaks down—people don't know what other teams are doing.

System signals

  • Deployments are slower, riskier, or require more coordination.
  • Incidents are more frequent, longer, or harder to diagnose.
  • Feature development slows down because "the system won't let us."
  • Technical debt is accelerating faster than you can pay it down.
  • Monitoring and alerting are overwhelmed—signal is lost in noise.

Core principles for scaling

These principles apply to both teams and systems:

Scale incrementally. Don't reorganize everything at once. Don't rewrite the system in one shot. Prefer small, reversible changes that you can learn from.

Preserve what works. Before changing something, understand why it worked. Scale the principle, not just the practice.

Make the implicit explicit. What was understood informally must be written down. Decisions, interfaces, ownership, expectations—all of it.

Invest in infrastructure. This applies to both technical infrastructure (observability, deployment, testing) and organizational infrastructure (onboarding, documentation, feedback loops). These enable scale; they don't happen automatically.

Accept that some things won't survive. Some practices, some architectures, some even some roles will need to change or disappear. Mourn them and move on.

Ownership and roles

Role Responsibility
Engineering Manager Owns team structure, hiring, onboarding, and coordination. Identifies team scaling signals and proposes changes.
Tech Lead / Staff Engineer Owns system architecture and technical scaling decisions. Identifies system scaling signals and proposes changes.
VP / Director Owns cross-team coordination and organizational design. Balances local optimization against global coherence.
Product Partner Provides context on growth expectations and customer impact. Helps prioritize scaling investments against feature work.

Scaling decisions require collaboration between people who see the organizational picture and people who see the technical picture. Neither perspective is sufficient alone.

What good looks like

  • Teams can grow without requiring heroics from the existing members.
  • Systems can handle 2–3x current load without major rearchitecture.
  • New engineers become productive within their first month.
  • Decisions are made at the appropriate level—not escalated by default, not made in isolation.
  • Technical debt is managed deliberately, not accumulated by default.
  • Teams feel ownership and clarity, not confusion and conflict.

What usually goes wrong

Failure mode What it looks like Mitigation
Scaling too early Process and structure for a scale you haven't reached; overhead without benefit Wait for pain to justify the investment
Scaling too late Burning out the team trying to operate a system too big for the current practices Watch the signals; plan ahead of the inflection point
Copying someone else's model Adopting Spotify squads or Google SRE without understanding your context Start from your constraints; borrow ideas, not structures
Ignoring culture Technical scaling succeeds, but the team feels fragmented and disengaged Invest in onboarding, rituals, and explicit values alongside technical changes
Over-optimizing for independence Teams can't work together when needed; duplication and divergence Balance autonomy with intentional coupling points