Scaling Engineering Teams

Scaling is not hiring. It is building the systems, structures, and culture that let more people ship without stepping on each other. Every engineer you add increases coordination cost — scaling is about keeping that cost sublinear.

The Coordination Cost Problem

Adding engineers has diminishing returns because communication paths grow quadratically:

Team Size	Communication Channels (n*(n-1)/2)	Typical Impact
5	10	Everyone knows everything
10	45	Information starts to fall through cracks
16	120	Need explicit knowledge sharing mechanisms
25	300	Subgroups form; silos emerge without effort
50	1,225	Organization needs structure to function

Brooks’s Law: Adding people to a late project makes it later. The new person needs ramp-up time and adds communication overhead. This is not just about late projects — it applies to any team above ~7 people.

The scaling paradox: The practices that work at 5 engineers (verbal coordination, shared context, no process) actively harm you at 25 engineers. Every growth threshold requires abandoning practices that got you to the current stage.

---

Growth Phases

Phase 1: Startup (5-10 Engineers)

Characteristics:

• Everyone talks to everyone
• One team, one backlog, one standup
• EM is a player-coach (50%+ coding)
• Architecture is simple (monolith or small set of services)
• Hiring is episodic (you need one more person)

What works: Speed, informality, shared context, minimal process.

What breaks next: Knowledge concentration in 1-2 people, no career path, no specialization.

Phase 2: Growth (10-25 Engineers)

This is where you are at 16 engineers. The critical transition.

Characteristics:

• Two to three teams with distinct ownership areas
• EM stops coding (or should — see the section on player-coach trap below)
• First tech leads and senior IC roles emerge
• Architecture splits along team boundaries (Conway’s law, whether you want it or not)
• Hiring becomes a regular activity

What you must build at this stage:

1. Career ladder — at minimum, distinguish Senior from Mid from Junior. Without this, top talent leaves for companies that have one.
2. Architecture decision process — ADRs or equivalent. Decisions can no longer happen verbally.
3. Onboarding program — New engineers cannot absorb context through osmosis at this size. First-week plan, 30/60/90-day milestones, assigned buddy.
4. Explicit engineering standards — Code review norms, testing expectations, deployment process. Written down, not tribal knowledge.
5. Cross-team coordination mechanism — weekly sync between team leads, dependency board, shared Slack channel for blockers.

The player-coach trap: At 16 engineers, writing production code as an EM is almost always a mistake. You become a bottleneck (reviews wait for you, architectural decisions wait for your code review), and you neglect people management. Delegate code ownership to tech leads and senior engineers. Your code contribution should be limited to prototypes, spikes, and occasional pair programming for context.

Phase 3: Scale (25-50 Engineers)

Characteristics:

• Multiple EMs needed — you become a manager of managers
• Platform team becomes necessary
• Engineering culture fragments without active maintenance
• Hiring is continuous; recruiter relationship becomes essential
• Architecture council or principal engineer role needed for cross-cutting decisions

What you must build at this stage:

1. Manager layer — promote or hire EMs for each team. Your job shifts to coaching EMs, not coaching ICs.
2. Principal engineer or staff+ track — senior ICs who operate across teams need a formal role and career path.
3. Platform team — internal developer platform (CI/CD, observability, shared services). Without this, every team reinvents the wheel.
4. Engineering principles — documented values that guide decisions when you are not in the room. “We prefer boring technology.” “We own what we ship.” “We measure before we optimize.”
5. Structured hiring — rubrics, interview loops, hiring committees. Ad-hoc hiring creates inconsistent teams.

Phase 4: Organization (50-150+ Engineers)

Characteristics:

• Director or VP layer needed
• Multiple product areas with distinct technical strategies
• Engineering brand matters for hiring
• Internal mobility and rotation programs
• Engineering metrics and reporting to executives

This phase is beyond your current scale but relevant for career planning and understanding the trajectory.

---

The IC Ladder — Staff+ Engineering

Why the IC Ladder Matters

Without a senior IC track, your best engineers face a choice: become a manager (which they may not want or be suited for) or leave. The IC ladder retains technical talent by providing growth without management.

IC Levels

Level	Scope	Key Activities	Org Impact
Junior (L1-L2)	Single task or feature	Writing code, learning patterns, getting reviews	Executes defined work
Mid (L3)	Single feature or small project	Owns implementation end-to-end, mentors juniors	Reliable delivery
Senior (L4)	Team-level	Designs solutions, sets technical direction for team, code reviews	Technical leadership within team
Staff (L5)	Multi-team or org-wide	Defines architecture across teams, mentors seniors, drives technical strategy	Multiplier across teams
Principal (L6)	Company-wide	Sets technical vision, represents company externally, shapes industry practices	Defines what the company builds and how

