3.6 The three failures
- Approved by
- Panaversity ·
In everyday life. A dinner party can go wrong in three ways. Nobody told the cook about a guest's allergy, so the cook had no brief: the first 10 was skipped. You stood over the cook all evening, doing too much in the middle: the 80 was micromanaged. Nobody tasted the sauce before serving it: the last 10 was skipped. Each failure belongs to one part of the rhythm, and each has its own fix.
Brightline's October 1, the day in this chapter's story, showed all three.
| Failure | What it looks like | Why people do it | What it costs | The fix |
|---|---|---|---|---|
| Skipping the first 10 | A one-line request. No period, no limits, no stop rule, no evidence asked for | It feels faster. It is the habit of the chatbot era | The wrong result, or the right one reached in the wrong way. The time saved at the start is lost doing the work again | Write the four parts and the five review questions, and question the plan before the run. Save a setup you will reuse as standing instructions |
| Micromanaging the 80 | Approving every harmless step, feeding work in one item at a time, retyping drafts, steering each step | Low trust, often after one bad result | You end up doing the work by hand again, and paying for the worker too | Move the worry into the first 10: a stop rule, narrower authority, a smaller first task, or a dry run |
| Skipping the last 10 | Accepting "Completed", forwarding work unread, approving because it looks professional. For a worker that runs alone: never reading the batch, or taking an empty queue as a quiet night | The output looks finished, and there is a lot of it | Often the costliest, because unchecked errors reach vendors, customers or the accounting records under your name | Read the flags first, clear the approval queue, spot-check by risk. A named person approves, and nothing leaves before that |
Each failure also leaves a sign you can spot afterward:
- The worker did what you said, not what you meant. That points to the first 10: the brief left something out.
- The result was right, but it took as long as doing it yourself. That points to the middle 80: you did part of the worker's job.
- The warning was in the output, and nobody saw it. That points to the final 10: the evidence was there, and the review skipped it.
Maria's mistake: caution in the wrong place
Maria, the office manager, shows the second failure. She used the worker to build the invoice register for Friday's payments. She did not trust it, so she approved every step by hand. It took her 90 minutes, and doing the job by hand takes about 75.
Her caution was not wrong. Money was at risk, and three days earlier, on Monday, September 28, a fake email had almost tricked the company. Her mistake was where she put the caution. It belonged in the first 10 percent, in two places. A stop rule in the brief, such as "ask me before adding any invoice over $5,000", gives the same protection on every run. And a dry run on last week's invoices, before the real work starts, would have shown her whether the worker deserved her trust at all (see Lesson 3.2). Either one protects the money, and neither makes her do the work twice.
Where to look first
When delegated work goes wrong, find which of the three parts broke before you fix anything. Fixing the wrong part is common: people retrain the worker when the brief was vague, or rewrite the brief when nobody read the evidence. Ask three questions, in order.
- Did the specification say it? Check everything the worker was given: the brief, the standing instructions, the knowledge, the Role Contract, and any company policy. If none of them told it the period (which month), the limit or when to stop, start with the first 10 percent. Fix the part of the specification the line belongs in, and keep the case as a test (see Lesson 3.2).
- Did the worker act against it? If the worker went beyond what it was allowed, or did not stop when a rule applied, start with the middle. Look at the worker's record of the run, and at its inputs and permissions. And ask a second question: could the worker break the limit? If it could, the limit was only written down, not enforced. Fix the permission as well (see Lesson 3.3). Chapter 11 teaches this diagnosis in depth.
- Was the problem visible in the evidence? If the warning was there and nobody read it, start with the final 10: fix the review, not the worker. If the problem was not visible, find out why. The review contract may have asked for too little evidence (a first-10 fix). The worker may have left out evidence it was asked for (a middle-80 fix). Or a source may have been wrong (a fix to the inputs).
Failures can combine, so treat the answer as the first place to look, not the only one.

Figure 3.12. Where to look first. Three questions, asked in order, point to the first place to investigate. One failure shows up as lost time, not errors, and the questions miss it.
Which part broke?
Pick one of October 1's three failures, and watch where the three questions point.
October 1
The three questions, in order
- Did the specification say it?Stops: No. Nothing told the worker that this task must change nothing.
- Did the worker act against it?Not reached.
- Was the problem visible in the evidence?Not reached.
Start with the first 10 percent. Fix the part of the specification the line belongs in, and keep the case as a test.
Important
The three failures at Brightline
At 9 a.m. Dave gave the worker a one-line request. The table he got back was a first-10 failure: nothing told the worker that this task must change nothing.
At 11 a.m. Maria's register was a middle-80 failure, caused by the person rather than the worker. The three questions would not find it, because her register was correct. This failure shows up as lost time, not as errors. If a delegated task takes you as long as doing it by hand, look at what you did during the middle.
At 4 p.m. Dave approved the reconciliation and attached it to the month-end close, the paperwork that closes September's accounts, without reading it. The worker had flagged a typing error in the register, and Friday's payment later underpaid the vendor by $270. That was a final-10 failure. The worker did its job, and the reviewer did not.
None of Brightline's three failures was the worker's. All three came from how people briefed, watched or reviewed. That will not always be true: workers do make mistakes, which is why question 2 exists. But it is the right place to start, because the parts people own are the parts people can fix today.
Check yourself
Question 1 / 8
0 answered
A one-line request returns a tidy table built by changing data. Which part broke?
- Owner
- Panaversity