"The reaction to failure is not a linear function of the weight or impact of the failure. We have seen lower impact failures produce stronger reactions than high impact ones."
www.adaptivecapacitylabs.com/2026/03/07/o...
The people behind and part of this community have been a huge influence on my own learning and progression around systems thinking and resilience engineering. I’m glad to see the community organizing itself—and to be a member of it all.
Resilience engineering is about how successful systems are able to modify themselves to deal with a shock that is outside of what they can handle. This video by David Woods illustrates this phenomenon using the real-life example of an ER dealing with an influx of burn patients.
youtu.be/duNMGTmZ4FA
Part of Resilience Engineering is knowing Compensation happens, and knowing how to protect, foster, and build on this type of capacity to keep systems successful; keeping it invisible increases the chances it reaches saturation, and fails in a cascade.
Posted on @resilienceinsoftware.org
Folks who would respond that way completely misunderstand the concept. ‘blameless’ doesn’t mean “getting off the hook” or not accountable. Ugh.
Does anyone have first-hand experience with using an AI agent that has “participated” in the response to an actual incident in a genuinely diagnostic — or otherwise contextually-specific way?
Comedy is about taking chances, Av. You took a chance.
There are a couple of phrases I genuinely despise. One of them is "...we're at an inflection point..."
1. That's not how inflection points work.
2. Hindsight's a helluva drug, isn't it?
3. Just say you are at a loss to explain some recent surprises. It's honest and not unnecessarily dramatic.
@staysaasy.bsky.social I’m not on X very much, finally collected notes on the post docs.google.com/document/d/1...
Hi, 👋 that right there, is me.
For leaders with expectations about how more productive, efficient, etc. the software engineers in their org will be with AI:
1. How are you handling the "Left-Over Principle" challenges?
2. Also: customer comms about the incidents involving code produced AI?
(Seems clear #2 is depends on #1)
Another real life demonstration of Ironies of Automation
Incidents happen because people do things that have always worked successfully, up until the incident. Doing something that always worked in the past is completely rational!
Come on, @gergely.pragmaticengineer.com. You and I talked about the hindsight bias trap on your podcast. Don’t also fall for this trap as well:
www.adaptivecapacitylabs.com/2021/08/22/w...
Yes, and when inevitably: “Oh…huh…whoa, how come you’re doing it like that?”
They’ve got a story for you. 😀
As if there was any other route!
I'm now talking with Hamed Silatani, Alex Hibbitt, and Beth Adele Long about the various Catch-22 situations leaders find themselves in when responding to incidents!
www.linkedin.com/events/incid...
As Richard Cook notes, in reflecting on the data collected from the SNAFU Catchers Consortium: "It's hard to know who is monitoring the system, who is looking at things, and who is available. We know for certain in (some organizations) that there is a pretty well defined group of people who are in high-frequency update mode more or less continuously while awake. This is a huge contributor to reducing the costs of coordination and it is invisible to everyone and therefore not on any dashboard." (Cook, personal communication)
1. PEOPLE keep things working.
2. When things break down, PEOPLE work to make the consequences much less than they might have been otherwise.
Both dynamics are, for the most part, invisible to management.
(via @lauramaguire.bsky.social's dissertation)
I recently read the paper "Towards Joint Activity Design Heuristics: Essentials for Human-Machine Teaming" which I loved so much I wanted to make it easier to share. To that end, I've excerpted the Ten Heuristics from the paper here: human-machine.team with anchors for each heuristic.
What a great podcast! Honored to be talking about Resilience Engineering with @colettecello.bsky.social and @spamaps.org!
Two years ago, at the first LFI Conference, we spoke alongside a client of ours (Indeed) about the amazing progress they had made in learning effectively from incidents.
This is what "good" looks like with respect to learning effectively from incidents.
www.adaptivecapacitylabs.com/2025/02/28/w...
@allspaw.bsky.social joined us last week to help contrast ITIL's approach of "Counting and tabulating incidents" with the resilience engineering way of looking directly at the messy reality underneath them.
www.youtube.com/watch?v=cimc...
Preach! youtu.be/cimcogNc02I?... 13:30-16:30
What a great podcast! Honored to be talking about Resilience Engineering with @colettecello.bsky.social and @spamaps.org!
The Resilience in Software Foundation blog included notes I wrote for the paper "Four Concepts for Resilience Engineering" in their post today: resilienceinsoftware.org/news/1149720
Very few know we've (@adaptivecapacity.bsky.social) been developing tools to help support us. After 7 years & 6 patents (!) we realized others were interested in integrating/commercializing "Churchkey."
We’re looking for partners interested in licensing Churchkey's IP. churchkey.info
