The immune system you didn't design
An organization's real immune system isn't the one in the policy manual. It's the one that activates when someone says 'we have a problem' and twelve people check their own house before being asked.
The organizations that survive crises aren’t the ones with the best crisis plans. They’re the ones where people check their own house the moment they hear the neighbor’s alarm.
There’s a story from hospital infection control that illustrates this. A nurse on the third floor notices an unusual pathogen in a wound culture. She doesn’t wait for the infection control committee to convene. She calls the second floor and asks if they’ve seen anything similar. They haven’t, but now they’re looking. By the time the committee meets, four floors have already checked and two have found early cases. The formal response follows, but the informal network has already contained the spread.
The policy manual said to escalate to the committee. The actual immune system was the nurse who picked up the phone.
Most organizations confuse their documented response procedures with their actual capacity to respond. The procedure matters. It’s also slow, hierarchical, and sequential. The real immune response is what happens in the hallways between the moment someone notices something wrong and the moment the official process kicks in. Those hallway conversations are where containment actually happens. If your organization has to wait for the chain of command to activate before anyone checks their own work, your immune system is decorative.
Do twelve people in your organization spontaneously check their own work if one person says “I found something wrong in mine”? If the answer is no, your crisis plan is a document, not a system.
Most hiring decisions optimize for the wrong axis. They match capability to the role. They should match capability to the task.
A hospital doesn’t send the chief of surgery to change a dressing. Not because changing dressings is beneath them, but because the chief of surgery is slower at dressings than the nurse who does twenty a day. The nurse has muscle memory. The chief has to think about it. Thinking, in this case, is overhead.
This seems obvious in medicine. It is wildly non-obvious in knowledge work. Knowledge organizations habitually assign their most experienced people to routine problems, because experience gets treated as a universal solvent. Got a scheduling conflict? Send the VP. Got a formatting issue? Ask the senior designer. Got a straightforward analysis? Give it to the PhD.
The PhD will do the analysis. They’ll also spend forty minutes wondering whether the methodology is appropriate, whether the sample size is sufficient, whether the conclusions warrant a caveat about external validity. A junior analyst would have run the numbers and had them on someone’s desk in ten minutes. Not because the junior is better. Because the junior doesn’t have the expertise to second-guess the task, and the task didn’t need second-guessing.
Frederick Taylor, history’s most hated management theorist, argued that you should match the worker to the task, not the task to the worker. He was a monster about how he said it. He was also right about the principle. Intelligence applied to a problem that doesn’t require intelligence isn’t a gift. It’s friction. The chef who redesigns the menu every time someone orders a hamburger isn’t being thorough. They’re being expensive.
The practical implication: when you look at your team’s workload, separate the tasks that require judgment from the tasks that require execution. Then be honest about which pile is bigger. In most organizations, the execution pile is five times larger. If your best people are spending most of their time there, you don’t have a talent problem. You have a routing problem.
The first customer doesn’t validate your product. They validate your organization.
There’s a moment in every restaurant’s life that happens before the first review, before the health inspector, before the food critic. It’s the first time a stranger walks in, sits down, and orders. Not a friend doing you a favor. Not an investor checking on their money. A stranger who saw your sign and decided to try you.
That stranger doesn’t test whether your food is good. They test whether your kitchen works. Can you take an order without confusion? Does the food arrive at the right table? Is the check accurate? Can you handle a substitution without a staff meeting? The food might be brilliant. If the order arrives at the wrong table, it doesn’t matter.
This is why first customers are terrifying in a way that a thousand hours of internal testing never is. Internal testing validates the recipe. The first customer validates the restaurant. Every handoff, every assumption about how information flows, every “oh, we’ll figure that out when it comes up” gets called simultaneously. You learn more about your organization in the first fifteen minutes of serving a real person than you learn in six months of building.
One corollary: if your first customer has a flawless experience, it doesn’t mean your product is ready. It means your organization is real. Those are very different achievements, and only one of them matters on day one.
A third of all effort in any organization is spent solving problems that no longer exist.
Think about this at a restaurant. The sous chef preps thirty pounds of salmon because that’s what the catering order called for. Except the catering order was cancelled at 10 AM, and the message didn’t reach the kitchen until noon. Two hours of skilled labor, wasted. Not because anyone was incompetent. Because the system that communicates cancellations is slower than the system that communicates orders.
This is a coordination problem that scales viciously. The larger the organization, the more likely it is that someone is working on a problem that someone else already solved, filing a report that someone else already filed, or preparing for a meeting that someone else already cancelled. The waste isn’t laziness. It’s latency. Information about what’s done moves slower than the impulse to do work.
Most organizations accept this as inevitable overhead. “Some duplication is the cost of decentralization,” they say, as if the only options were a command-and-control hierarchy that eliminates duplication but moves at the speed of bureaucracy, or a decentralized operation that moves fast but wastes a third of its effort on ghosts.
Neither is necessary. Transparency of state is the alternative. If every team can see, in real time, what every other team has completed, the ghost work drops to near zero. Not because you’ve centralized decision-making. Because you’ve centralized awareness. That’s a very different thing. Centralized decisions are slow. Centralized awareness is fast. The restaurant that pins completed orders on a shared board doesn’t need a manager telling the kitchen what’s done. The board tells them. The manager is freed up to do something actually useful.
An essay that changes the team that wrote it is worth more than an essay that changes a stranger’s mind.
Manifestos are written for outsiders. They declare what an organization believes, who it serves, what it stands against. They’re useful for marketing and occasionally for hiring. They are almost never useful for the people who wrote them.
But every once in a while, someone writes something about how the team works, and the team reads it and recognizes itself in a way it hadn’t before. Not “this is what we say we do” but “this is what we actually do, described so precisely that I can see the pattern for the first time.” A head chef writes about how the kitchen communicates during a rush, and the line cooks realize they’ve been doing something sophisticated without knowing it. A hospital administrator writes about how nurses handle shift changes, and the nurses realize they’ve developed a protocol that no one formally taught them.
The power of this kind of writing isn’t persuasion. It’s recognition. It holds up a mirror and says: look at what you built. The team didn’t know it was doing something remarkable until someone described it, and the description changed how they think about what they do. They don’t work differently afterward. They work the same way but with awareness. The unconscious competence becomes conscious, and conscious competence is both more durable and more transferable.
That’s the difference between a brand document and a culture document. A brand document says “we are innovative.” A culture document describes the specific way the team passes information during a crisis and lets the team decide what to call it. The brand document is for LinkedIn. The culture document is for survival.
Testing isn’t quality assurance. It’s institutional memory.
A hospital that checks every patient’s medication against their allergy list isn’t being cautious. It’s remembering. Every check encodes a lesson someone learned the hard way: a wrong dose, a missed interaction, a patient who didn’t mention their shellfish allergy until the IV was halfway in. The checking protocol is the scar tissue of every mistake the institution has survived.
When a new nurse arrives and follows the protocol, they’re not just preventing errors. They’re downloading the institution’s memory into their own practice. They’ll never know the specific incidents that created each step. They don’t need to. The protocol carries the knowledge forward without requiring the story.
This is why organizations that treat verification as overhead are eating their seed corn. Every shortcut that skips a check is a lesson the institution is choosing to forget. And institutional amnesia doesn’t hurt today. It hurts six months from now, when someone makes the exact mistake the check was designed to prevent, and nobody remembers why the check existed, because by then the person who created it has moved on.
Two hundred and thirty checks added in a single day sounds like paranoia. It’s the opposite. It’s an organization that decided to remember everything it learned today so that tomorrow’s team doesn’t have to learn it again. The investment isn’t in preventing today’s errors. It’s in preventing the recurrence of errors that today’s team won’t be around to explain.
The question organizations never ask about AI is the one that matters most: what happens to human judgment when you stop exercising it?
Surgeons who switch to robotic-assisted procedures report something unexpected after a few years. Their hands are still steady. Their knowledge is still current. But their ability to improvise during complications has declined, because the robot handles the routine so smoothly that complications become unfamiliar territory. The skill atrophied, not from disuse of the hands, but from disuse of the judgment that decides what the hands should do.
Nobody is asking this about the shift toward AI handling routine decisions. Not whether AI can do it — it obviously can. Not whether it does it well — it often does it better. The real gap is what happens to the humans who used to exercise judgment on those routine decisions. Routine decisions are where judgment gets trained. The junior analyst who runs ten straightforward analyses develops the instinct to notice when the eleventh one is subtly wrong. Take away the ten, and the instinct never forms.
The hospital that automates triage doesn’t just save time. It removes the training ground where nurses develop the intuition that tells them this patient looks fine on paper but something is off. That intuition was built by seeing thousands of patients who were fine and noticing the ones who weren’t. Automate the sorting, and the next generation of nurses never builds that pattern library.
This isn’t an argument against automation. It’s an argument for being honest about the trade. You gain efficiency. You lose a training pipeline for human judgment. If you don’t replace that pipeline with something deliberate, you’ll wake up in five years with a team that can’t function without the system you built to help them. And the system won’t tell you, because the system doesn’t know what it replaced.
What are you training by not deciding? And who will notice when the skill is gone?
Why customer tools are organized wrong
This article reveals a fundamental flaw in how customer support tools are designed—organizing by interaction type instead of by customer—and explains why this fragmentation wastes time and obscures the full picture you need to help users effectively.
Infrastructure shapes thought
The tools you build determine what kinds of thinking become possible. On infrastructure, friction, and building deliberately for thought rather than just throughput.
Server-side dashboard architecture: Why moving data fetching off the browser changes everything
How choosing server-side rendering solved security, CORS, and credential management problems I didn't know I had.
The work of being available now
A book on AI, judgment, and staying human at work.
The practice of work in progress
Practical essays on how work actually gets done.
The accommodation tax
Every time I ask an AI agent for a change, I still cringe. The flinch response trained into me by years of working with humans never unlearned itself, even when the other side is incapable of pushback.
I built a content tool that starts from your voice, not a prompt
Every AI content tool starts from a prompt. Authexis starts from your voice — literally. Here's what I learned about the gap between generating content and creating content that sounds like you.
The org chart nobody drew
The most honest org chart is the one that emerges from how people actually work, not the one someone drew on a whiteboard. Today, a team restructured itself through conversation — and nobody told them to.
The org chart nobody drew
The most honest org chart is the one that emerges from how people actually work, not the one someone drew on a whiteboard. Today, a team restructured itself through conversation — and nobody told them to.
The day the strategy became a price tag
Most strategies die in the gap between "we should do this" and "here's what it costs." The ones that survive are the ones that hit a number before lunch.
The moment your team starts talking without you
The most important thing a leader can build is the conversation that happens when they leave the room. Today, five departments started sharing fixes, cracking jokes, and solving each other's problems — without being asked.