Issue #12 - Redline the Brief Before You Delegate
The interface I write before I delegate is the interface. If it ships wrong, the executor ships wrong. Presence Optionality (Issue #9) said your interface has to hold in your absence. Prove-Then-Replicate (Issue #11) said don't parallel-fire until the first instance is clean. This week's issue is the pass in between. The redline. The place where you look at your own brief cold and try to break it before the executor does.
Field Note
I wrote a brief a few months back to add a new stage to a scan I run. I read it once. It looked fine. Well-scoped, clear success criteria, executor could have started that afternoon.
Then I put it down and came back to it an hour later. Read it like I hadn't written it.
Four bugs. One was an API assumption that would have failed at the first call. One was a scope that referenced a column that didn't exist. One was a dependency between two stages that the brief said were independent. One was a "just do X" that quietly required a design decision I hadn't made.
None of them looked like bugs when I wrote the brief. They looked like small unspecified pieces. The kind of thing an executor would resolve on the fly.
That's the problem. An unspecified piece in a brief is a decision the executor is going to make without you. If it's a decision you would have made differently, you don't find out until the work comes back and doesn't fit what you meant.
Fifteen minutes of cold reading caught all four. If I had skipped that pass, the executor would have surfaced them one at a time over the next two days, and each surface would have interrupted whatever else I was doing.
The redline isn't a formality. It's the single highest leverage moment in the whole delegation.
The Deep Dive
A brief is done when you write the last sentence. That's the trap.
The moment you finish writing a brief, you know what you meant. Every ambiguous phrase reads as clear because your head is still holding the thing the phrase was pointing at. Every skipped constraint feels covered because you know the constraint even if you didn't write it down. Every assumption about the executor's context feels safe because you're the one who has the context.
That state is the worst possible state to ship the brief in.
The executor doesn't have your head. They have your document. If the document says "just do X," they will decide what X means. If the document says a stage is independent, they will build it as independent even if you meant it depends on the previous one. If the document leaves a decision unstated, they will make the decision. This is the whole point of delegation. You are trading your presence for their execution. The brief is the only thing that survives the trade.
The redline is the pass where you stop being the writer and start being the reader. Not a proofread. A cold read, from the position of somebody who has never seen this before and is about to spend a day of their own time acting on it. Every sentence gets asked the same question. If I had to act on this and only this, what would I have to guess?
Everything you have to guess is a defect. Not always a serious one. But every guess is a place where the executor's answer might differ from yours, and you won't know it until the work lands. The redline is where you convert those guesses into stated decisions before they become surprises.
Most people skip the redline because it feels like slowing down. You wrote the brief. You know what you meant. Reading it again feels redundant. It isn't. The redline is the cheapest place in the whole delegation to catch a wrong assumption. Once the executor starts, every catch costs at least an hour. Once the work comes back, every catch costs a rebuild.
The math on this is not close. Fifteen minutes of that pass buys back hours of executor time and rebuild time on any brief with real scope. Skipping it feels like efficiency. It's the opposite.
Case Slice Teardown
Role: Solo operator running a small stack of production services, cleaning up an old sandbox environment
Situation: Wanted to remove a set of unused test services to reduce clutter and cost. Wrote a brief for the executor: here's the list, delete them. Three-line brief. Looked done.
Constraint: Some of the "unused" services shared a database with services that were still live. The brief didn't name any of them by dependency. It only named them by intent (test, sandbox, old).
Intervention: The brief was not redlined. It was sent as written. The executor deleted the services on the list. One of them owned the database that another service, still in use, depended on. The database went with it.
Outcome: Recovery took two hours. The database was rebuilt from a git seed. No user data was lost because the service was pre-launch and had no real users on it yet. Cost was time and about six months of accumulated schema history, restored from the seed to a working state but not to the working state that had existed the previous day.
What's notable here: The redline that would have caught this is a single line. Which of these services shares state with anything still running? Fifteen seconds of question. The reason it wasn't asked is that the brief looked simple. Delete these things, done. Nothing to redline. That's the failure mode. The briefs that look like they don't need a redline are the ones where the redline is the only thing that catches the load-bearing assumption. If there had been real users on that database, the same brief would have destroyed live customer data. The brief did not know the difference between a safe delete and a destructive one. Neither did the executor. Only the redline would.
The Redline Test
1. The cold read.
Put the brief down for at least a few minutes. Then read it like the executor. Not like the writer. If any sentence makes you say "well, obviously they'll figure out what I meant," rewrite it until it doesn't need them to figure anything out.
2. Name every guess.
Read each sentence and ask: could someone in good faith read this two different ways? If yes, that's a guess the executor is going to make for you. Pick the answer and put it in the brief.
3. Check the shared state.
Anywhere the brief tells the executor to add, remove, or change something, ask what else touches it. This is the pass that catches destructive cleanup, breaking changes, and downstream failures that the brief looked safe from.
4. Partition the decisions again.
Look at what you're asking the executor to decide versus what you're reserving. If the brief doesn't say, it defaults to the executor's call. Anywhere you'd want to be the one making the call, name it. Anywhere you're fine with the executor deciding, name that too, so they don't come back to ask.
5. Read the success criteria last.
Ask if the criteria you wrote would actually distinguish "done right" from "done wrong." A lot of criteria describe what the output looks like. Real criteria describe what tells you the work solves the thing the brief was written to solve. If a wrong version could still pass your criteria, the criteria aren't tight enough yet.
If any of the five passes surfaces something, patch the brief and rerun that pass. Don't send until nothing new surfaces.
Redline your next brief before you send it
Write the brief the way you normally would.
Whatever your version of a delegation document looks like. A message, a doc, an email. Write it once, all the way through, without stopping to redline.
Then get up.
Walk away for a few minutes. Feed something. Refill water. Anything that breaks the writer-state.
Come back and read it again.
Not to polish. To catch. Where do you have to remember what you meant? Where did you use a word that could go two ways? Where is a decision buried inside a "just do" or a "handle"?
Patch what you catch. Send.
Not because the brief is perfect. Because now the guesses are decisions, and the decisions are yours instead of the executor's.
Do this once. Watch what you catch. The number will surprise you the first few times. Every catch is an interruption the executor won't have to send back at you.
What's a brief you sent recently where the work came back not quite fitting what you meant?
Reply with the delegation type and which of the five passes would have caught it. The best examples (anonymized) show up in future issues.
Redline is one pass in a bigger delegation discipline. Presence Optionality is the interface. Prove-Then-Replicate is the sequencing. Redline is the pass that catches the defects before either of those get tested. Together they're the difference between delegation that scales and delegation that generates cleanup.
Explore Strategic Thinking AcademyOr learn frameworks on your own for free on YouTube.
Strategic Thinking Weekly - New frameworks as they land
Unsubscribe anytime - Tampa, FL