Autonomy, is that what we really want?
summary
Argues autonomy is a fractal polarity that must be negotiated, not simply granted, and shows concrete tactics: use polarity map and collaborative modeling like event storming and user story mapping to surface boundaries; prefer bounded contexts and a diamond of coarse and fine tests over single-style unit testing; avoid feature-branching pain (he cites reviews with 12,000-line merges) by choosing trunk-based flow or pairing when signals show coupling. Recommends timeboxed enabling teams and maturity mapping to rebalance autonomy and alignment; reports these methods reduce isolation and unblock delivery.
AI-written summary · about
chapters (13)
- 0:00Intro
- 2:10What is autonomy
- 5:20Polarity map
- 15:30Feature branching
- 16:05Pairing
- 17:08Cost fallacy
- 19:23Autonomy between teams
- 22:55Architect enabling teams
- 26:43What do they need
- 30:13QA
- 32:13Polarity mapping
- 34:38Collaborative modeling
- 37:53What would you do when you see an autonomous team
related talks
49mAutonomy, is that what we really want?
47mAutonomy – From Buzzword to Business Value
47mToo Much of a Good Thing: Finding the Balance
39mAutonomous teams require great managers
41mAutonomous teams require great technical leaders
18mJourney towards autonomous teams | A coach's toolkit
39mAgility at Scale: A Meeting of Mindsets
33mExtreme Autonomy - Create Space so your Knowledge Workers Can Thrive