Part 6 · 2 chapters · ~15 min
Scaling and Managing Engineering Teams
Conway's law and Team Topologies: stream-aligned, platform, enabling and complicated-subsystem teams, interaction modes, cognitive load and the inverse Conway manoeuvre; then the people systems: sustainable on-call that teaches, hiring for a platform, dual-track growth, the platform's customers, and scaling the organisation.
13
Team topologies and Conway's law
designing teams is designing architecture
- Conway's law: the system mirrors the communication structure of the organisation that built it.
- Stream-aligned teams are the default, and own their area end to end.
- Platform teams provide services. Complicated-subsystem teams own deep specialisms.
- Enabling teams teach a capability, then step back.
- Interaction modes: collaborate to discover a boundary, then switch to X-as-a-service.
- Cognitive load limits what one team can own. The inverse Conway manoeuvre reshapes teams to get the architecture you want.
a frontend example
A "frontend team" serving five product teams turns into a queue and a bottleneck: every feature waits for it. Stream-aligned teams with frontend engineers in them, plus a design-system platform team and an enabling team for accessibility and performance, is the shape the Big-company FE course part 0 describes.
TEAM TOPOLOGIES AND CONWAY'S LAW
four team types, three interaction modes, and the architecture your org chart will produce whether you plan it or not
swipe the figure sideways, or tap expand for full screen
1/6
Conway's law
Conway's law in practice: three teams building a compiler produce a three-pass compiler; a frontend team, a backend team and a database team produce a three-tier system with hand-offs at every boundary. If you want independently deployable services owned end to end, you need teams that own them end to end.
14
On-call, hiring, growth paths and the platform's customers
the people systems
- Sustainable on-call: rotations of six, compensated time, a cap on pages.
- On-call that teaches: shadowing, runbooks, blameless reviews, written handovers.
- Hiring: builders, operators and product-minded engineers, interviewed on the actual work.
- Growth paths: a dual track. Staff-level work is direction, strategy and unblocking others.
- The platform's customers: a public roadmap, regular reviews, a support SLA, and a clear no when needed.
- Scaling the organisation changes communication paths. Plan a reorganisation like a migration.
| signal | healthy | unhealthy, and what to do |
|---|---|---|
| pages per on-call week | 0 to 3 actionable | 10+: freeze features, fix the top alert sources |
| after-hours pages | rare | frequent: move batch work, fix alert thresholds, add self-healing |
| incident review actions done in 30 days | 80%+ | under 50%: fewer, better actions with owners and dates |
| time for a new hire to first on-call | 6 to 10 weeks with shadowing | day one, alone: retention risk |
| staff engineers' time | direction, reviews, hardest problems | all in tickets: no one holds the technical direction |
ON-CALL, HIRING AND GROWTH PATHS
the people systems that decide whether the infrastructure keeps working and the engineers keep staying
swipe the figure sideways, or tap expand for full screen
1/6
sustainable on-call
On-call that is sustainable: you build it, you run it, so each team is on call for its services; rotations of at least five or six people so each is on one week in five or six; primary and secondary; compensated time; a cap on pages per shift (two or three actionable pages a week is a healthy upper bound; more is an engineering priority, not a personal burden).