Building and Scaling Engineering Teams

Scaling an engineering team is not hiring more people. It is redesigning communication, decision-making, and knowledge sharing to work at a larger scale. The practices that work for 5 engineers break at 15. The practices that work at 15 break at 50. Each inflection point requires deliberate organizational redesign.

Team Topology Patterns

Stream-Aligned Teams

Teams organized around a flow of work — a product, a customer segment, or a business capability:

Order Team:       Owns the entire order flow (API, UI, DB, deployment)
Payment Team:     Owns payment processing end-to-end
Search Team:      Owns search experience and infrastructure
Onboarding Team:  Owns new user activation flow

Key principle: Each team can deliver value to customers independently, without waiting for other teams.

Platform Teams

Teams that provide internal infrastructure capabilities to stream-aligned teams:

Platform Team provides:
  - CI/CD pipelines
  - Kubernetes platform
  - Monitoring and logging
  - Developer experience tools
  
Stream-aligned teams consume these as self-service.

Enabling Teams

Temporary teams that help other teams adopt new practices:

Enabling Team mission: Help all teams adopt observability
  Week 1-2: Work with Order Team to instrument their service
  Week 3-4: Work with Payment Team
  Week 5-6: Create self-service documentation and templates
  Week 7-8: Dissolve — knowledge is distributed

Organizational Inflection Points

5→15 Engineers (Single Team → Multiple Teams)

Before:  One team, everyone knows everything, informal communication
After:   2-3 teams, need explicit ownership boundaries

Actions:
  - Define team charters (who owns what)
  - Establish API contracts between teams
  - Create shared on-call rotation
  - Weekly team-of-teams standup

15→50 Engineers (Teams → Organization)

Before:  Teams work independently, leads coordinate informally
After:   Need formal processes for cross-team work

Actions:
  - Engineering manager layer
  - Architecture review process
  - RFC process for cross-cutting changes
  - Quarterly planning with dependencies
  - Shared design system and patterns

50→150 Engineers (Organization → Multiple Groups)

Before:  Single engineering org with functional teams
After:   Need group structure with independent planning

Actions:
  - Engineering directors / group leads
  - Domain-specific architecture councils
  - Internal APIs treated as products
  - Platform team(s) with SLOs
  - Formal developer experience program

Hiring Pipeline

The Engineering Hiring Funnel

Sourcing        (100 candidates)
  ↓
Resume Screen   (30 pass — 30%)
  ↓
Phone Screen    (15 pass — 50%)
  ↓
Technical       (8 pass — 53%)
  ↓
System Design   (5 pass — 63%)
  ↓
Team Fit        (3 pass — 60%)
  ↓
Offer           (2 accept — 67%)
  ↓
Hired           (2 of 100 — 2%)

Interview Design

Round	Duration	Evaluates
Phone Screen	30 min	Communication, problem-solving basics, culture
Technical	60 min	Coding, debugging, code quality
System Design	60 min	Architecture thinking, trade-off analysis
Team Fit	45 min	Collaboration, values alignment, growth mindset

Onboarding

First Week

Day 1: Environment setup, meet the team, company overview
Day 2: Codebase walkthrough, architecture overview
Day 3: First PR (small, well-scoped, reviewed same day)
Day 4: Shadow on-call engineer, understand incident process
Day 5: Retrospective on onboarding experience

30-60-90 Day Plan

30 days: Ship 3-5 small features independently
         Understand the deployment pipeline
         Attend all team ceremonies
         
60 days: Own a medium-sized feature end-to-end
         Participate in code review as reviewer
         Understand 2-3 adjacent services
         
90 days: Lead technical design for a feature
         Mentor the next new hire
         Contribute to on-call rotation

Onboarding Buddy

Every new hire gets an onboarding buddy — an experienced team member who:

Answers questions they are embarrassed to ask in public
Reviews their first 10 PRs with extra detail
Has a standing 1:1 for the first month
Helps them navigate the organization

Communication at Scale

Meeting Cadence

Daily:     Team standup (15 min, async preferred)
Weekly:    Team retro (30 min), Tech leads sync (30 min)
Biweekly:  1:1s with direct reports (30 min each)
Monthly:   All-engineering meeting (30 min), Architecture review
Quarterly: Planning, OKR setting

Decision-Making Framework

Type 1 (Irreversible): Architecture choices, vendor selection
  → RFC process, broad review, explicit approval

Type 2 (Reversible): Feature implementation, tool choice
  → Team-level decision, document rationale, move fast

Default: If in doubt, it is Type 2. Bias toward action.

Anti-Patterns

Anti-Pattern	Consequence	Fix
Only hiring senior engineers	No pipeline, expensive, competitive	Hire across levels, invest in growth
No onboarding program	New hires unproductive for months	Structured 30-60-90 plan
All decisions need leader approval	Bottleneck, disempowerment	Type 1/Type 2 decision framework
Teams too large (>10)	Communication overhead explodes	Split at 8 — two focused teams
No career growth framework	Retention drops at 18 months	Engineering ladder with clear levels

Scaling a team is a design problem. Every organizational decision — team boundaries, communication channels, decision rights — shapes what your engineering organization can and cannot build.