Learning Center
A short course in outcome development: seeing the finished states you are responsible for, naming them properly, and handing the machinery away.
Most work is not the work. Consider a dentist. She trained to look at teeth. On a Tuesday she spends two hours chasing a lab about a crown, an hour reconciling a payment, forty minutes renewing a registration that lapses in March, and another hour moving appointments because somebody cancelled. None of that is dentistry, and all of it has to happen.
She is not badly organised. She is doing what the systems around her require a person to do. The spreadsheet has to be opened, the portal has to be logged into, the inbox has to be read. Those interfaces sit in the middle of the work instead of underneath it, so the day fills with the handling of work rather than the work.
What an outcome is
An outcome is a finished state in the world that somebody is responsible for reaching. The crown is fitted and paid for. The registration is renewed before March. The bridge is built. The album is released. The client renewed.
It is not a task and not a project. A task is a thing done once and ticked off. A project has a beginning and an end and a pile of tasks between them. An outcome is a condition that has to be true, and often a condition that has to be true again next year. The tax return is filed. Then it is filed again.
What is left for a person
Once the outcomes are named precisely, most of what stands between a person and those outcomes turns out to be machinery: checking dates, assembling documents, chasing, filing, keeping a record. Machinery can be carried by software. What is left is judgement, taste, relationship, and the decisions that genuinely belong to the person who holds the responsibility.
This is the claim of outcome development, and it is worth stating plainly because it cuts both ways. Handing machinery away is only useful if somebody stays to decide. Knowing which decisions must stay with a person is a skill, and it is taught here in its own course.
Who this is for
Anyone who is answerable for something recurring. A landlord with forty flats. A touring musician with three visas and eleven venue contracts. An accountant with two hundred year end files. A restaurant holding a licence, an inspection date and a rota. A photographer with a release form for every shoot. A student with a dissertation that will not write itself.
No technical background is needed. Nothing here requires a subscription, a product, or an account of any kind. It is a way of looking at a working life, and it can be practised on paper.
How to use this
Three courses, five lessons each, in order. The Foundations teach you to see and name an outcome. Operating an Outcome teaches you what keeping one actually involves. Directing an Outcome with Software teaches what to hand over and what never to. Each lesson is short, takes a different kind of work as its example, and ends with an exercise you can do in five minutes with a pen.
Read one lesson at a time. Do the exercise before moving on, because the exercises are the course. A person who reads all three courses and writes nothing down will close the last page with the same day they started with.
Terms are collected in the glossary if a word is unfamiliar.
The curriculum
Every lesson
Three courses, read in order. Each lesson is a few minutes of reading and one exercise.
The Foundations
What an outcome is, how it differs from the tasks and projects around it, how to find the ones you already carry, how a large outcome holds smaller ones inside it, and how to write an outcome down so that it can actually be worked.
- 1.1 What is an outcomeA finished state somebody is responsible for reaching, and why that is a useful thing to name.
- 1.2 Outcomes, tasks, projects and habitsFour words that get used as if they were the same word. Telling them apart changes the plan.
- 1.3 Finding yoursWorking backwards through a calendar, a diary and a set of past mistakes to the outcomes underneath.
- 1.4 The onionA large outcome contains smaller outcomes, and each layer is owned by somebody different.
- 1.5 Naming itThe wording of an outcome decides whether it can be worked, checked or argued with.
Operating an Outcome
A named outcome is not yet a kept outcome. This course covers what has to remain true, what comes round again, what is standing in the way, who answers for it, what finished means, and when to stop.
- 2.1 What has to stay trueReaching an outcome is one moment. Keeping it is the rest of the time.
- 2.2 What recursRenewal cycles, filings, reviews and intervals: the clockwork inside an outcome.
- 2.3 What it is blocked onA blocker named precisely is usually half solved. A blocker named vaguely never is.
- 2.4 Who is answerableA mandate, a delegate and the difference between helping and owning.
- 2.5 Knowing when it is doneA definition of done that another person could check, and knowing when to stop entirely.
Directing an Outcome with Software
What to hand over and what never to hand over, how to describe work well enough for a system to carry it, what deserves a check, where a person must sign, and the one failure that makes all of it worthless.
- 3.1 What to hand overMachinery travels well. Judgement does not. Sorting one from the other is the whole skill.
- 3.2 Describing the workTrigger, source, rule, output, exception. A description a stranger could follow.
- 3.3 What to checkSpot checks, thresholds and the checks worth setting up before anything goes wrong.
- 3.4 Where a person must signApproval is not a formality. Deciding where it belongs is a design decision.
- 3.5 The failure modeIt did it and nobody looked. Why silence is the most expensive result of all.
Glossary
Plain-language definitions of every term the lessons use: outcome, obligation, item, desk, register, renewal cycle, blocker, mandate, approval and the rest.
Begin at the beginning
The first lesson takes five minutes to read and one pen to act on.