REALITYWIPE

OLD SCRIPT DETECTED

If I don't touch it, it will break

Try this response:

If it breaks without me watching, I didn't build it right. That's a design problem to fix, not a reason to never leave.

Take the 60-second self-check

SEE THE PRACTICE

Build a response for this thought—and one move to prove it.

THE THOUGHT

If I don't touch it, it will break

YOUR RECORDED RESPONSE

If it breaks without me watching, I didn't build it right. That's a design problem to fix, not a reason to never leave.

ONE PRIVATE MOVE

Write down, in plain language, exactly what you check when you review delegated work. Then spend ten minutes asking: which of these checks could live in a test, a document, or a runbook instead of in your hands?

The Monday code review that takes three hours

SCENE_01

You find yourself re-reading their work on Sunday night

Your developer shipped the feature Friday. It's live. Users haven't reported anything. But at 11 p.m., sitting with your laptop, you're stepping through the logic line by line, checking error handling, running through edge cases in your head. Each review takes longer than it would have to write it yourself. You already know this. You tell yourself you're being thorough. What you're really checking is whether the system survives without your direct supervision.

SCENE_02

The private meaning: absence = neglect = collapse

If you're not reading it, testing it, verifying it, then it's unwatched. Unwatched things fail. Your developer might miss something. The monitoring might miss something. Your absence from the process is the gap where breaks happen. So your hands stay on the controls. Nights and weekends become your unpaid insurance policy. You can't fully delegate the outcome because you don't trust the outcome without your fingerprints on it. The behavior feels necessary. It feels like the only thing standing between working systems and chaos.

SCENE_03

The pivot: what broken systems actually reveal

Systems don't fail because a founder stepped away for a week. They fail because the founder was the system. No monitoring. No runbook. No clear ownership. No escalation path. When you can't leave, the design is incomplete—not the people. The question isn't whether your team will drop it; it's whether you've built the drop into the design. That's the real work. Do it once, in writing, during work hours. Then the grip can loosen.

TRACE · 01/04

How this script runs you

  • You re-examine delegated work so thoroughly it becomes faster to redo than to trust—then use that as proof delegation doesn't work.
  • Days off sit in your calendar while your hand reaches for Slack; you call checking messages 'staying informed' instead of naming it staying in control.
  • Every handoff travels with an unspoken recovery plan for when they fail, because failure feels inevitable without you watching.

SOURCE_LOCATED · 02/04

The hidden rule underneath

The White-Knuckle Grip

If my hands leave the controls—the work, the decisions, the verification—the system breaks. My absence is the failure mode. The only way to guarantee it doesn't break is to never stop touching it. Stepping back isn't trust; it's recklessness.

FORGING_REPLACEMENT · 03/04

Replacement lines (record these)

  • If it breaks without me watching, I didn't build it right. That's a design problem to fix, not a reason to never leave.
  • My fried judgment during a sleepless week costs more than a system that works without me monitoring it.
  • I own the outcome. I don't own managing my anxiety about the outcome by staying in it.

Generated per person in the app — these are the flavor, not your script. Yours is built from your exact words.

INSTALL · 04/04

The protocol, on one card

When I think

If I don't touch it, it will break

I say

If it breaks without me watching, I didn't build it right. That's a design problem to fix, not a reason to never leave.

Then I do one thing

Write down, in plain language, exactly what you check when you review delegated work. Then spend ten minutes asking: which of these checks could live in a test, a document, or a runbook instead of in your hands?

STATUS: READY_TO_INSTALL

Wipe this thought

4 minutes. Your voice. Free.

Start this exact wipe in the app →

The wipe protocol
  1. Write the thought exactly as it plays: "If I don't touch it, it will break". Word for word — the wipe targets the sentence, not the vibe.
  2. Trace the rule and the avoided action. What does this thought conveniently excuse you from doing?
  3. Record the replacement lines below in your own voice. Speak like you mean it — no recording, no install.
  4. Run the loop: play it every morning and night, log one proof action a day for 7 days.

Straight answers

Doesn't stepping back mean I'm ignoring real problems?

No. It means building so the problems surface without you. Monitoring, logging, tests, and clear ownership are how real systems stay visible. Your presence isn't visibility. Instrumentation is.

What if my team isn't ready to handle the responsibility?

Then you've found the real design flaw. Instead of staying in the work, write down what readiness looks like, what checks they should run, and when to escalate. That's the handoff that actually works.

Isn't it faster to just do it myself than to explain all this?

Yes, once. No, perpetually. Every time you redo their work instead of debugging the handoff, you prove the system requires you. The system is broken, not them.

Related old scripts

Related self-checks

Related science

Researchers to explore

Related mechanisms

The research behind this script