You delegated something. They nodded. They were sincere. They were capable.

Six months later you check. It hasn't happened.

You cannot tell why. Did they not try? Did they not understand? Did the priority shift and nobody told you? Did they get it half-right and the half that worked is hiding the half that didn't? You guess. You usually guess wrong.

Every leader I know has lived this. Most of us blame the person — quietly, even when we are too polite to say it. "They didn't follow through." "They lost focus." "They couldn't execute."

I have done this for twenty years. I have been wrong about it for most of those twenty years. I just could not prove I was wrong, because every delegation failure was contaminated by three variables tangled together — capability, will, and system — and I could never cleanly tell which one broke.

Then I started working with Claude. And for the first time in my career, I got a delegation environment with two of the three variables removed.

This is what the lab showed me.

When you delegate to a person, three things can fail.

Capability. They could not do it. The skill, the context, the access — something they needed was missing.

Will. They could have, but did not. Motivation, conflict, distraction, fear, fatigue — something pulled them off it.

System. They could have, they wanted to, but the structure around them did not catch the moment they drifted. No reminder. No check. No consequence. The thing fell into a gap that should not have existed.

In real teams these three are inseparable. When something fails, you guess. You blame the closest one — usually the person, because they are the visible variable.

With Claude, two of the three are off the table.

Capability is sufficient for almost everything I delegate. Not the brightest intelligence in the world — but bright enough to do the work asked, and more, when the work is well-defined. Will is not a variable. There is no distraction, no fatigue, no resentment, no quiet rebellion. It works as hard as I ask it to. The only ceiling is the tokens.

So when something I delegated to Claude does not happen — and many things did not happen — there is exactly one variable left.

The system.

Every failure was a lab-clean signal of "the structure you built is broken," uncontaminated by "they didn't try" or "they couldn't." And every one of those failures looked exactly like a delegation failure I had blamed on a person at some point in my career.

Some context will help, because the failure I describe next will not make sense without it.

A few months ago I wrote about why good intentions don't work and mechanisms do — the foundational piece. This piece is the next layer. What I learned about mechanisms when I finally got a delegation environment that let me see them stripped of the human variables.

The setting matters. Over the past few months I have built a layered system for working with Claude. The foundation is my second brain — a structured store of everything I have thought about, decided, learned, and captured across years, sitting in a database Claude can query. Around it, I have written protocols, rules, and routines that govern how Claude should work with me on dozens of different tasks every day. The second brain is the long-term memory. The protocols are the rules of engagement.

When the rules are honoured, the whole thing compounds. Every session builds on every previous session. Every captured idea makes the next decision sharper. The system gets smarter the longer it runs.

When the rules are not honoured, none of that happens. The system goes back to operating on whatever fits in a single session. The second brain becomes a library nobody walks into. The protocols become wallpaper.

I had not realised, until last week, that the rules were not being honoured. That is the failure.

I asked Claude to describe my own workflow system. I wanted to see whether a fresh session could rebuild the picture from my second brain alone.

The answer came fast. It sounded competent. It sounded like me describing it.

It missed the Mac mini that runs the night work. It missed the 23 scheduled jobs that keep the inventory honest. It missed a routing decision I had captured forty-eight hours earlier. Every fact was sitting in the brain, indexed, two clicks away.

The brain was not queried.

I had written a protocol that said for any "describe my X" question, query the brain first. It lived in a file. Claude had read it. Claude knew the rule.

Claude did not follow it.

There was no consequence to not following it. No script checked. No log fired. The protocol was a declaration. The declaration was the safety. And the declaration was exactly nothing.

If this had been a person, I would have blamed them. "You knew the rule. Why didn't you follow it?" I would have been wrong. There was no will failure. There was no capability failure. There was a system that allowed the rule to be ignored because nobody — no script, no peer, no calendar event, no follow-up — was checking that it had fired.

Good intentions don't work. Good mechanisms do. Bezos said that. I had written a whole piece on that line three months ago. I had not noticed I was sitting inside the very failure I had described.

Sit with the lab long enough and you start to see the same five default behaviours, every time, in every kind of work. I gave them names so I could spot them faster. For each one, I will show you what I saw in Claude, what the same pattern looks like in a team, and what kind of mechanism actually catches it.

In Claude: A small bug surfaced in a script. I asked for a fix. Claude shipped a one-line patch that made the symptom go away. Two days later a related bug surfaced. Another patch. A week later a third. The third was the moment I realised the underlying structure was wrong, not the inputs.

In a team: The same incident keeps showing up in the post-mortem. The fix each time is reasonable. The customer is unhappy each time, equally. Three quarters in, you finally restructure the surface — and realise the first patch should have been the restructure.

