Where we start
You cannot pass a verdict on something you have not yet placed, which is why the sort came first. But the placement does not imply the verdict, and most roadmaps you will be handed have quietly collapsed the two: they treat "this is a prediction case" as if it already meant "so we will build a model that acts on its own". It does not mean that. It means you now know which of four questions to argue about.
★ What you walk out with tonight. Your top three candidates broken into their actual tasks, one of four verdicts written against each task with a reason, a count of how many augment verdicts you passed, and the one task you are going to deliberately keep a person doing even though a machine could do it.
Two axes, and the error of treating them as one
7 min liveThe category says what KIND of thing a candidate is. The verdict says what to DO about it. They are independent, every pairing is legal, and you have to pass both judgements separately or you will silently inherit one from the other.
LiveThe four verdicts, and what each one is actually claiming4 min▶
Automate it. The claim is narrow and testable: the work is repeatable, and the cost of being wrong is low. Both halves have to hold. Repeatable with a high cost of being wrong is not an automation case, it is a case for a machine that prepares the answer and a person who signs it. The cost test is the one people skip, because repeatability is visible in a process map and the cost of an error usually is not.
Augment the person. The judgement stays human, the gathering does not. This verdict is where most of the value in most organisations sits, and it is the hardest to get approved, because it does not produce a headcount number. What it produces is a person who arrives at the decision already holding the five things they used to spend two hours assembling.
Build something new. The honest verdict when nothing in the business does this yet and nothing can, usually because the data required does not exist. Calling this out as its own verdict matters, because otherwise it hides inside an automation case and the estimate is wrong by a factor nobody can name. Session 4 is entirely about telling this verdict apart from the other three.
Keep it human. A deliberate decision not to hand something over, taken on the merits rather than by default. Two things justify it: the stakes, where an error does damage a correction cannot undo, and the trust, where the fact of a machine having decided changes how the person on the other end behaves. This is a verdict, not an absence of one, and it should be written down with a reason like the other three.
Self-studyHow the two axes get collapsed, in three moves nobody notices4 min▶
Move one: the category is read as a level of ambition. Somebody sees "do it" at the top of the ladder and hears "the most advanced answer", so anything placed there inherits the automate verdict automatically. But "do it" is a description of where the person is standing, not an instruction. Plenty of genuine do-it cases should be built and then deliberately left with a human confirmation step for years.
Move two: the verdict is read off the technology. A candidate arrives named after a tool, the tool is an automation tool, so the verdict is automate. This is the same failure session 1 parked in the "no question yet" pile, arriving one step later: the technology has decided both axes before anybody asked what question it answers.
Move three: augment gets treated as the leftovers. The list gets sorted into what can be automated and what cannot, and the second pile is renamed "augmentation". That is not a verdict, it is a residue. Part 2 is about why this particular collapse is so reliable, and it is not because augment cases are worse.
The test for whether you have collapsed the axes is simple. Look at your list and ask whether any category appears with more than one verdict against it. If every predict-it case got the same verdict, you passed one judgement and wrote it down twice.
Why augment is not the consolation prize
5 min liveIf your portfolio of verdicts comes out almost entirely automate, the most likely explanation is not that your work happens to be unusually automatable. There is a published argument that the incentives around everyone in the room push that way regardless.
The quotable claim. Erik Brynjolfsson, in "The Turing Trap: The Promise and Peril of Human-Like Artificial Intelligence", written for Daedalus in 2022: "While both types of AI can be enormously beneficial, there are currently excess incentives for automation rather than augmentation among technologists, business executives, and policy-makers." Note the three groups named. This is not an argument that engineers are careless. It is an argument that three separate sets of incentives happen to point the same way.
LiveThe clay-pot thought experiment, and what it is for3 min▶
The essay asks you to imagine engineers who succeeded completely at automation in an ancient economy: they fully automated herding, pottery, weaving, cart repair and bloodletting. Labour productivity soars. Every one of those five is now done faster, cheaper and with fewer people.
And then the argument lands: "there is only so much value one can get from clay pots and horse-drawn carts, even with unlimited quantities and zero prices." The automation worked. The economy is still poor, because the set of things worth having did not grow.
It is a thought experiment, not a finding, and it is worth being precise about that when you use it. What it does is make a structural point that no failure rate can make: a portfolio consisting only of automate verdicts has a ceiling built into it, and the ceiling is set by the value of the tasks that already exist. You reach it by succeeding, not by failing, which is why nothing in your delivery metrics will warn you.
The practical translation for a roadmap: augment is a first-class verdict, not a consolation prize for the cases that were too hard to automate. And if your portfolio has no augment verdicts in it at all, that is a signal about your incentives rather than about your work.
Self-studyWhich three sets of incentives, and how each one shows up in a planning meeting4 min▶
The claim names technologists, business executives and policy-makers. It is worth sitting with each, because each produces a different sentence you will hear out loud.
Technologists. Automation is a cleaner engineering problem. It has a fixed target, a measurable accuracy, and a finish line. An augment case has a human in the middle of it, which means the success criterion involves somebody's working day and cannot be reduced to a single score. The sentence you hear is "we would need to know what good looks like", which is true, and is not a reason to prefer the other verdict.
Business executives. A headcount saving is a number that survives contact with a budget process. "The team now arrives at the decision holding the evidence" is not, even when it is worth more. The sentence you hear is "what is the business case", asked in a way that only accepts one kind of answer.
Policy-makers. Outside the scope of a roadmap, but it changes the tools you are handed: the surrounding rules and tax treatment of capital versus labour are not neutral between the two verdicts. You inherit that as defaults in the software you buy.
Two honest caveats. This is one economist's argument, published as an essay rather than an experiment, and reasonable people dispute it. And there is no published rate for how often real portfolios over-automate, so nobody here is telling you a percentage. What the argument gives you is a reason to check your own distribution of verdicts and to treat an all-automate portfolio as a question rather than a result.
The verdict belongs to a task, never to a job
4 min live"Should we automate the account manager role" is an unanswerable question. "Which of the eleven things an account manager does are repeatable with a low cost of being wrong" is answerable in an afternoon. The difference is the unit, and there is primary research that pins it down.
The study, and a number worth correcting. Brynjolfsson, Mitchell and Rock built a rubric for suitability for machine learning and applied it at scale: 23 statements, each rated 1 to 5, applied to 964 occupations, 18,156 tasks and 2,069 direct work activities drawn from O*NET. Published in AEA Papers and Proceedings in 2018. You may have seen the rubric described elsewhere as having 21 criteria. That figure is wrong. It is 23.
LiveThe finding, in the authors' own words3 min▶
The central result is three clauses, and all three matter:
"(i) most occupations in most industries have at least some tasks that are SML; (ii) few if any occupations have all tasks that are SML; and (iii) unleashing ML potential will require significant redesign of the task content of jobs."
SML there is their shorthand for suitable for machine learning. Read the three clauses as a set and they say something a single headline cannot. Clause one kills "our work is not the kind of thing machines do" - almost every job has some tasks that qualify. Clause two kills the opposite error - almost no job is entirely made of them. The striking version of clause two: out of 950 occupations, zero had every task suitable. Not a small number. Zero.
Clause three is the one that ends up on your roadmap. If the suitable tasks are scattered through jobs rather than concentrated in whole jobs, then acting on them means redesigning what a job consists of. That is an organisational change with a technical component, which is a very different project from the one people think they are approving.
Here is what the decomposition looks like in practice. One role, five of the things it actually contains, a different verdict on each, and a reason you could defend in a meeting.
| One task an account manager actually does | Verdict | The reason, in one line |
|---|---|---|
| Pulling each account's usage and billing numbers into one place before a review | Automate it | Fully repeatable, and a wrong number gets caught in the same meeting it appears in |
| Working out which accounts are genuinely at risk this quarter | Augment the person | The gathering is repeatable, the judgement is not. They should arrive holding the evidence, not the answer |
| Telling a long-standing customer their renewal price is going up | Keep it human | The trust cost of a machine delivering this outweighs any efficiency, and the damage is not correctable |
| Answering "which of my accounts look like the one that left last month" | Build something new | Nothing in the business can answer this today, because nobody records why an account left |
| Logging the call outcome and next step after every conversation | Automate it | Repeatable, low stakes, and currently the most-skipped task on the list precisely because a person does it |
Self-studyWhy the job-level question is not just imprecise but unanswerable3 min▶
It has no truth value. If a role contains eleven tasks and four of them are repeatable with low error cost, there is no fact of the matter about whether "the role" is automatable. Any answer you give is a weighting you chose without saying so. The question feels answerable because it is grammatical, which is not the same thing.
It routes the conversation to the wrong room. A job-level question is a headcount question, so it gets answered by people who are thinking about headcount, using arguments about headcount. A task-level question is a workflow question and gets answered by the people who do the work, who know which four tasks they would happily never do again.
It hides the redesign. This is clause three of the finding. If you automate four of eleven tasks, the role still exists and is now a different role. Somebody has to decide what the remaining seven tasks add up to, whether they still fit one person, and what got quietly added because the four disappeared. Nobody plans for that when the unit of analysis was the whole job, because at that resolution the redesign is invisible.
The department version is worse. "Can we apply AI to customer service" contains dozens of jobs and hundreds of tasks, and the only honest answer is another question. When you are handed one of these, the useful reply is not yes or no. It is: name three things somebody in that department does on a Tuesday, and we will pass a verdict on each of the three by Friday.
A verdict on every task, with a reason
★ 22 min · use your sorted listFive passes over your own list. You should end with tasks rather than candidates, one of four verdicts against each, a count you can be uncomfortable about, and one deliberate refusal.
Take the three highest-rung candidates from your sorted list, the ones you wrote up for homework. Three is the right number: enough to see a pattern in your verdicts, few enough to finish in twenty minutes. Leave the "no question yet" pile alone, it is not ready for a verdict.
Break each candidate into the actual tasks it touches, written as things a named person does on a named day. Not "improve retention" but "reads the cancellation list on Monday and decides who to ring". Expect each candidate to produce four to eight tasks, and expect one or two of them to surprise you.
Pass exactly one of the four verdicts on each task, with a written reason. For automate, the reason has to cover both halves: it is repeatable AND a wrong answer is cheap. If you cannot write the second half, the verdict is augment. A row with a verdict and no reason is not a decision, it is a preference.
Count your augment verdicts and look at the number honestly. If it is zero or one out of thirty tasks, the published argument from part 2 is now about you, and the productive question is which verdicts you passed on the strength of how easy they were to justify rather than how right they were. Go back and re-read the three cheapest automate rows.
Find the one task where a machine could clearly do it and you are going to keep a person doing it anyway. Write the stakes or the trust reason next to it. If you genuinely cannot find one across thirty tasks, that is worth ten minutes of argument with somebody who talks to your customers, because it means either your work is unusually low-stakes or you have not asked them.
If two people pass different verdicts on the same task. Good. It is almost always a disagreement about the cost of being wrong, and that cost is a fact about your business that somebody can go and find out. Write both verdicts down with both reasons and go and look. This is the most productive argument available in the whole exercise, and it is a much better use of the room than agreeing quickly.
Before session 3
30 min- Show your verdict sheet to one person who does the work and ask them to change any row they disagree with. Do not defend the rows. The ones they change are the ones you guessed at, and finding that out costs you nothing now and a great deal later.
- Price one automation error. Take your cheapest automate verdict and find out what a wrong answer actually costs: a refund, a complaint, an hour of somebody's week, a lost member. One real number beats the whole rubric, and it usually moves at least one verdict.
- For every build-something-new verdict, write the one piece of data that does not exist. One line each. Session 3 puts both gates on the whole portfolio at once, and this is the line it will ask you for first.
- Bring the sheet. Tasks, verdicts, reasons. Sessions 3 through 5 each operate on it, and session 6 turns what survives into the one-page artefact a vertical roadmap can import.
Three questions
Clear all three and session 2 gets stamped in your passport.
1 · A candidate is placed at "predict it" in session 1. What does that tell you about its verdict?
The two axes are independent and all twenty pairings are legal. A and C are the two halves of the same mistake, reading the verdict off the category; D is the maturity-model reading of the ladder that session 1 warned about. The tell that you have collapsed the axes is that every case in one category got the same verdict.
2 · Your verdict sheet comes back with twenty-eight automate verdicts, no augment verdicts and two keep-it-human. What is the most useful reading?
The argument names three separate groups whose incentives happen to point the same way, which is why the pattern is reliable and does not require anybody to be careless. Note what is not being claimed: there is no published rate for how often real portfolios over-automate, so nobody can tell you your twenty-eight is too many. What you can do is check each automate row for the second half of its reason, the cost of being wrong.
3 · An executive asks you whether the account manager role can be automated. What is the right response?
C misreads the first clause of the finding, which says the opposite: most occupations in most industries have at least some suitable tasks. B is the tempting answer and it manufactures a number out of a weighting nobody agreed. The third clause is the one that changes the project: because the suitable tasks are scattered through jobs rather than concentrated in whole ones, acting on them means redesigning what a job consists of.
What this session teaches, and where it came from
Every fact on this page, and its verification tier, is recorded in the course's source map.
Session 2 cheat sheet · pin this
You now have a sheet of tasks, verdicts and reasons, and it is longer than your roadmap will be. Session 3 is the bench night: the whole portfolio goes through two gates at once, and it has to clear both. The first gate asks whether the business actually holds the data a case needs, which turns out to disqualify things nobody expected. The second asks whether the case moves the money the business makes, which is a different question from whether it is possible or whether anybody wants it. Bring the sheet, because we run your list through the same two gates as the worked example, and the most interesting rows are usually the ones that pass one gate and fail the other.