The Intentional Organisation - Issue #61 - The Task Fallacy

Work is not a list of tasks. We have known it since 1951, but we keep forgetting it every time a new technology arrives.

Oct 16, 2026

Work in a coal Mine. Photo by The New York Public Library on Unsplash

1. The Task Fallacy

In the last issue I promised that the next ones would start with the fallacy of treating work as a list of tasks. I would like to keep that promise properly, because almost everything I want to argue in the coming months depends on it. If the task is the wrong unit, then most of the forecasts, business cases and workforce plans now being written about AI’s impact on jobs are measuring, with great precision, the wrong thing.

I would like to start somewhere unexpected: underground, in Durham (UK), just after the war.

The coal face

For generations, British miners had extracted and worked coal in small groups. A handful of men took a stretch of face and did the whole cycle themselves: cutting, loading, propping the roof, moving on. They chose each other, covered for each other, and carried the craft between them. We all know what happened next: the industry mechanised. The longwall method stretched the work along a single long face and split the cycle into specialised jobs, each done by a different group on a different shift. Every task was now better engineered than before. No group any longer saw the whole.

What followed was not what the engineers had planned. Eric Trist and Ken Bamforth (Bamforth had himself been a miner) went to find out why, and in 1951 they published the study that founded what we now call the socio-technical school. The problem was not the machinery. The machinery had been fitted to the tasks, and in the process it had broken the system of relationships that used to make the tasks add up: who covered whose mistakes, who taught whom, who felt responsible for the face as a whole. Isolation, mutual blame and quiet withdrawal filled the space, producing what today we would call a “siloed” organisation.

The subtitle of their paper says it with almost bureaucratic calm: the psychological situation of a work group “in relation to the social structure and technological content of the work system“. Not the job. Not the task. The work system.

A decade later, Trist and his colleagues found mines where the same longwall technology had been organised differently, around composite groups that took on the whole cycle again and regulated themselves. They called the book that reported it Organizational Choice, and showed that the same technology could support more than one way of organising the work. The title is the argument. The technology did not decide how the work would be organised. People did, whether they noticed or not.

The frame comes back

Seventy-five years on, the task has returned as the unit of analysis, and this time it comes with very good credentials.

The modern version was built by economists. David Autor, Frank Levy and Richard Murnane modelled what computers do to jobs by breaking jobs into routine and non-routine tasks, and the approach turned out to be extraordinarily productive. Even they noted, in a footnote, that their focus on task shifts “within given jobs overlooks” changes in how production itself is organised. In the formal statement Daron Acemoglu and Autor later gave it, a task is “a unit of work activity that produces output”. Jobs are bundles of these units. Technology substitutes for some, complements others, and creates new ones.

The task itself is older than economics. Frederick Taylor built scientific management on it, and he was explicit about what task analysis was for: managers were to take on the burden of gathering “all of the traditional knowledge which in the past has been possessed by the workmen” and reduce it to rules, laws and formulae. The task was first of all an instrument for moving know-how from the people doing the work to the people planning it. Every process map I have seen in a system implementation carries that inheritance: it captures what can be written down, and it is silent about what cannot.

Last month Anthropic published an economic scenario explorer built on exactly this idea, and to its credit it says so on the first screen: the model “represents all the jobs people do in the economy as bundles of tasks”. It even walks you through an example. A nurse does rounds, draws blood, triages incoming patients, charts vitals, orders supplies for the ward. Some of those tasks AI will augment, some it will automate (charting and ordering), and some new ones will appear, such as checking how well an AI triages. The result, we are told, is that the nurse can spend more time talking with patients.

I want to be fair to this report, because it is not naive. The explorer calls itself “a stark simplification of a complex reality”, its authors list what it leaves out, and they publish their reviewers’ objections, including the one I find most interesting: some reviewers questioned whether the occupations exposed to AI will shrink at all. For forecasting an economy, a countable unit is a virtue, not a sin. You cannot model GDP to 2030 one hospital ward at a time.

The problem starts when the frame walks out of the macro model of an economy and into the organisation. Into the workforce plan that counts tasks per job. Into the business case that adds up hours saved per task. Into the redesign that asks which tasks can AI take? and stops there. At that point a modelling convenience has quietly become a theory of how work works.

And the nurse is a particularly unlucky choice of example. Because nine years after the coal study, the same institute studied nurses.

The nurse, the first time

At the end of the 1950s a London teaching hospital asked the Tavistock Institute for help. Too many student nurses were leaving. Isabel Menzies, who led the study, found that the nursing service had organised itself around a list of tasks. Care for a patient had been split into separate procedures, each performed by a nurse across many patients, so that the work could be scheduled, checked and handed over cleanly. Her explanation of why became famous: the task list was a collective defence against the anxiety of caring for ill and dying people, a way of keeping suffering at a distance. But the consequence is the part that matters here. The arrangement removed from the work what had drawn people to nursing in the first place, and the people it was supposed to protect left.

