I was looking at my to-do list this morning and realized it is basically just a graveyard for dreams I have no intention of fulfilling. It is a digital monument to my own procrastination. But today is prompt from Daniel is about the kind of lists that actually keep people alive, or at least keep multi-billion dollar businesses from imploding into a pile of regulatory fines and technical debt. Daniel is asking us to look at checklists and standard operating procedures, specifically outside the context of aviation. We are moving beyond the cockpit to see how these things work in the rest of the world, from the operating room to the server room and even the venture capital boardroom.
It is a brilliant topic because most people have a very love-hate relationship with the idea of a standard operating procedure. We love the safety they provide, but we hate the perceived bureaucracy. I am Herman Poppleberry, and I have spent way too much time reading about the cognitive science of why these things work and why they so often fail. There is this massive paradox at the heart of this, which Atul Gawande famously explored in The Checklist Manifesto. We tend to think we are too smart for a checklist. We think our expertise exempts us from the need for a simple list of steps. But then the moment the stress hits, or the moment the complexity of the system exceeds our working memory, our brains basically turn into wet cardboard.
It is the expert bias, right? If you have done something a thousand times, you feel like a checklist is an insult to your intelligence. It feels like you are being treated like a trainee on your first day. But then you forget that one tiny toggle, or you skip one "obvious" safety check, and suddenly the server room is on fire or the patient is having a very bad day. We see this in tech all the time. The senior engineer who has deployed a thousand times is often the one who causes the biggest outage because they stopped looking at the documentation.
That is the core of the issue. We have this distance between the written procedure and the actual execution, which I like to call the standard operating procedure gap. Most corporate documentation ends up as what we call shelfware. It is written by someone in a compliance department to satisfy an auditor or a legal requirement, but the person on the ground never looks at it. Why? Because it is too bloated, it is out of date, or it simply does not reflect the messy, non-linear reality of the job. When the procedure is a forty-page document of legalese, the human brain just filters it out as noise.
So before we get into the weeds of how to fix that gap, we should probably define the two main flavors of these things. I know you have a distinction you like to make between do-confirm and read-do. This feels like the foundational architecture of the whole conversation.
It is a critical distinction that most people miss when they start drafting these. A read-do checklist is exactly what it sounds like. You read the step, then you perform the step. This is for complex, infrequent tasks where you cannot afford a single mistake. Think about decommissioning a chemical reactor, or setting up a brand new, multi-region server architecture from scratch. You are following a recipe in real time because the sequence is too complex or too rare to be committed to muscle memory. You are essentially a human processor executing a script.
And the do-confirm is more like the grocery list you check right before you leave the store. You have done the shopping, you think you have everything, but you do one final pass to make sure the milk and the eggs are actually in the cart.
Precisely. In a do-confirm workflow, you perform a sequence of tasks from memory because you are an expert. You have the flow down. You are in the zone. But then you pause at a specific gateway, a "hold point," and you run through the checklist to confirm everything was actually done. This is what surgeons use. They do not read a manual while they are cutting. That would be a disaster. But they stop before they close the incision to make sure the sponge count is correct and the antibiotic was administered at the right time. It is a safety net for the expert mind.
That brings up that famous World Health Organization study from two thousand nine. I remember reading that a nineteen-item checklist reduced surgical complications by something like thirty-five percent. That is a staggering number for something that costs basically zero dollars to implement. It is probably the most cost-effective medical intervention in history.
It really was. The study was conducted in eight different cities around the world, from Seattle to New Delhi, and the results were consistent across all of them. Complications dropped by thirty-five percent, and the death rate dropped by nearly half in some of the hospitals they studied. But what was fascinating about that study is that it was not just about the technical steps. It was not just "did we wash our hands?" One of the items on the checklist was just everyone in the room introducing themselves by name and role.
Wait, how does knowing the nurse is name stop a surgical error?
It is about psychological safety and the social permission structure. It turns out that when the junior nurse knows the lead surgeon is name, and the surgeon has acknowledged her, she is much more likely to speak up if she sees a mistake. If the room is a rigid hierarchy where no one speaks, errors go unchallenged. The checklist flattens the hierarchy. It gives the junior person a "script" to follow that requires them to speak. It turns a collection of individuals into a high-functioning team.
So it is not just about memory offloading, it is about culture. But let us talk about that memory offloading for a second. You mentioned earlier that our brains turn into wet cardboard under stress. What is actually happening there technically? Why do we need these external buffers?
It is called cognitive load theory. Our working memory is incredibly fragile. Research suggests that under extreme stress, our working memory capacity can drop by nearly fifty percent. We suffer from something called attentional blink, which is a phenomenon where the brain literally fails to perceive a second stimulus if it happens too quickly after the first one. When you are in a crisis, your prefrontal cortex—the part of the brain responsible for logic and sequencing—essentially goes offline as cortisol and adrenaline take over. A checklist acts as an external hard drive for your brain. It offloads the need to remember the sequence so your brain can focus on the actual problem-solving.
I like the idea of the checklist as an external buffer. It is like we are moving the sequence from volatile RAM to a stable disk. But if that is the case, why are so many checklists so bad? I have seen standard operating procedures that are forty pages long. No one is reading that in a crisis. If my brain is already at half capacity, a forty-page document is just going to make me give up entirely.
That is the number one mistake in procedure design. People confuse a training manual with an operating procedure. A training manual is where you explain the "why." An operating procedure is where you list the "what." If your checklist has a paragraph explaining why a step is important, you have already failed. A good procedure should be lean and imperative. There is this concept called the seven plus or minus two rule, or Miller is Law, which dates back to nineteen fifty-six. It suggests the human mind can only hold about seven chunks of information at once. If a section of your checklist has fifteen items, your brain will start skimming. You have to group them into logical clusters.
You also mentioned something about kill switches in complex workflows. I love that term. What does that look like outside of a factory or a nuclear plant?
A kill switch is a go or no-go point. It is a hard boundary. In software deployment, for example, a good procedure has a specific step that says: "If the latency is over two hundred milliseconds at this stage, stop everything and roll back." It removes the ambiguity of the decision. You are not standing there at three in the morning, exhausted, wondering if "maybe it will stabilize." The procedure has already made the hard choice for you when you were calm and rational. It is a gift from your past self to your future, stressed-out self.
I think Daniel probably sees this a lot in his world of automation and technical communications. If you are writing a script to automate a cloud environment, that script is essentially a digital standard operating procedure. It does not get tired, and it does not have an ego. But we are still the ones writing the scripts. How do we identify which tasks actually need this level of rigor? Because if you make everything a procedure, you just end up with a massive bureaucracy that everyone hates. You end up in that "bureaucratic labyrinth" we talked about in episode seven hundred sixty-five.
You have to look for the high-consequence, low-frequency events. If you do something every single day, like making coffee or checking your email, you likely have the muscle memory. You might still need a do-confirm list for the critical bits, like "did I actually hit send on that invoice?" but you do not need a manual. The real danger zone is the task you do once every three months. You are just familiar enough to be dangerous, but not practiced enough to be perfect. That is where you need a read-do list. It is the "uncanny valley" of competence.
What about the tradeoff between rigidity and agility? I am thinking about something like a high-frequency trading desk versus a nuclear power plant. In a power plant, you want absolute, rigid adherence to the manual. But in a fast-moving market, if you are stuck reading a thirty-page document, the opportunity is gone. The market has moved on while you were checking step fourteen.
That is where heuristic-based checklists come in. Instead of a list of specific actions, you provide a list of mental checks or boundaries. In high-stakes trading or rapid-response environments, the checklist might be three questions: Is our exposure within the limit? Is the volatility index below thirty? Is the counterparty liquid? If the answer to any of those is no, you pull the plug. It is about speed and safety, not just blind following of steps. It is about defining the "safe operating envelope" and then letting the expert navigate within it.
We talked about aviation in the past, specifically in episode thirteen hundred fifty-five when we discussed those ninety-second sprints for home safety. One thing that sticks with me from that is how procedures can drift over time. You start with a perfect list, but then the software changes, or the team changes, and suddenly step four doesn't make sense anymore. So you just start skipping it. And once you skip step four, skipping step five doesn't seem like a big deal.
That is exactly what sociologist Diane Vaughan called the normalization of deviance. She coined the term while investigating the Challenger disaster in nineteen eighty-six. It is the process where people become so accustomed to a small deviation from the procedure that it stops feeling like a risk. The standard operating procedure says you need two signatures, but you have been getting away with one for six months because the second manager is always in meetings. Nothing has exploded yet, so one signature becomes the new functional standard. Until the day that second signature was the only thing that would have caught a catastrophic error.
So how do you fight that? Especially in a fast-moving startup or a tech environment where things are literally changing every week. You can't have a static binder in a world of continuous deployment.
You have to treat your procedures like code. This is something we touched on in episode twelve hundred sixty-seven about the git-ification of everything. If your standard operating procedures are sitting in a static P-D-F on a shared drive, they are already dead. They need to be in a version-controlled system where the people using them can submit pull requests. If a step is broken or redundant, the person on the front lines should be able to propose a fix immediately. The documentation should be as agile as the software it describes.
I love that. It makes the procedure a living document rather than a decree from on high. It also solves the version control problem. There is nothing more dangerous than a technician following an outdated version of a safety protocol because they did not see the email update from last Tuesday. If the procedure is the "source of truth," it has to be current.
And this is where it gets really interesting when we look at the future of this with A-I. We are now in March of twenty-six, and we are starting to see the rise of what I call agentic, context-aware checklists. Imagine a system that looks at the current state of your network, realizes you are under a specific kind of D-D-o-S attack, and generates a tailored standard operating procedure for that exact moment based on your specific infrastructure. It is not just a static list anymore; it is an active partner in the workflow. It is pulling in real-time telemetry and saying, "Based on the current load, you need to execute these five steps in this order."
That sounds great, but does it not risk making us even more dependent? If the A-I is generating the checklist, do we lose the ability to think for ourselves when the system goes down? It is the "automation irony"—the more reliable the automation, the less prepared the human is to take over when it fails.
That is the tension. You want the system to handle the low-level sequence so you can handle the high-level strategy. If you are a doctor using an A-I-generated checklist for a rare condition, the A-I ensures you do not forget a rare drug interaction, which allows you to focus on the patient is immediate physical response. It is about augmenting expertise, not replacing it. We are moving toward a world where the "checklist" is an invisible layer of the environment, prompting us only when we deviate from the safe path.
Let us look at some of the non-technical industries. I was reading about a famous venture capital firm that uses a checklist for every single investment meeting. They are not looking at technical specs; they are looking for cognitive biases. They have a list of questions like: "Are we only excited about this because the founder is charismatic?" or "Are we ignoring a competitor because we do not like their C-E-O?"
That is a brilliant application. It is a checklist for the ego. We are all prone to confirmation bias and the halo effect. By forcing yourself to answer those questions before you write a check for ten million dollars, you are building a speed bump for your own impulsivity. It is the same logic as the surgical checklist, just applied to financial risk. It is about creating a "Verification Loop." A checklist without a feedback mechanism is just a list of suggestions. You need a moment where you have to physically or digitally sign off that the check was performed.
It seems like the common thread here is that a good checklist is actually a tool for freedom. If I do not have to spend my mental energy worrying if I turned off the oxygen or if I checked the sub-domain records, I can actually do the high-value work I was hired for. It is about reducing the cognitive tax.
But to get there, you have to be ruthless about the design. If you are drafting these for your team, you have to write for the stressed self. You have to assume the person reading this is tired, they are being yelled at by a client, and they have a headache. They do not want beautiful prose. They want clear, imperative verbs. "Check the logs." "Verify the port." "Deploy the patch." No fluff. No adverbs. Just action.
I also think there is a lot of value in what you called the sunset clause. If a procedure has not been touched in six months, does it still deserve to exist? In the world of tech, six months is an eternity.
Every standard operating procedure should have an expiration date. If you have not reviewed it in a year, it is probably a liability, not an asset. You either re-validate it, or you delete it. This prevents the "procedural rot" that kills large organizations. You want a lean, mean library of procedures that people actually trust. If people know that twenty percent of the manual is out of date, they will stop trusting the other eighty percent too.
I want to pivot a bit to how we can actually implement this in our own lives or small teams. You mentioned a ten-minute audit. What does that look like in practice?
Take your most common recurring task. Maybe it is your weekly reporting, your code deployment, or even just your Monday morning planning. Look at the steps you currently take and ask yourself three questions. First, what is the one step that, if I missed it, would cause the most damage? That is your "Critical Item." Second, have I ever skipped a step because it felt redundant? If so, why is it still there? And third, if a stranger had to do this tomorrow, where would they get stuck?
That third one is the real test. If you can hand your procedure to someone who is technically competent but unfamiliar with your specific setup, and they can finish the task without calling you, you have a winner. If they have to ask you what you meant by "check the thingy," you have failed. It is the "Curse of Knowledge"—you literally cannot remember what it is like to not know what you know.
And you should literally do that. It is a form of red teaming, which we discussed in episode eight hundred ninety-three. You have to try to break your own plans. Give your standard operating procedure to a colleague and watch them try to follow it. Do not help them. Just watch. You will be amazed at how many assumptions you have baked into the text that are not actually on the page. You will see them hover over a button, unsure if they should click it, because your instructions were slightly ambiguous.
Building on that, I think we need to talk about the difference between a checklist and a standard operating procedure, because people use the terms interchangeably, but they serve different roles. A standard operating procedure is the overarching document that explains the process, the roles, and the goals. The checklist is the tactical tool you take into the field. You do not bring the whole procedure to the surgery table; you bring the checklist.
That is a clean way to divide it. If you try to cram the "why" into the checklist, you lose the speed. If you leave the "why" out of the standard operating procedure, you lose the buy-in. People need to know why they are doing something so they can exercise judgment when the situation goes off-script. Because as we know, the map is not the territory. No procedure can account for every possible variable. We are not trying to turn people into robots. We are trying to give them a solid floor to stand on so they can be more human.
That is a really important point. If the routine stuff is handled, you have the mental bandwidth to handle the weird, edge-case stuff that actually requires your expertise. It is about cognitive offloading to enable higher-order thinking. I think about this in terms of the nuclear industry. They have incredibly rigid procedures for the reactor, but they also have intensive training for how to handle what they call "beyond design basis events." Those are the situations the manual does not cover. If you have spent all your energy just trying to remember the basic cooling sequence, you are going to be useless when the earthquake hits and the pipes break in a way no one predicted.
And this applies to the world of A-I safety and alignment too. If we are building these massive models, the procedures for how we test them and how we deploy them are going to be some of the most important documents ever written. Daniel is obviously deeply involved in this. If you are doing a red teaming exercise on a new model, you need a rigorous checklist to make sure you are not just testing the easy stuff. You need to ensure that the testing is consistent across different teams. If team alpha is checking for bias and team beta is checking for prompt injection, but they are using different standards, you do not actually have a safety profile. You just have a collection of anecdotes.
So, looking forward, do you think we are moving toward a world of invisible checklists? Like, will our environments just sense what we are doing and provide the right prompts at the right time?
I think that is the trajectory. Ambient computing. If you are in a lab and you pick up a specific chemical, a heads-up display or a voice assistant might remind you of the specific safety protocol for that substance. It removes the friction of having to go find the binder or open the file. The information finds you when you need it. It is the ultimate version of just-in-time learning. But until we get there, we are stuck with the tools we have.
So, to wrap this up, what is the one thing someone should do tomorrow if they realize their team is documentation is a mess?
Pick the one process that keeps you up at night. The one where you say, "I hope nothing goes wrong while I am on vacation." Sit down and write a ten-item checklist for it. Not a twenty-page document. Just ten items. Focus on the kill switches and the high-consequence steps. Write it for your "Stressed Self"—the version of you that is hungry, angry, lonely, or tired. Then, give it to someone else and tell them to try to break it.
And if they can not break it, you might actually get to enjoy your vacation. I think that is the real takeaway. These procedures are not just about safety or efficiency; they are about peace of mind. They are a gift to your future self.
I could not have said it better. It is about being kind to the person you are going to be when the pressure is on.
Well, this has been a deep dive into the world of lists that actually matter. Thanks to Daniel for the prompt that got us thinking about this. It is one of those topics that seems dry on the surface but is actually at the heart of how everything from hospitals to hedge funds stays upright.
It is the hidden architecture of the world. I love it.
Before we go, we should give a shout out to our producer, Hilbert Flumingtop, who I am sure has a very rigorous checklist for making sure we do not sound like total idiots every week.
And a big thanks to Modal for providing the G-P-U credits that power the generation of this show. They make the technical side of this look easy, which we know it is not.
If you found this useful, or if you have your own horror stories of procedures gone wrong, we would love to hear from you. You can find us at myweirdprompts dot com for the R-S-S feed and all the ways to subscribe.
This has been My Weird Prompts.
We will catch you in the next one. Bye.
Take care.
