Case Study: Scaling the Organization
This case study explores how a Staff+ engineer helped scale an engineering organization from 30 to 150 engineers while maintaining productivity and code quality.
Context
The Situation
**Company:** B2B SaaS platform
**Growth:** 30 → 150 engineers in 18 months
**Challenges:**
- Onboarding taking 3+ months to productivity
- Architecture knowledge in few heads
- Inconsistent practices across teams
- Technical debt accumulating rapidly
- Cross-team coordination becoming painful
Your Role
As a Staff Engineer, you've been asked to help the organization scale effectively. This isn't a project with a clear end—it's an ongoing effort to build sustainable engineering practices.
Problem Analysis
Symptoms Observed
## Engineering Health Assessment
### Velocity
- Story points delivered per engineer: Declining 20% QoQ
- Time to first PR for new hires: 4-6 weeks
- PRs waiting for review: Average 3 days
### Quality
- Production incidents: Up 150% YoY
- Bug escape rate: 15% (target: 5%)
- Test coverage: Declining (70% → 55%)
### Satisfaction
- Engineer NPS: 35 (down from 65)
- Voluntary attrition: 18% (industry: 12%)
- Exit interview themes: "Chaos", "No growth", "Burnout"
Root Cause Analysis
Solution: Engineering Effectiveness Program
Initiative 1: Developer Experience Platform
## Golden Path Initiative
### Goal
Create a "golden path" - the default, well-supported way to build
and deploy services at our company.
### Components
#### Service Template
```bash
# Create new service with all standards built-in
dotnet new company-service -n OrderService
# Includes:
# - Project structure
# - CI/CD pipeline
# - Observability (logs, metrics, traces)
# - Health checks
# - API documentation
# - Test scaffolding
# - Security scanning
Platform CLI
# Common operations automated
platform service create order-service
platform service deploy --env staging
platform db migrate
platform secrets set API_KEY
platform logs tail order-service
Results
- New service setup: 2 weeks → 2 hours
- Onboarding to first deploy: 4 weeks → 3 days
- Consistency across 40+ services
### Initiative 2: Documentation System
```markdown
## Documentation Architecture
### Principles
1. **Docs as Code:** Documentation lives with code
2. **Single Source:** One place for each type of doc
3. **Discoverable:** Search across all documentation
4. **Maintained:** Ownership and freshness tracking
### Structure
docs/ ├── getting-started/ # Onboarding ├── architecture/ # System design docs │ ├── decisions/ # ADRs │ └── diagrams/ # C4 diagrams ├── guides/ # How-to guides ├── runbooks/ # Operational procedures └── api/ # API documentation (generated)
### Freshness Tracking
```yaml
# Every doc has metadata
---
title: Order Service Architecture
owner: @commerce-team
last_reviewed: 2024-01-15
review_frequency: quarterly
---
Results
- Onboarding satisfaction: +40%
- "Can't find docs" complaints: -80%
- Architecture knowledge spread across teams
### Initiative 3: Technical Standards
```markdown
## Engineering Standards Program
### Approach
Not top-down mandates, but collaborative standards with buy-in.
### Process
1. **Identify need:** Teams struggling with inconsistency
2. **Working group:** Representatives from affected teams
3. **RFC:** Propose standard with rationale
4. **Feedback period:** 2 weeks for input
5. **Adoption:** Gradual rollout with tooling support
### Standards Created
#### API Standards
- REST conventions (naming, versioning, errors)
- Authentication patterns
- Rate limiting requirements
- Documentation requirements
#### Code Standards
- Repository structure
- Testing requirements (unit, integration, e2e)
- Code review guidelines
- Security requirements
#### Operational Standards
- Logging format
- Metrics naming
- Alerting thresholds
- Incident response
Initiative 4: Architecture Guild
## Architecture Guild
### Purpose
Cross-team forum for architectural alignment and knowledge sharing.
### Structure
- **Core members:** Staff+ engineers (8 people)
- **Rotating members:** Senior engineers from each team
- **Cadence:** Weekly 1-hour meeting
### Responsibilities
1. Review significant architectural changes
2. Maintain technology radar
3. Create and update standards
4. Mentor engineers on architecture
5. Coordinate cross-team technical initiatives
### Meeting Format
- 15 min: Updates on ongoing initiatives
- 30 min: Architecture review (1-2 proposals)
- 15 min: Open discussion / Q&A
### Artifacts
- Architecture Decision Records
- Technology Radar (quarterly)
- Technical Strategy document
- Standards documentation
Initiative 5: Onboarding Program
## Engineering Onboarding Redesign
### Week 1: Foundation
| Day | Morning | Afternoon |
|-----|---------|-----------|
| Mon | Company overview | Dev environment setup |
| Tue | Architecture overview | First PR (docs fix) |
| Wed | Team introductions | Pair programming |
| Thu | Domain deep-dive | Small feature |
| Fri | Security training | Deploy to staging |
### Week 2: Integration
- Assigned buddy (peer)
- Assigned mentor (senior)
- First on-call shadow
- First production deploy
### Week 3-4: Contribution
- First feature independently
- First code review given
- First incident participation
- 30-day check-in
### Onboarding Checklist (Automated)
```yaml
onboarding:
day_1:
- laptop_setup: automated
- accounts_created: automated
- slack_channels: automated
- calendar_invites: automated
week_1:
- first_pr: tracked
- architecture_overview: scheduled
- buddy_assigned: required
week_2:
- first_deploy: tracked
- oncall_shadow: scheduled
Results
- Time to first PR: 4 weeks → 2 days
- Time to productivity: 3 months → 6 weeks
- New hire satisfaction: +50%
## Measuring Success
### Engineering Metrics Dashboard
```markdown
## Quarterly Engineering Health Report
### Velocity Metrics
| Metric | Q1 | Q2 | Q3 | Q4 | Trend |
|--------|-----|-----|-----|-----|-------|
| Deploys/day | 5 | 12 | 25 | 40 | ↑ |
| Lead time (days) | 14 | 10 | 5 | 3 | ↓ |
| PR review time (hrs) | 72 | 48 | 24 | 8 | ↓ |
| Story points/eng | 8 | 10 | 12 | 13 | ↑ |
### Quality Metrics
| Metric | Q1 | Q2 | Q3 | Q4 | Trend |
|--------|-----|-----|-----|-----|-------|
| Production incidents | 45 | 38 | 22 | 15 | ↓ |
| Bug escape rate | 15% | 12% | 8% | 5% | ↓ |
| Test coverage | 55% | 62% | 70% | 75% | ↑ |
| MTTR (minutes) | 120 | 90 | 45 | 30 | ↓ |
### People Metrics
| Metric | Q1 | Q2 | Q3 | Q4 | Trend |
|--------|-----|-----|-----|-----|-------|
| Engineer NPS | 35 | 45 | 58 | 68 | ↑ |
| Voluntary attrition | 18% | 15% | 12% | 9% | ↓ |
| Onboarding time (weeks) | 12 | 8 | 6 | 4 | ↓ |
| Internal mobility | 5% | 8% | 12% | 15% | ↑ |
Challenges Faced
Challenge 1: "Not Invented Here"
## Problem
Teams resist adopting shared tooling. "We built our own and it's better."
## Solution
1. **Listen first:** Understand why they built their own
2. **Incorporate good ideas:** If their solution is better, adopt it
3. **Make switching easy:** Migration tooling, not mandates
4. **Show value:** Teams that adopted saw 2x deploy frequency
## Result
After 6 months, 90% voluntary adoption of platform tooling
Challenge 2: Standards Become Bureaucracy
## Problem
Standards slow teams down. "We have to get architecture approval
for everything now."
## Solution
1. **Right-size reviews:** Only significant changes need review
2. **Async first:** Most reviews via RFC, not meetings
3. **Clear criteria:** Checklist for what needs review
4. **Fast turnaround:** 48-hour SLA for reviews
## Review Criteria
Needs architecture review if:
- New service or major component
- New external dependency
- Breaking API change
- Security-sensitive change
- Cross-team impact
Does NOT need review:
- Feature work within existing patterns
- Bug fixes
- Refactoring within a service
- Dependency updates
Challenge 3: Maintaining Momentum
## Problem
Initial enthusiasm fades. "We're too busy for process improvements."
## Solution
1. **Quick wins:** Prioritize high-impact, low-effort improvements
2. **Celebrate success:** Monthly demos of improvements
3. **Measure and share:** Dashboard visible to all
4. **Embed in teams:** Champions in each team
5. **Executive support:** Engineering effectiveness in OKRs
Key Learnings
## What Worked
1. **Collaborative standards:** Teams own standards they helped create
2. **Platform thinking:** Invest in developer experience
3. **Measure everything:** Data drives decisions and proves value
4. **Start small:** Pilot with willing teams, then expand
## What I'd Do Differently
1. **Start documentation earlier:** Knowledge loss is expensive
2. **Hire for platform team sooner:** Underestimated investment needed
3. **More communication:** Over-communicate changes and rationale
4. **Celebrate failures:** Learning from what didn't work
## Advice for Others
1. You can't mandate culture change - model it
2. Find your champions in each team
3. Make the right thing the easy thing
4. Progress over perfection
5. This is a marathon, not a sprint
The Staff+ Engineer's Role
## How I Spent My Time
### Typical Week
- 30% Hands-on technical work (tooling, reviews, coding)
- 25% Meetings (guild, 1:1s, planning)
- 20% Documentation and communication
- 15% Mentoring and teaching
- 10% Strategic thinking and planning
### Key Activities
1. **Technical:** Built initial service template, reviewed architectures
2. **Process:** Designed RFC process, created standards
3. **People:** Mentored 8 engineers, led guild meetings
4. **Communication:** Monthly all-hands updates, documentation
### Impact Multiplier
My code touches 1 service.
My template touches 40 services.
My standards touch 150 engineers.
My mentoring creates future Staff engineers.
💡 Flashcard
What is a 'Golden Path' in engineering organizations?
Click to reveal answer✅ Answer
A Golden Path is the default, well-supported way to build and deploy services. It includes templates, tooling, and documentation that make following best practices the easiest option, reducing cognitive load and ensuring consistency.
Click to see question💡 Flashcard
How should engineering standards be created in a scaling organization?
Click to reveal answer✅ Answer
Collaboratively through working groups with team representatives, not top-down mandates. Use RFCs for proposals, allow feedback periods, and support adoption with tooling. Teams are more likely to follow standards they helped create.
Click to see questionLoading quiz...