Getting out of the Starting Blocks
summary
Argues that adoption fails because title and culture misframe the work and because teams lack mechanisms — tool, adoption path, audit — not motivation. Recommends starting with postmortem analysis to find repeat causes, measuring MTTR as the primary metric, picking a mid-performing Trojan-horse team, and shrinking blast radius. Describes a policy engine that scores teams, weekly leadership audits, and open-source failure-injection tooling on GitHub (adhorn) that kills DBs, ElastiCache, AZs and mutates Lambda responses.
AI-written summary · about
chapters (14)
- 0:00Preamble
- 1:55What prevents the wide adoption of chaos engineering?
- 2:54Why is production chaos?
- 3:45#0 - (Don't) call it (Chaos) Engineering
- 4:47#1 - Look at the Bigger Picture
- 13:20#2 - Change begins with understanding
- 24:30#3 - Choose your Trojan Horse
- 28:16#4 - Over-index on the Hypothesis
- 32:15#5 - Introduce Chaos Engineering Early in the Journey
- 35:31#6 - Blast-Radius Reduction Mindset
- 36:23#7 - If you haven't verified it, its probably Broken
- 39:43https://github.com/adhorn
- 40:50Getting out of the starting blocks
- 43:46Thank you!
related talks
29mTales from the Platform Adoption Mines
42mStart As You Mean To Go On
33mWhat Got Us Here Won’t Get Us There: A Story of Transformations
30mWhy most technology migrations fail (and what we've learned along the way)
41mLessons from Mission-Critical Systems in Fast-Moving Industries
47mOvercoming Obstacles to DevOps
01h 04mTrust and Confidence through Chaos
50mAdopting DevOps? You are Aiming at the Wrong Target!