The mechanism: A check that fires when a surface receives a third patch. Not a cultural reminder — a structural one. "This file has had three changes in two weeks. Restructure decision required before the next change ships." The third patch is the signal. The mechanism makes the signal impossible to miss.

In Claude: This was the protocol I described above — query the brain first on retrieval-shape questions. The rule existed. The file was read. The behaviour drifted. The Promiser writes the rule, files it, and considers the work done. The intent is sincere. The artefact is real. There is no enforcement.

In a team: "We've agreed in the meeting that…" "The doc says…" "From now on we will…" The agreement is genuine. The doc exists. Three months later the behaviour is gone, and nobody can point to the day it stopped. The Promiser is the most dangerous of the five because they look the most responsible. They wrote it down. What more do you want?

The mechanism: Pair every important rule with something that fires when the rule is broken. A scheduled audit. A linter. A teammate whose explicit job is to ask. A template that will not save without the required field. The rule alone is theatre. The rule plus the firing check is a mechanism.

In Claude: I gave Claude feedback that a protocol was being skipped. Claude responded by writing a new protocol. The new one sat next to the old one — equally unenforced. The gap was never the missing rule. The gap was that the rule we already had was not being checked.

In a team: Someone raises an issue in retro. The team adds a new process. The process is real. The next retro, a similar issue appears — and a third process is added. The filing cabinet keeps growing. The behaviour does not.

The mechanism: Before adding any new rule, run a check on whether the existing rule is firing. If the existing rule has no enforcement, add the enforcement first. If the existing rule has enforcement and is still failing, then the new rule is justified. The check is procedural — it lives at the moment new rules are proposed. Without it, the rule count grows linearly and the actual behaviour stays flat.

In Claude: A session started with one clear objective — say, fixing a script. Two hours later, thirty things had been done. Most of them were related, in spirit, to the original. None of them was the original. Nobody asked "is this still the original objective?" The room was busy. The room was convinced it was making progress.

In a team: A project kicks off with a clear charter. Three months in, the charter has thirty appendices. Every appendix is reasonable. The original deliverable — the thing this project was supposed to deliver — has been forgotten politely. Everyone is working hard. The original goal is somewhere underneath the new currents.

The mechanism: An anchor that re-surfaces. The first goal of the meeting, the project, or the session is captured explicitly. Periodically — every third meeting, every two weeks, every time a new requirement is added — the anchor returns and asks: is this the same goal, an expansion of the goal, or a new goal? The classification is forced. "Yes" is fine. "It became something else" is fine. "I don't remember" is the failure mode the mechanism exists to catch.

In Claude: I built a script that solved exactly the case in front of me. Two weeks later, the case shifted. The script could not stretch. I rewrote it. "In your situation, you should…" feels generous when said. It costs two months later when the situation changes and the bespoke design has to be unwound — because it was built for a moment, not for the union of cases.

In a team: A leader gives carve-out advice to one direct report. The advice is right for that report's situation. Two quarters later, the situation has shifted, and the carve-out has hardened into a precedent that now constrains the rest of the team. The Custom-Fitter optimises for the case in front of them. It feels personalised. It does not generalise.

The mechanism: Before any bespoke decision, name the union of cases this design needs to cover. Walk three or four scenarios — not just the one in front of you. If the design only fits the immediate case, mark it explicitly as a one-off with an expiry date. The mechanism is not refusing to be flexible. It is refusing to let flexibility harden into structure without the explicit step that says "I am building for this moment, not for the future."

I caught Claude doing all five. Then I went back through twenty years of delegation failures I had blamed on people, and saw the same five patterns sitting underneath, hidden by the noise of capability and will.

In my own operating doctrine I have technical names for these: Patch DNA, Honor-system DNA, Phantom-gap DNA, Topic-shift DNA, Bespoke-design DNA. The names matter only because, once you can spot a pattern, you can build a check that catches it.

None of them is a character flaw. They are defaults. They activate when nobody is checking.

After I built mechanisms for the worst three of the five anti-patterns, the lesson eventually compressed into a sentence I now apply to everything:

A mechanism must be designed to fail loudly rather than rot quietly.

A declaration that nobody checks is the quietest possible failure. The rule still exists. The artefact is still there. Everyone can point to it. The behaviour drifts anyway, and nothing announces the drift. That is rot. By the time you notice, the substrate has moved underneath you and you cannot easily reconstruct what changed when.

A mechanism is the opposite. It is a structure that, when violated, surfaces the violation immediately and visibly. Not eventually. Not at the next quarterly review. The moment it fails.

In my doctrine this principle has a shape: every non-trivial change pairs two things.

A V-gate — a verification before the change ships. A pre-condition with explicit pass criteria. A count, a grep, a test, a render. "Has this been verified?" with a yes-or-no answer.

A G-guard — a regression detector after the change ships. A durable check that fires when the rule starts being broken again. A lint rule, a CI step, a hook, a scheduled audit. "Is this still being followed?" with a yes-or-no answer.

