> ## Content Index > Fetch the complete content index at: https://www.anndiab.com/llms.txt > Use this file to discover other available public pages before exploring further. # Friction Is Information - URL: https://www.anndiab.com/friction-is-information/ - Published: 2026-08-13T18:50:28.000Z - Updated: 2026-08-14T14:08:45.000Z - Description: A repeated question, a manual reminder, a workaround someone built just to survive the day, a downstream team absorbing extra work - none of those are annoyances to route around. Each one is the system telling you where it's under-built. - Author: Ann Diab - Tags: Systems Thinking, Process, Forcing functions, Automations *What repeated failures, workarounds, and manual dependencies can teach us about the systems underneath our work* For years, before I had a name for it, this was my reflex. A leader would come to me with a performance problem - a missed handoff, a metric sliding the wrong way, a team that kept tripping over the same rock - and where most people wanted to talk about who dropped the ball, I wanted to talk about the floor. What is the thing underneath the behavior? What did we build, or fail to build, that made this outcome the likely one? I never treated a single failure as a single failure. I treated it as evidence that a system was missing or working against us. And I've always believed in building the smallest possible thing to keep it from happening again; sometimes that's a one-line change to a form, and sometimes the small thing pulls a thread that unravels into a much larger question about what capability or enablement the whole function is missing. Both are worth chasing. You just have to be willing to follow the thread wherever it goes. Once you start looking, the tells are everywhere. The real workflow or operating system may be happening in someone's DMs: the same three questions land on them every week, and they answer every time, because they're generous and because the answer lives nowhere else. Or it's taped to someone else's monitor: a hand-written list of steps, in order, because the tool doesn't carry them and getting the order wrong costs an afternoon. These are the blueprints of missing architecture, drawn for free by the person who feels the gap every day. ## Where the instinct came from I've been quietly obsessed with hospitals for a long time. The drama, sure; but more so the rigor. I think it started with *ER* in the early aughts. I was committed to Thursday night Must See TV, and capping the lineup was a cozy late-night hour with Dr. Greene, Dr. Ross, Dr. Lewis, Dr. Carter, Dr. Benton, and faves Carol Hathaway and Jeannie Boulet. Watch enough trauma bays and you notice the protocol never bends to the chaos. A patient comes in with a mangled, bleeding leg, every instinct in the room wants to chase the blood, and the team runs the primary survey anyway - in the same fixed order every single time: airway, breathing, circulation. You secure the thing that kills fastest first, even when it isn't the thing screaming loudest for attention. The sequence carries the priority so an adrenaline-flooded human doesn't have to reinvent it from scratch. And every drug order gets called out and repeated back before it's pushed - "one of epi," "pushing one of epi" - a closed loop so a mis-heard dose can't slip through. These rules can look rigid to the point of absurd up close, but standardizing what shouldn't vary is exactly what frees a clinician to spend judgment on what genuinely does. The system carries the safety so a tired human at 3 a.m. doesn't have to remember to. Hospitals gave me that vocabulary I didn't know I was looking for: **forcing functions**. Oxygen and nitrous oxide outlets have physically different nozzles, so the wrong gas can't be plugged into the wrong port; feeding tubes use connectors that won't attach to an IV line; a nurse can't pull a medication until the barcode on the drug matches the one on the patient's wristband. None of it depends on anyone being careful. The care is designed into the shape of the thing. You've got to find the place where success depends on a human remembering, knowing, checking, or noticing - and build that dependency into the system instead of hoping for vigilance. What I love just as much is the second half of that story. The best hospitals didn't stop at rigid protocols. They borrowed from aviation and gave the most junior person in the room the authority to stop the line. A nurse reading a central-line checklist out loud can halt a physician mid-procedure if a step gets skipped - no rank, no retaliation, no waiting. The mature version of a system isn't one that removes all judgment; it's one that knows exactly where judgment belongs and protects the right to use it. Rigid where the stakes are fixed, open where the situation is genuinely new. ## The mantras I collected along the way Two phrases have stuck with me, and those in my orbit appreciate and repeat them as mantras. "Slow is smooth, smooth is fast." (Adapted by multiple productivity gurus since its first uses in the military.) I've watched more projects die from the rush than from the pause. Taking the time to understand the terrain before you move through it isn't the enemy of speed; it's the source of it. And from James Clear's *Atomic Habits*: "You do not rise to the level of your goals. You fall to the level of your systems." I can't tell you how much this reframed things for me. Goals are wishes with good posture. When the pressure is on and everyone is tired, people don't perform at the height of their ambition; they settle to whatever the system makes easy. So if you want a different outcome, don't give a better speech. Build a better floor. ## Putting a name on it The first time I saw my own thinking reflected back at me in print was in Donella Meadows' *Thinking in Systems: A Primer*. She writes: > "You think that because you understand 'one' that you must therefore understand 'two' because one and one make two. But you forget that you must also understand 'and.'" So much of what goes wrong in organizations lives in the "and" - the connective tissue between two things that each work fine on their own. Onboarding exists and the knowledge base exists, but nothing links the new hire's first week to the answers they'll need. Product ships a feature and Support is ready to help, but no reliable flow carries the change from one to the other, so it rides on someone remembering to mention it. The parts are rarely the problem. The relationships between the parts almost always are. ## Why I've hit the brakes on "good" projects Understanding the "and" is also why I've stopped improvement projects that were already in motion - which does not always make you popular in the moment. More than once I've looked at a plan that would genuinely fix the thing in front of us and asked what it does three steps downstream. What new friction does this introduce for the team nobody in this room represents? What does the person at the end of this chain now have to absorb that they didn't before? A fix that solves one problem and seeds two others isn't a fix; it's a transfer. The question I try hardest to get into the room before we ship anything that runs on its own is the least glamorous one: what happens the first time the input is wrong? Automations don't hesitate. They do the wrong thing exactly as fast and as confidently as the right thing, at scale, and they keep doing it until a human happens to notice - which is why the moment to ask is before it's live, not after the cleanup. A tenured engineer once told me he valued that I got things done - but what he really valued was that I asked the hard questions, the ones even he, deep in the system, hadn't thought to ask. I've held onto that, because it names the tension I try to live in: enough drive to actually ship, enough restraint to make sure what I ship makes the whole system healthier and not just this one corner of it. But you don't always get to pull the brake. Sometimes the question doesn't get asked, or doesn't get heard, and you meet the automation on the other side instead - already live, running clean and confident and wrong. ## Fast and wrong at the same time I've met that automation on the other side more than once, and the shape is always the same, so let's walk through it. A team is drowning in manual work - enrollments, payments, processed by hand, slowly, one at a time. It's tedious and expensive and everyone can see it, so the obvious move is to automate it. Reasonable. Overdue, even. But here's what the manual slowness was doing that nobody wrote down: the person doing it by hand was also, without quite naming it, checking one thing against another - is what we're about to pay for what this member actually elected? The drudgery and the check were tangled together in the same pair of hands. Automate the task without the people who understood why it was slow, and you strip the check out along with the tedium. Now the process pulls whatever the carrier's records say is due and pays it - fast, clean, at scale - and never asks whether those records match what the member chose. The day the carrier's records are wrong, the automation does the wrong thing exactly as confidently as the right one, and keeps doing it until a human happens to notice. The smallest fix is a read-back: put expected next to actual and flag every place they disagree - the same closed loop as "one of epi, pushing one of epi," just with dollars instead of doses. But the better fix is upstream of the code entirely: build the automation with the person who'd been doing it by hand in the room, because they're the only one who knows which part of the slowness was drag and which part was a control. The lesson isn't "automation is dangerous." It's the question nobody got to ask: what happens the first time the input is wrong? Because when the records are wrong and nothing's been built to catch it, the payment goes out before anything checks whether it's right. Smooth is not the same as correct; don't sand every bit of friction out of the process and, in the doing, sand off the one piece that is load-bearing. ## Not all friction is the same A forcing function is friction too, deliberately installed. The mismatched gas nozzles, the barcode that won't scan, the dose read back out loud: every one of those is a small, engineered inconvenience, and every one is there on purpose. So friction isn't uniformly a symptom. Emergent friction - the workaround, the repeated question, the downstream team absorbing extra work - is the system saying "under-built." Designed friction - the check, the read-back, the step you can’t skip - is the system saying "load-bearing." The whole skill is telling the two apart: pull the friction that's a symptom, and protect the friction that's a control. Get it backwards and you either leave people suffering around a gap, or you "streamline" away the exact step that was keeping someone safe. So the word to the wise is simple: before you sand a piece of friction away, make sure you know what it was holding up. The step that feels like pure drag is often the one quietly keeping something from going wrong - and you don't find out what it was preventing until it's gone and the thing it prevented shows up. ## The through-line Whatever the problem in front of me, my mind runs the same route to the floor. Whether I'm redesigning onboarding, building compliance evidence into the flow of ordinary work, moving knowledge off the one overloaded expert, or catching a payment automation that was fast and wrong at the same time - I'm looking for the un-designed dependency and asking whether the coordination can be built rather than remembered. And I never stop at the moment of execution. A checklist being complete is not the same as a new hire being ready to work on their own. A ticket being closed is not the same as the customer's problem being gone. An automation running is not the same as the correct payment landing. The process executing tells you almost nothing; only the downstream state does. So I design for the outcome and close the loop back to the process, because a system that can't tell you whether it actually worked isn't finished; it's just running. A customer implementations team once built a metric around onboarding meeting time - shorter was better. I asked why the speed of an onboarding call was the thing we'd want to optimize. They were really trying to find what could be automated when facing a large volume, which was a fair instinct aimed at the wrong target: a rep can win on meeting time by rushing past the very questions that make a customer ready, so the metric will reward the opposite of the outcome. Obviously the more customers we can onboard, the more we grow revenue. But the right question wasn't "Can we optimize on time?" It was "Which parts of onboarding genuinely don't require judgment?" Which is really a way of saying I've learned to treat friction as information. A repeated question, a manual reminder, a workaround someone built just to survive the day, a downstream team quietly absorbing extra work - none of those are annoyances to route around. Each one is the system telling you where it's under-built. So when something goes wrong more than once, I try not to ask who needs to try harder. I start somewhere else: what does this outcome currently depend on a person remembering, noticing, knowing, translating, or checking? That's almost always where the design has something to tell you. People are not the point of failure to be engineered out. They're the reason to build the system well. A trained organization teaches people what they're supposed to remember; an enabled one redesigns the environment so they don't have to carry the unnecessary complexity in their heads at all. Get that right and on the hard days, the tired days, the 3 a.m. days, the right thing is also the easy thing - and the humans are freed up for the judgment only they can bring.