Conway's Law says that systems reflect the communication structure of the organizations that created them. If your organization is slow, your software will be slow. Performance starts with people, not code.
You can have the best engineers in the world. If the organization is dysfunctional, the system will be dysfunctional.
Conway's Law in Practice
What it says
"Organizations which design systems are
constrained to produce designs which are
copies of the communication structures
of these organizations."
— Melvin Conway, 1967
Examples
Organization by technical layers:
Frontend Team
Backend Team
Database Team
Infra Team
→ System with tight coupling between layers
→ Simple changes require 4 teams
→ Constant coordination meetings
Organization by product:
Payments Team (full-stack)
Catalog Team (full-stack)
Checkout Team (full-stack)
→ Independent services
→ Independent deploys
→ Autonomous teams
Organizational Bottlenecks
1. Excessive approvals
Simple change:
1. Dev implements (1 hour)
2. Waits for review (1 day)
3. Waits for architect approval (2 days)
4. Waits for deploy window (3 days)
5. Waits for QA validation (2 days)
Total: 8 days for 1 hour of work
→ Organizational throughput: 12% efficiency
2. Dependencies between teams
Team A needs API from Team B
Team B is busy with priority C
Team A: blocked for 2 sprints
→ Organizational latency: weeks
3. Knowledge silos
Only John knows how module X works
John is on vacation
Critical bug in X
→ MTTR: days instead of hours
4. Excessive meetings
Monday: Planning
Tuesday: Sync with Team B
Wednesday: Architecture review
Thursday: Grooming
Friday: Retrospective
Time for code: 2h/day
→ 75% organizational overhead
Organizational Performance Metrics
DORA Metrics
Deployment Frequency:
Elite: Multiple deploys/day
High: 1 deploy/day to 1/week
Medium: 1/week to 1/month
Low: < 1/month
Lead Time for Changes:
Elite: < 1 hour
High: 1 day - 1 week
Medium: 1 week - 1 month
Low: > 1 month
Mean Time to Recovery (MTTR):
Elite: < 1 hour
High: < 1 day
Medium: < 1 week
Low: > 1 week
Change Failure Rate:
Elite: 0-15%
High: 16-30%
Medium: 31-45%
Low: > 45%
Flow Metrics
Flow Efficiency:
work_time / (work_time + wait_time)
Example:
Active work: 8 hours
Waiting (reviews, approvals): 72 hours
Efficiency: 8/80 = 10%
Cycle Time:
Time from start to delivery
Work in Progress (WIP):
How many items in progress simultaneously
Organizational Patterns for Performance
1. Team Topologies
Stream-aligned Teams:
- Focused on value stream
- End-to-end ownership
- Minimizes handoffs
Enabling Teams:
- Help other teams
- Temporary specialists
- Transfer knowledge
Platform Teams:
- Provide self-service
- Reduce cognitive load
- Internal APIs
2. Inverse Conway Maneuver
Instead of accepting that structure → architecture,
organize teams to produce desired architecture.
Want microservices? Create small autonomous teams.
Want modular monolith? Create single team with squads.
3. Inner Source
# Any dev can contribute to any repo
# Owners review PRs from other teams
# Reduces blocking dependencies
# Example flow
team_a_needs_feature_in_service_b():
# Instead of waiting for Team B:
team_a_implements_feature()
team_a_opens_pr_to_service_b()
team_b_reviews_and_merges()
# Result: days → hours
4. Platform Engineering
Before:
Each team configures infra: 2 days/deploy
10 teams × 2 days = 20 dev-days/sprint
After:
Self-service platform
Each team: 1 hour/deploy
10 teams × 1 hour = 10 hours/sprint
ROI: 19.5 dev-days saved/sprint
Practices that Accelerate
1. Trunk-Based Development
# Instead of long-lived branches
# Small PRs, frequent merge
git checkout main
git pull
# Small change
git commit -m "feat: add button"
git push
# PR reviewed and merged in < 4 hours
2. Feature Flags
# Deploy ≠ Release
# Code in production, feature off
if feature_flags.is_enabled('new_checkout', user):
return new_checkout(cart)
else:
return old_checkout(cart)
# Enables:
# - Continuous deploy
# - Instant rollback
# - Testing in production
3. Docs as Code
# Documentation versioned with code
# Review along with PR
# Always up to date
## Payments API
### POST /payments
Request:
...
Updated at: (auto-generated from code)
4. Automated Runbooks
# Instead of: "call John at 3am"
# Executable runbook
@runbook("High CPU Alert")
def handle_high_cpu():
# 1. Collect diagnostics
metrics = collect_cpu_metrics()
# 2. Try automatic mitigation
if metrics.is_spike:
scale_up()
return
# 3. If not resolved, escalate
page_oncall(metrics)
Measuring Progress
Organizational Dashboard
┌─────────────────────────────────────────────────┐
│ ORGANIZATIONAL HEALTH │
├─────────────────────────────────────────────────┤
│ Deploy Frequency: 12/day [ELITE] │
│ Lead Time: 2.3 hours [ELITE] │
│ MTTR: 45 minutes [ELITE] │
│ Change Failure: 8% [ELITE] │
├─────────────────────────────────────────────────┤
│ Flow Efficiency: 35% [IMPROVING] │
│ Avg Cycle Time: 3.2 days [ON TARGET] │
│ WIP per dev: 1.8 [HEALTHY] │
└─────────────────────────────────────────────────┘
Tracking over time
Q1: Lead Time = 14 days
- Reduced mandatory approvals
Q2: Lead Time = 5 days
- Implemented trunk-based
Q3: Lead Time = 1.5 days
- Feature flags for decoupling
Q4: Lead Time = 4 hours
Organizational Anti-patterns
1. Hero Culture
❌ "John saved production at 3am again!"
→ Indicates: lack of documentation, tests, automation
→ John is single point of failure
→ Burnout guaranteed
2. Blame Culture
❌ "Who deployed this?!"
→ Teams hide problems
→ Don't report incidents
→ Culture of fear
3. Process Worship
❌ "The process says it needs 3 approvals"
→ Process exists to serve, not to be served
→ Review processes regularly
→ Eliminate bureaucracy
Conclusion
Organizational performance is a multiplier:
Fast team × Slow organization = Slow system
Normal team × Fast organization = Fast system
To improve:
- Measure DORA metrics and flow efficiency
- Reduce handoffs and approvals
- Automate repetitive processes
- Empower teams with ownership
- Eliminate knowledge silos
The question isn't "how fast does your code run?" but "how fast can you change your code?"
Organizations optimized for control are slow. Organizations optimized for flow are fast.