Read the explorer’s nurse next to Menzies’s nurse and the difficulty becomes visible. A list of tasks is not a neutral description of a job. It is already a design choice, and sometimes a damaging one. When we take the list as the given and ask only which items AI can absorb, we inherit every assumption the list was built on, including the ones that were hurting people. Menzies saw something I should concede, though: a task list is often a defence people want, because it makes difficult work bearable and checkable. The point is not that lists are wrong. It is that they are a design, with costs.

What a list of tasks cannot see

Let’s see what, specifically, the task frame misses, because “work is more than tasks” on its own is a slogan, and you could fairly reply that everything is more than its parts. There are three things the unit structurally cannot register, and I have met each of them in practice before finding it in the literature.

The weak link. Tasks sit in a chain, and the chain moves at the speed of its slowest step. The cleanest recent evidence comes, interestingly, from economists themselves. Mert Demirer, Leon Musolff and Liyuan Yang followed more than 500,000 software developers: autonomous coding agents raised their coding activity by 240%, but the number of projects by 80% and actual software releases by 30%, because human review and integration further down the chain did not speed up. The task got faster; the work did not, or not nearly as much. (Two of the authors disclose consulting work for Microsoft, which, if anything, makes the finding more striking.) The work also moved. When open-source maintainers were given Copilot, the share of their activity spent on coding rose and the share spent on project management fell by about a quarter (two of the five authors work at Microsoft and GitHub). The authors read this as relief for overloaded maintainers, and it may be. A task count records more code. It does not ask who now runs the project.
What the task was carrying. Some tasks exist for their output, and quietly produce something else as well. In Issue 58 I called this the missing junior loop: the routine work automated first is the work through which people used to become good. A recent workshop paper puts it bluntly: the tasks most amenable to AI delegation are “exactly those tasks through which junior workers develop their tacit judgement”. A task inventory records the output. It has no column for the formation.
The gap between the list and the work. Every list of tasks describes work as someone imagined or prescribed it. Human factors researchers distinguish this from work-as-done, and the French ergonomics tradition has argued for decades that the gap between prescribed and real work never closes, because working is the continuous bridging of it. The explorer’s task list comes from O*NET, which is a very good catalogue of work-as-prescribed. The workarounds, the judgement calls and the favours between colleagues that make the ward function are not in it, so no model built on it can see them disappear.

Aviation is the clearest case I know. A pilot’s work is about as thoroughly described as any work can be, checklist by checklist, and much of the flying has been automated for decades. Yet when NASA brought airlines and researchers together in 1979, the research identified most accidents as failures of communication, decision making and leadership between the people in the cockpit: in one 1978 crash, a captain who would not take input from his crew. What aviation built in response, crew resource management, trains the relations, not the tasks. The checklists stayed. What was added was design for the space between them.

None of these three is a mystery. Each is a property of the relations between tasks: the sequence, the hand-offs, who checks whom, who learns from whom, who covers for whom. That is precisely what Trist and Bamforth meant by a work system, and precisely what a bundle of tasks leaves out.

I have used the frame too

I should be honest about my own part in this. In Issue 50 I leaned on the task arithmetic myself: AI transforms some tasks in some jobs, and the macro effect depends on how many. And in Issue 52 I proposed the skill, “a bundle of related tasks”, as one of the practical units for redesign. I still think the skill is a useful handle for deciding what AI does and who answers for it. But I described it as a bundle, and a bundle is exactly the thing this issue is arguing against. The unit of redesign has to include the relations, or it is a larger list, not a different one.

This is also, I realise, the thread running through the last eleven issues, from the blind spot of instruments that measure jobs while work moves between them, to the adoption debt, where the gain is booked at the task and the cost lands in the system. I had been describing symptoms of the same fallacy without naming it.

So what is the unit?

If not the task, then what? Two definitions, to keep the distinction precise.

A task is what the economists say it is: a unit of activity that produces an output. It is a legitimate unit for counting and for forecasting at scale.
A work system is the set of tasks together with the relations that make them work: how they are sequenced and handed over, who checks and who decides, what each one teaches, and the informal work that bridges what was prescribed and what actually happens. It is the unit at which AI’s effect on work can be judged, and the unit that has to be designed.

Recent research is converging on the same move from a different direction: the workshop paper I quoted above argues explicitly for analysing whole workflows rather than “atomised tasks”. Stuart Winter-Tear has a nice line for it from the practitioner side:

The model is not the operating unit. The governed workflow is.

In practice the difference is less abstract than it sounds. A redesign that starts from the task asks what can AI do here? A redesign that starts from the work system asks three further questions before anyone signs the business case.

Where does this output go next, and who will check it at the new volume?
What did this task teach, and to whom, and where will that happen now?
And what do people actually do here that is not on any list, and who will notice when it stops?

Let me give you a personal example. I have designed Shared Service Centres several times in the past, both in HR and outside it, and I have also brought back in-house services that had once been offshored. Across all these cases one big lesson stood out. The very idea of a shared service centre rests on the Pareto principle, whereby you try to concentrate the effort. Process analysis is done at the task level, and what happens very often in the “lift and shift” is that what moves is not entire jobs, but portions of them. What is left behind is often relational work, tasks that are not part of any mapped process (but are still relevant), specific know-how and so on. In one of these projects, for example, all the HR administration tasks were migrated to an offshore centre in India. In Russia only one HRBP was left, out of an original HR team of four. It took only three months for the local unit to receive a fine for not respecting a number of local rules (including the manual stamping of the monthly attendance report by a local office). The inspection that followed found a number of other issues that in the past had always been managed “relationally” by one of the HR generalists. That incident wiped out the business case of the shared service centre for the entire Europe region for more than two years.

