E-shaped engineers, two-pizza teams, loose coupling
Once you've decided on market orientation, two design questions remain: what shape of engineer do you grow, and how big can a team get before it stops working? Both answers also force architectural choices.
You need engineers who've achieved mastery in specific tech areas — but not "specialists frozen in time" who can only contribute to one slice of the value stream. The DevOps Handbook calls the target the E-shaped engineer:
Years of solving real problems in production.
Deep mastery in 1–2 areas they can teach others.
Curious about adjacent areas — picks up new tech.
Ships. Not theory — working code in production.
The DevOps Handbook claim: cross-trained generalists do orders of magnitude more work than specialist counterparts — because they remove queues and wait time, not because they type faster.
Amazon's heuristic: if you can't feed a team with two pizzas, it's too big. Practically, that's ~5–10 people. Four reasons it works:
Communication scales combinatorially. 5 people = 10 pairs; 20 people = 190 pairs. Past a point, nobody can know what's going on.
Limits the surface area of what one team owns — forces clean boundaries between products.
Small teams have autonomy; decisions don't escalate. Faster, more accountable.
More teams = more lead roles. People grow into them.
Two-pizza market-oriented teams only work if the architecture lets them. Loose coupling means:
- — Services update in production independently — no flag-day cross-service releases.
- — Services are decoupled from each other.
- — Services are decoupled from shared databases. Sharing a database service is OK; sharing schemas isn't.
- — Team A can deploy without coordinating with Team B's calendar.
"Organizations with these types of service-oriented architectures, such as Google and Amazon, have incredible flexibility and scalability. These organizations have tens of thousands of developers where small teams can still be incredibly productive."
// Randy Shoup — former Engineering Director, Google App Engine.
A team grew from 8 to 25 engineers over a year. Standups now take 45 minutes and decisions stall. What does the two-pizza rule suggest?
// pick one to verify
An org runs 60 microservices, but every service reads from and writes to the same shared schema. Is this a service-oriented architecture?
// pick one to verify