Staff Engineer Archetypes (Will Larson)

Archetype	Description	Example
Tech Lead	Guides technical direction of a team or project, partners with EM	Owns the technical roadmap for the AI platform; makes architecture decisions; unblocks the team daily
Architect	Defines system design across multiple teams	Designs the integration patterns between product search and recommendation services
Solver	Parachutes into the hardest problems	Leads the database migration; fixes the performance crisis; builds the prototype
Right Hand	Extends a senior leader’s reach	Acts as VP Eng’s technical proxy; drives cross-org initiatives that need technical authority

What Makes Staff Engineers Effective

Staff engineers operate differently from senior engineers. The key shifts:

1. From coding to enabling: Staff engineers write less code but ensure the right code gets written. Their leverage comes from design docs, architecture reviews, and mentoring — not from PRs.

2. From team scope to org scope: A senior engineer optimizes within their team. A staff engineer optimizes across teams, resolving conflicts between team-local and system-global concerns.

3. From execution to judgment: The primary contribution is judgment — which problems are worth solving, which technologies to adopt, where to invest versus accept debt.

4. From being told what to do to finding what needs doing: Staff engineers identify problems before they are assigned. They see the gap between current architecture and business needs and act on it.

Sponsoring Staff Engineers (EM’s Role)

As an EM, you cannot promote someone to Staff by giving them harder coding tasks. You must:

• Create the scope: Give them cross-team problems to solve
• Provide air cover: Shield them from interrupt-driven work
• Connect them to stakeholders: Staff engineers need business context
• Make their impact visible: Their work is often invisible (architecture improvements, mentoring). Document and communicate it.
• Challenge them: Staff engineers need honest feedback more than encouragement

---

EM vs IC Ladder — The Pendulum

The Ladder Comparison

Dimension	EM Track	IC Track
Scope growth	More people, broader org	Harder problems, broader technical scope
Day-to-day	1:1s, planning, hiring, stakeholder management	Design, code, architecture reviews, mentoring
Impact model	Multiplier through people	Multiplier through technology
Feedback cycle	Long (team health over quarters)	Medium (project outcomes over weeks/months)
Reversibility	Hard to go back after 2+ years (skills atrophy)	Easier to return to (technical skills stay fresh)
Emotional labor	High (performance issues, layoffs, conflict)	Lower (but increases at Staff+ with organizational work)

When to Switch

IC to EM:

• You find yourself naturally coaching and unblocking others
• You care more about team output than your own code
• You are frustrated by organizational problems you cannot solve as an IC
• Caution: “I want to have more impact” is a good reason. “I want a promotion and management is the only path” is a bad reason.

EM to IC:

• You miss deep technical work and it is not scratched by occasional coding
• You dread 1:1s and performance reviews
• You are in management because it was the only promotion path, not because you want it
• The org supports a return to IC without it being seen as a demotion

---

Managing Managers

When you grow beyond 16 engineers, you will need to manage other managers. This is a different skill set.

Key Differences

Managing ICs	Managing Managers
You see their work directly (code, designs)	You see their work through their team’s output
Feedback is concrete (“this code needs refactoring”)	Feedback is abstract (“your team’s delivery predictability has dropped”)
You can observe problems in real-time	Problems are filtered through the manager’s lens
You solve problems directly	You coach the manager to solve problems

What Changes

1. Skip-level 1:1s become essential: Meet each IC on the team every 4-6 weeks. Not to undermine the manager, but to calibrate your understanding. Ask: “What is going well? What could be better? Is there anything you need from me?” Share feedback with the manager afterward.

2. You manage systems, not tasks: Instead of reviewing PRs, you review team processes. Instead of unblocking an engineer, you ensure the manager has the skills and authority to unblock.

3. Calibration across teams: Ensure consistent standards for performance, promotion, and hiring. The biggest risk with multiple managers is inconsistency — one manager is generous with ratings, another is strict. Calibrate regularly.

4. Manager coaching: Your 1:1s with managers should focus on their development as managers, not on task tracking. “How did the difficult conversation go?” “What did you learn from the incident response?” “Where are you struggling?”

---

Building Engineering Culture

Culture is not a slide deck or a list of values on a wall. Culture is what people do when no one is watching — the default behaviors that emerge from incentives, norms, and examples.

Culture Mechanisms That Actually Work

Mechanism	How It Works	Example
What you celebrate	Public recognition signals what matters	Celebrate the engineer who found the bug before production, not just the one who shipped the feature
What you tolerate	What you allow defines your real standards	If you tolerate a brilliant jerk, you signal that results matter more than collaboration
What you measure	Metrics shape behavior (Goodhart’s Law risk)	Measure cycle time and MTTR, not lines of code or story points
Who you promote	Promotions are the loudest signal of what the organization values	Promote the engineer who mentored three juniors, not just the one who shipped the big feature solo
Who you hire	Every hire shifts the cultural center of gravity	One toxic hire in a 16-person team shifts 6% of the culture. That is significant.
How leaders behave	Leaders model the culture; hypocrisy kills it	If the EM skips retros, the team learns retros are optional

