Unlock your autonomy. Improve your software design
summary
Argues autonomy breaks into four concrete levers—time, task, technology, people—and shows how those levers change design choices: monoliths at five–10 devs, microservices as headcount grows, platform teams exposing APIs (X-as-a-service) or collaborating when trust exists. Cites a 20,000-person University of Birmingham survey that IT reports highest autonomy, but autonomy falls as companies exceed Dunbar’s limits (150); gives a real failure: two devs produced 100 pull-request comments instead of talking. Recommends DevOps practices, pair programming and building cognitive and emotional trust as the practical route to more autonomous architecture.
AI-written summary · about
chapters (19)
- 0:00Introduction to autonomy
- 1:15Why autonomy matters
- 2:43TTP protocol of autonomy
- 6:15Autonomy in IT environments
- 7:22Company size and autonomy
- 9:12Dunbar's number and trust
- 12:36Building trust for autonomy
- 12:56Conway's Law in software
- 16:54Team topologies and design
- 18:40Cognitive and emotional trust
- 22:16Trust and engineering practices
- 25:09Trust in tiny moments
- 27:16Pair programming and vulnerability
- 30:25Human vulnerability vs system vulnerability
- 32:12Choosing your trusted circle
- 33:18Monoliths vs microservices
- 36:03Autonomy in small teams
- 37:29Unlocking autonomy in architecture
- 39:35Q&A session
related talks
39mAutonomous teams require great managers
18mJourney towards autonomous teams | A coach's toolkit
34mAutonomous Teams in Technology Organisations
08mSAG Expert Interview #11: Success Through Team Autonomy & Culture Change
27mSoftware Architects and Autonomous Teams
31mModularity in open systems
29mCultivating architecture
39mFrom code to software, a team journey