The Rise and Fall of Feature Teams
summary
Company moves from cross‑functional feature teams back to platform silos after seeing understaffed teams, fragmented codebases and rising operational complexity; a cited Harvard Business Review stat claims 75% of cross‑functional feature teams are dysfunctional. Engineering adopts collective code ownership and scheduled mobbing/pairing to restore knowledge sharing, keeps biweekly releases and feature toggles, and spins up temporary feature teams only for large projects. Result is fewer ownership silos and better pairing, but the organization still iterates on cadence and cross‑org prioritization.
AI-written summary · about
chapters (18)
- 0:00Introduction and disclaimer
- 1:28What are feature teams?
- 3:56Spotify model inspiration
- 5:41Problems with understaffed teams
- 7:23New silos and code ownership
- 9:51Conway’s law in practice
- 10:55Trickle down KPIs
- 13:02Technical debt and crashes
- 14:49Did we misunderstand Spotify?
- 16:14Microservices fallacy
- 18:19Scale and team size
- 19:25Key-shaped engineers
- 20:30Current team structure
- 21:53Breaking old silos
- 22:36Cross-functional collaboration
- 23:37Shared vision over KPIs
- 24:41When to avoid feature teams
- 25:02Conclusion and discussion
related talks
22mThe Rise and Fall of Feature Teams
33mFeature Teams vs. Platform Pain
01h 10mAgile Cross Team Collaboration How Tos
58mDevs fight your Battle! A Pledge for cross-functional Teams
58mReturn of the rockstars? Building great teams in challenging times
46mWhy Cross-Functional Teams Build Better Microservices
45mThe Goldilocks Problem of Software Delivery
16mScaling Teams with Ownership