Engineering Principles (Examples)

These are not aspirational values. These are decision-making heuristics:

• “We own what we ship.” — No throwing things over the wall to ops. If you build it, you are on-call for it.
• “Make it boring.” — Choose proven technology over exciting technology. Innovation belongs in the product, not the infrastructure.
• “Measure before you optimize.” — No premature optimization. Profile first, then improve.
• “Write it down.” — Decisions, architecture, runbooks. If it is not written down, it does not exist.
• “Default to open.” — Share context broadly. Overcommunicate. Assume positive intent.

Culture at Scale

At 16 engineers, culture is maintained through direct interaction. The EM’s behavior sets the tone. Beyond 25 engineers, culture requires explicit mechanisms:

• Engineering all-hands: Monthly or quarterly. Share wins, failures (postmortems), strategy updates, and promotions.
• Tech talks / brown bags: Weekly 30-minute sessions where engineers present to each other. Builds knowledge sharing and public speaking skills.
• Guild or community of practice: Cross-team groups (e.g., frontend guild, testing guild) that maintain standards and share practices.
• Written engineering principles: Posted, referenced in ADRs and design reviews, updated annually.

---

Anti-Patterns

Anti-Pattern	Symptom	Fix
Hiring to solve process problems	“We need more people” when the real issue is unclear priorities or poor tooling	Fix the system first; adding people amplifies dysfunction
Flat org fallacy	No titles, no levels, no career path — “we are all engineers”	People need growth paths. Flat org just hides the hierarchy.
Staff engineer as super-senior	Staff title but same scope as senior (one team, coding all day)	Staff scope must be multi-team; if it is not, the title is inflation
EM as project manager	EM spends all time on Jira, none on people	Delegate project tracking to tech leads; EMs focus on people and strategy
Hero worship	One engineer “holds it all together” — celebrated but never supported	Bus factor problem. Pair them, spread knowledge, build redundancy.
Culture of overwork	Late-night Slack messages from leadership, weekend deploys as norm	Model boundaries. Stop rewarding heroics; start rewarding prevention.

---

Real-World Application

Stripe’s Engineering Ladder

Stripe’s IC ladder goes from L1 (new grad) to L7+ (distinguished engineer). Key features:

• Each level has explicit scope, complexity, and impact expectations
• Staff+ engineers are expected to have “company-level” impact
• The ladder is published and referenced in every performance review
• Promotion to Staff requires a “promo packet” with evidence of sustained impact

Google’s TL/TLM Split

Google explicitly separates Tech Lead (TL) from Tech Lead Manager (TLM):

• TL: IC who leads a project technically. No people management.
• TLM: Combines tech lead and people management for a single team.
• EM (Manager): People management without deep technical ownership.

This gives engineers flexibility to lead without managing and managers the option to remain technical.

Amazon’s Bar Raiser Program

Amazon’s hiring process includes a “Bar Raiser” — a trained interviewer from outside the hiring team who has veto power. The Bar Raiser ensures hiring standards remain consistent as the organization scales. Every hire must be “better than 50% of current employees at the same level.”

Shopify’s Manager Expectations

Shopify publishes explicit expectations for managers at each level:

• Manager: Direct team output, individual coaching, sprint execution
• Senior Manager: Cross-team coordination, hiring pipeline, technical strategy input
• Director: Org design, stakeholder management, culture at scale

Each level’s expectations are written as observable behaviors, not abstract qualities.

---

References

Larson, W. (2021). Staff Engineer: Leadership Beyond the Management Track Larson, W. (2019). An Elegant Puzzle: Systems of Engineering Management Fournier, C. (2017). The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change Reilly, T. (2022). The Staff Engineer’s Path: A Guide for Individual Contributors Navigating Growth and Change Brooks, F. (1975/1995). The Mythical Man-Month — Brooks’s Law Meadows, D. (2008). Thinking in Systems — Systems dynamics applied to organizations Will Larson’s blog — lethain.com — extensive writing on Staff+ engineering and engineering management Charity Majors — “The Engineer/Manager Pendulum” — charity.wtf Stripe Engineering Ladder — referenced in multiple blog posts and talks Google’s SWE Ladder — described in Software Engineering at Google (O’Reilly) Conway, M. (1968). “How Do Committees Invent?” — Datamation Will Larson — “Scaling Engineering Teams” (LeadDev talks)