If I am wrong, it should show: an AI deployment designed task by task whose results at the level of the whole work matched what the task arithmetic predicted. I have not yet seen one, and I would like to.

The choice nobody notices making

Go back for a moment to the mines. The striking thing about Organizational Choice is not which arrangement was better. It is that the same machinery supported both arrangements, and most of the industry did not realise it was choosing between them. It adopted the technology, and the organisation came along as a side effect. And where the choice was made explicit, it did not stay made. Sweden, with a reputation as one of the most progressive countries in the world on work reform, built decades of programmes on these ideas; a recent history of them finds that the radical movement failed to generate radical change and the reformist one achieved only partial success, while interest in redesigning work declined over time. Choosing the work system is not a decision taken once.

That is the risk I see now, and it is the thread I want to follow through the next issues. Every AI deployment designed task by task is also a decision about the work system: about who checks, who learns, who decides and who covers. It is just a decision nobody takes. The work gets redesigned anyway, by default, and we discover the design afterwards in the numbers that do not add up, in the juniors who never became seniors, in the nurses who leave.

The task fallacy is not that tasks do not exist. It is the belief that once you have listed them, you have described the work…. and that once AI has taken some of them, you know what the work has become.

Next time I want to turn this on the function that, in most organisations, should be best placed to see work systems and is mostly equipped to see jobs: what happens to the HR operating model when its basic unit stops being the role.

In the meantime, a question. Pick one process in your organisation where AI has already taken over some of the tasks. Do you know what those tasks were carrying, besides their output?

Sergio

2. Site Updates

Two pages on the site belong next to this issue, and I did not mention either last time.

The first is the closest to it. The Work Matters Podcast — AI Needs Work Design is the page for my second conversation with Thomas Bertels, recorded in June and published in September, on why AI keeps failing to show up in the productivity figures. My answer was that the missing investment is not technical: it is the design of work. Listening back after writing this issue, I would sharpen one line: AI does break work down into tasks, but what it changes is the system the tasks sit in.

The second is a page I did not expect to write. Sustainability says what it costs, in electricity and carbon, to run the site and the tools I use to write it. The first full estimate, over two months, found that a reader costs very little, and that most of the footprint is the invisible work in between: AI tools re-reading context they have already read, and a background job that checked a set of files every fifteen minutes by downloading them again. Most of it, in other words, was work nobody had designed.

3. Reading Suggestions

From Hype to Impact — KennedyFitch. A disclosure first: I helped draft it, and I am one of the nine interviews in it. A survey of more than 200 HR professionals finds that 68% place their organisation at the awareness or exploration stage and only 15% report any deeper redesign of processes, decisions, workflows or roles. Its second position, redesign the work before the workforce, takes the workflow, not the job, as the unit of analysis: the argument of this issue, arrived at from the survey side.
Complexity Is Not in the Eye of the Beholder — Stefan Norrvall, on Substack. The Substack pick. When roles and systems are not designed for the work they have to carry, extra effort and repeated coordination hide the shortfall, and the people doing the hiding wear out first. A work system failing quietly, from the inside.
Don’t Design the Job Yet. Design the Work. — The People Process. A practical sequence: map what needs to happen, decide what can be simplified, automated or stopped, and only then design the roles around it. The order of operations this issue argues for, written for people who have to do it next quarter.
Can Leaders Count on Self-Organisation? — Phanish Puranam, INSEAD Knowledge. Self-organising teams still run on rules, norms and incentives somebody designed, and without them self-organisation can produce disorder as easily as cooperation. A useful corrective to any romantic reading of the composite groups in the essay.
The Collapse of Sensemaking in Organizations: The Mann Gulch Disaster — Karl E. Weick, Administrative Science Quarterly, 38(4), 1993. The scientific pick, from Zotero. A smokejumping crew falls apart when the structure of roles that held it together dissolves under pressure. Thirty years old, and still the best account I know of what happens when the relations between tasks disappear and only the tasks are left.

4. Events

Next week I will be at Zing 2026, Var Group’s event at the Palacongressi in Rimini. On 22 October I open the session Modelli agili e impatto reale al centro di un nuovo design organizzativo with Francesco Frugiuele (Leapfrog, Kopernicana), setting the scene on how organisations are evolving, before the People Leap community takes it into practice. The session is in Italian. If you are there, come and say hello.

5. The (un) Intentional Organisation 😁

The process map is complete. The process runs on Maria. Of course, AI Generated.

6. Keeping in Touch

Don’t hesitate to reach out by directly hitting “reply” to this newsletter or using my blog’s contact form.

I welcome any feedback on this newsletter and the content of my articles.

Find me also on:

Discussion about this post

Ready for more?