Real work is six steps where the fourth depends on what the second turned up.
Almost nobody has been shown how to run that with a machine doing the steps, so people do the thing that feels responsible. They plan the whole job at the start and then follow the plan through material that has been telling them since step two that it was the wrong plan.
Everything in this book so far has been a single exchange. Ask, check, score, send. This chapter is about the longer jobs, which is most of what you're actually paid for.
Not because planning is bad. Because of when it happens.
At the moment you write a plan you've less information about the job than at any later point. Every step adds something. So the plan is authored at peak ignorance and then defended, by you, against everything you learn afterwards, because changing it feels like conceding the first version was wrong.
The alternative isn't to abandon planning; it is to move the planning between the steps instead of before them.
Do the first step. Read what came back, properly. Then ask: given what I now know, what is the most useful next step?
That question, asked between every step, is the whole method. Ten seconds each time, and it's the difference between six steps that compound and six steps chosen by somebody who had not started yet.
I keep arriving at this shape. I have built research systems three times, for different purposes, and ended up with the same architecture each time. Run one step, read the result, choose the next from what is now known. Treat that as my habit rather than as proof. The argument above stands without it.
I stop when I get bored.
So does everybody I have watched. Not when the question is answered. When the afternoon runs out, or the reading turns repetitive, or something louder arrives. And because it feels like a natural ending rather than a decision, almost nobody counts it as one, or notices they made it somewhere different last week on a similar job.
You have met this shape three times already, and it is worth naming now rather than letting it keep arriving in disguise. Chapter five decided the depth before asking. Chapter eight wrote the bar down before seeing the score. Chapter eleven noted the expectation before looking at the answer. Every one of them is the same move: commit while you are still able to, because after you have seen the thing you cannot.
This is the fourth and the most expensive, because it is the one measured in hours rather than minutes. Write the finish line down before the first step. Written down, not intended.
The rule most people reach for is three independent sources, and it has a hole in it. Three outlets carrying the same wire story is one source wearing three coats. Independent means a different origin, not a different website, and if you can't say where each one got it, you've one.
The same hole sinks the other obvious rule, the number stops moving, because a number stops moving precisely when nothing new is being checked.
So the condition has to be both halves at once: two consecutive passes turn up nothing I did not already have, and I can say where each source got it. Written at the top of the page, before the first step.
Then, when you feel the pull to stop, you have something to check the feeling against. Sometimes the honest answer is not yet. More often the condition was met a while ago and you were continuing out of anxiety, which is an hour you have just been handed back.
Before planning anything: have I already solved part of this?
Somewhere on your machine is an instruction you wrote three months ago that does a chunk of what you're about to start from scratch. A brief that worked. A structure built for a different client that transfers exactly. A checklist you made after something went wrong.
You won't remember it, because you filed it where you file things, and that place is a graveyard.
Two minutes at the start of anything. Look before you build. And the reason this fails isn't laziness — nothing was ever saved in a form that could be found again.
I have built sixteen applications that I use, not demos. I don't write code professionally and never have.
That isn't the point, and I'm not telling you to build sixteen of anything. The point is available to you this week without writing a line of anything.
Every one of those tools is a judgement I made once and then stopped making.
How to tell whether an article is good enough. What makes an event worth the flight. When research has gone far enough. Each was a decision I used to make freshly every time, slightly differently depending on how tired I was and what had happened that morning.
Now each is written down in a form that runs.
The speed is real and it isn't the interesting part. The consistency is. The standard I applied on a bad Thursday in February is the standard applied now, because I'm not the one applying it any more. I am the one who decided it.
That has almost nothing to do with software.
Not an application. An instruction, with your actual standards in it, in the words you would use to a competent colleague doing it for you.
Here is a complete one. It is dull on purpose, because the dull recurring judgements are where this pays.
You are a procurement manager with fifteen years in a mid-sized services business. You are looking at a supplier quote to decide one thing: is this worth an hour of my time in a meeting, or is it a no? > > Check these five, in this order. > > 1. Does the quote answer what we actually asked for, or a nearby question they preferred? Quote the line that shows it. > 2. Is the price broken down enough that I can see what is being assumed? A single number is a flag, not a price. > 3. What is excluded? List anything a reasonable buyer would expect to be included and is not. > 4. What are they committing to and what are they merely describing? Separate the two. > 5. What would have to be true for this to go wrong at month four? > > Then give me: a verdict of MEET, ASK FIRST, or NO. If ASK FIRST, the single question that would settle it, in under twenty words. If NO, the one line I can send them. > > Stop when you have all five. Do not go looking for a sixth thing. > > Do not summarise the quote back to me. Do not give me options without a verdict.
Note the second-to-last line. The stopping rule lives inside the instruction, not in your intentions, because that's the only place it survives a busy week.
That instruction is one step. Watch what happens when you actually use it, because this is the shape the whole chapter is about.
It comes back ASK FIRST, with one question: does the implementation fee cover the data migration or not?
Here is the moment. You don't go to step two of a plan, because you never wrote one. You ask: given what I now know, what is the most useful next step?
And the answer has changed. Before you ran it, the obvious next step was a reference check. Now it isn't, because the whole decision has collapsed onto one ambiguity, and a reference won't resolve it. The finding chose the next move. You send the question.
They come back and the fee doesn't cover migration. Ask again. Now the useful step isn't a meeting either; it's a rough number for what migration costs, because if that number is large the quote you were assessing was never the real price and the comparison you were about to run was wrong.
Three steps. None of them planned in advance. Each chosen from what the one before it turned up, and the second and third would both have been wrong if you had decided them at the start.
That is the method, and it costs one question asked out loud between each step.
The instruction takes roughly twenty minutes to write. Use it three times and you'll notice something missing, and you'll add it. That is the moment it stops being a note and becomes an asset, because it now holds something you learned rather than only what you already knew.
Give it a file of its own, named for the judgement in the words you would use to a colleague, in one place with the others. That is what a form that could be found again means, and it's the whole of what the two-minute look needs to work.
Do that a few times over a few months and you have several of them. They take twenty minutes to draft and a good while of use to become worth anything, which is exactly why almost nobody has them.
I am not going to hand you this without the part that gets people into trouble.
What your contract says about work product. In most places, depending on your contract, things you create in the course of employment belong to your employer. That is usually fine and occasionally matters, and you want to know which before you build something you think of as yours.
What your employer's policy says about putting internal standards, client material or process detail into an AI tool. Many organisations now have one. Some have one nobody has read.
Do this in the open. Tell your manager you're building it. It is worth more to you visible anyway — a private asset makes you faster, and a visible one makes you the person who improved how the team works, and only one of those gets discussed in a pay conversation.
The obvious objection is the right one.
If you write the judgement down, is it still yours?
You saw this in chapter two. The moment a rule leaves somebody's head and gets documented, it becomes rule work, and rule work is the work that moves away from people.
The distinction is precise. What you write down is the standard. What you keep is deciding it.
Anybody can run your checklist. Almost nobody can build it, and the person best placed to notice it has stopped being right is the one who set it. The judgement in the file is the judgement you made in March. The valuable thing is being the person who notices in September that March was wrong.
Which is why the title of this chapter isn't do it once and never again. The asset has to be maintained or it quietly becomes a liability, and a checklist nobody has questioned in two years is somebody's outdated opinion being applied with great consistency.
That is how good judgement actually decays, and it's the honest cost of everything here.
Take the supplier-quote instruction from a few pages back and run it forward eighteen months, because this is the part nobody warns you about and it is the reason most of these things quietly stop being worth having.
It works. That is the problem.
It works so well that after the first three months you stop reading its reasoning and start reading only the verdict. MEET, ASK FIRST, NO. By month six you are forwarding the ASK FIRST question to the supplier without opening the rest. By month twelve somebody else on the team is using it, because you gave it away, and they never saw the reasoning at all · they inherited a verdict machine.
Now look at check number two. Is the price broken down enough that I can see what is being assumed? A single number is a flag, not a price.
That was right when you wrote it. Then your industry changed the way it quotes. A fixed all-in price became the normal, competitive, customer-friendly way to sell this thing, and the suppliers still itemising are the ones who intend to add to it later.
Your rule has inverted. It now flags the good quotes and waves through the bad ones, and it does this with total consistency, every time, in your name, and it has never once told you it was struggling. A person applying that rule would have said this feels wrong lately. A file does not have that feeling.
Then the second failure, which is worse and quieter. Check five asks what would have to be true for this to go wrong at month four? Nine months in, a supplier failed at month four in a way nobody had seen before · they were acquired, and the team that had written the quote left. You had a bad quarter because of it, you learned something real, and you did not put it in the file. You put it in your head, where it will stay until you leave.
So the file is now two things at once. It is a rule that has quietly gone backwards, and it is missing the single most expensive thing you learned in the period it covers.
Here is the maintenance, and it is smaller than the problem. Once a quarter, open the file and answer two questions.
Which of these checks has fired in a way I disagreed with? Any check you have overridden more than twice is not a check, it is a formality, and either the rule is wrong or you are wrong. Both are worth knowing and you cannot find out without looking.
What did I learn since last time that is not in here? Not everything. The one thing that cost you something.
Twenty minutes a quarter. That is the whole maintenance schedule, and it is the difference between an asset and a fossil.
And the thing that makes it work is a date. Put the date you last reviewed it at the top of the file, where you cannot miss it, because a rule with a date on it is a rule somebody can question. Anybody who opens it can see it is fourteen months old and treat it accordingly. A rule with no date on it reads as permanent, and nothing in this book is permanent.
That is also the honest answer to the objection I raised a moment ago. What you keep is not the standard · the standard is in the file and anybody can run it. What you keep is being the person who notices in September that March was wrong, and the quarterly twenty minutes is what that noticing actually looks like when it is a habit rather than a virtue.
Almost everybody writes the instruction and never writes the stop.
The instruction is the interesting part, so it gets the attention. The stopping rule feels like a detail you can add later, and later does not come. What you are left with is a tool that runs until whoever is watching decides there has been enough, which is the exact thing you built it to eliminate · your own boredom, wearing a more professional coat.
If you write only one line of it today, write the line that says when to stop.
One thing. The judgement you make most often.
Write it as an instruction, with your real standards, in about twenty minutes. Put its stopping rule inside the file before you use it once. Check the two things above first. Use it three times, asking between each one what the last result changed. Add what you notice is missing.
At the end you'll apply one standard the same way twice in a row, which you almost certainly didn't do last month.
That is a smaller claim than I would like to make and it's the one I can support.
And it puts you somewhere specific. Telling your manager you're building it isn't the same as having it checked, and you're now producing consequential work through a process nobody has tried to break.
So give it to one person whose job it's to disagree with you, and ask them to break it. That is the last cheap thing available to you before the expensive question arrives, which is what could go wrong. And almost nobody in your building has said it out loud.