Feature Teams vs. Platform Pain
summary
Claims that swapping org structure doesn’t fix underlying issues: one company moves from platform teams to feature teams and back, creating a loop of the same problems. Cites Harvard Business Review 70% dysfunction and a 70% project failure rate, plus Google 2017 research naming psychological safety as the top team factor. Recommends concrete tools and practices: static analysis with detect and sonar, architecture rules with consist, trunk-based development, feature flags, and enforced pair/mob programming to make CI/CD and code quality actually work.
AI-written summary · about
chapters (19)
- 0:00Introduction
- 1:09Feature teams pain points
- 3:15Communication bottlenecks
- 5:26Waterfall in agile teams
- 7:11Problems both teams miss
- 9:19Endless team structure loops
- 10:01Engineering desires across teams
- 13:12Critique of cargo cult agile
- 16:28Misunderstanding user stories
- 18:15Real agile development
- 19:42Scaled agile neglect
- 21:28Improving team craftsmanship
- 22:34Quality compromises costs
- 23:59Fixing technical debt workflow
- 25:26Bad estimations meetings
- 27:55Feature vs platform teams
- 30:04Key questions for feature teams
- 31:50Product alignment evaluation
- 32:53Closing remarks
related talks
26mThe Rise and Fall of Feature Teams
22mThe Rise and Fall of Feature Teams
22mThe challenges of Platform teams
35mPlatform Engineering Is Not About Tech
23mPlatform Engineering for Architects - Crafting Platforms as a Product
30mTeam Topologies Applied to Platform Engineering
32mPlatform Engineering Is Not About Tech
37mPlatform as a Product for modern IT needs