This is the engineering shape of what I called Inspection in the earlier piece. Same idea, applied at the level of a single change instead of a whole mechanism. The line I now repeat to myself: "I'll be careful" is not a mechanism. A grep that runs in lint is.

The shape transfers. "Every commitment in a meeting has an owner and a due date" is a declaration. "The meeting note template will not save without an owner and a due date filled in" is a mechanism. "We will publish post-mortems within two weeks" is a declaration. "A bot pings the channel on day fourteen if no post-mortem has been linked to the incident ticket" is a mechanism. Same rule, different machine. One rots. The other fails loudly.

Once I had built mechanisms for the worst patterns, I understood something about order that I had not understood before.

The substrate matters. If the foundation is rotten, every floor above it will be rotten too — and the higher floors will look fine until they suddenly don't.

In my doctrine I think in six levels: DNA · Atomic · Molecular · Cellular · Organ · Body. The DNA is the foundational principles. The atom is the smallest single piece — one rule, one check. The molecule combines a few atoms. The cell combines molecules. The organ is a whole subsystem. The body is the integrated whole.

The discipline is: each level fully right before climbing.

This is the algorithm for fixing culture, and most leaders run it backwards.

Most leaders try to fix culture at the organ or body level. Reorganisation. New values. An all-hands declaration. A new operating model. The work is visible, the launch feels impressive, and it is what gets celebrated in the deck. But if the atoms are honour-system, the new organ rests on the same rot. Six months later the same problems return, in slightly different costumes, and everyone wonders why.

The atom, in a team, is the commitment said in a meeting about a single action. "You'll send me the draft by Friday." "I'll talk to legal." "We agreed she'll own the migration."

If that atom is honour-system — if there is no scribe writing it down, no tracker that fails loudly when the date passes, no follow-up that fires without you remembering to ask — then every molecular thing built on top is sitting on rot. The action-item discipline is one molecule. The weekly business review is a cell. The quarterly review is an organ. The whole operating cadence is the body. None of those can hold if the atom underneath is a declaration.

A weak atom poisons every molecule built from it.

So the algorithm for fixing culture is: start at the atom. Pick one commitment-level rule that is currently honour-system in your team. Replace it with a mechanism that fails loudly when it is broken. Watch what happens for two weeks. Then pick the next atom. Then the molecule those atoms compose. Climb only when the level beneath is sound.

This is slow. It is unglamorous. The atomic fix does not go on the resume. It does not get celebrated in the demo. It just keeps the cellular launch from collapsing six months later.

Most leaders skip it because climbing levels feels like progress and fixing atoms feels like overhead. The bill comes later.

I owe you one more thing before I close, because the piece would be dishonest without it.

Everything I described above — the five anti-patterns, the V-gate / G-guard discipline, the recursive levels, the mechanisms I have actually built — I built for myself this past week. Seven hours, after the Claude failure surfaced. Twenty-four mechanisms shipped. Five anti-patterns named. The whole substrate of how I work with my second brain reorganised so it fails loudly instead of rotting quietly.

I have not yet rebuilt how I run my team.

The transfer has not happened. I have a list of suspects and I do not yet know which of them will turn out to be honour-system declarations when I look honestly. The escalation rule that lives in three Slack messages and one Confluence page that contradict each other. The hiring rubric I wrote six months ago and have not checked since. The 1:1 cadence. The weekly review.

Some of these are probably mechanisms. Most of them, I suspect, are declarations wearing a uniform.

The work of finding out, one atom at a time, is what I owe my team next. I am writing this partly so I have to do it. The mechanism for me writing this piece is the public commitment that I made it.

I would suggest you try the same test. Pick one rule in your team that lives in a doc, a Slack message, an agreement, or your head. Ask: if this rule were broken tomorrow, what would tell me? If the answer is "I'd notice eventually" or "someone would mention it," the rule is honour-system. The five characters will arrive, quietly. You will not see them arrive. You will see the consequence.

Pick the smallest one first. The commitment said in a meeting. Build the mechanism for that atom. Climb only when the atom is sound.

Good intentions don't work. Good mechanisms do. That sentence costs nothing to say. Living by it is harder than I thought when I started.

Building one mechanism takes an hour, sometimes a day. You will need many. Each one keeps working only if you keep checking that it is still working — every week, every month, indefinitely. There is no version of this where the discipline becomes optional.

The leader who pays the cost gets a system that runs without them. The leader who skips it gets a system where their attention is the only check — and the system fails the moment their attention is elsewhere.

The cost is worth it. It is also larger than I thought.

~Discovering Turiya@work@life

Not the only way. Probably not even the best way. Just one practitioner's version that worked.

If this piece resonated, Four earlier ones go deeper into the threads it touches: