Autonomy, is that what we really want?
summary
Argues that autonomy must be balanced across code, team, cross-team and organizational levels using concrete practices: use polarity mapping to manage the isolation vs connectedness tradeoff; apply Domain‑Driven Design and a bounded context to keep shared purpose; choose between solitary and sociable tests, prefer collaborative acceptance tests; limit long‑lived feature branches (heuristic: max one day branches), do continuous code review and pairing; leadership defines boundaries and negotiates decision rights so teams gain agency without fragmenting the system.
AI-written summary · about
chapters (7)
- 0:00Start
- 5:16Autonomy can be compulsive
- 21:10Autonomy IS NOT dictatorship
- 23:08Autonomy is not an excuse to hold something against someone
- 34:46Enabling teams actively avoid becoming ivory towers of knowledge. dictating technical choices for other teams to follow.
- 38:08Vision, boundaries, or both?
- 42:28When there's autonomy everywhere, do we still need managers and architects?
related talks
43mAutonomy, is that what we really want?
47mAutonomy – From Buzzword to Business Value
49mSelforganisation needs Leadership
01h 10mAgile Cross Team Collaboration How Tos
32mLet’s build sustainable and empathetic cross-functional teams
20mWorking with Others and Delivering as a Team — Bridges Seen Through Human Relationships
35mPlease Understand Me
44mThe socio technical developer