Redesign Tasks Before Headcount — สัญญาประชาคมของงานในยุค AIRedesign Tasks Before Headcount — The Workforce Compact

🤔 If 1 in 4 workers worldwide are in occupations that "touch" generative AI, does that mean 1 in 4 are about to lose their jobs?

The previous post, What the Evidence Says, closed on a knot I left deliberately tied. When AI takes over the routine cases that used to be the training ground for beginners, where does the organisation let people learn — and how are the productivity gains shared? Neither question is technical. They are questions about how work is designed and how the benefit is divided, and they are the heart of Chapter 11 and of this entire post.

The short answer to the whole post is that the unit you can actually design a workforce with is the task, not the job title. Break the role into its component tasks, classify the future of each one five ways, then reassemble the role so that the routine work that disappears is replaced by higher-value responsibility rather than by a larger workload — and write the commitments on data, notice, appeal, redeployment and the sharing of saved time down clearly, before the choices become impossible to reverse.

1. Exposure Is Not Displacement

Chapter 11 of AI Transformation as an Organizational Core opens with a single sentence that works as both conclusion and warning: "The useful unit of workforce redesign is the task and the social choice is how authority opportunity risk and productivity gains are shared." The sentence has two halves, and most of the organisations I have gone in to help do the first half deliberately and skip the second half whole.

What usually arrives first is a number. An executive reads a headline saying "one in four workers worldwide at risk of replacement by AI", then walks into a meeting with a brief: what percentage of headcount can we cut by the end of the year. The trouble is that the headline has read the wrong kind of number.

The International Labour Organization's refined global index estimates that one in four workers worldwide are in occupations with some generative AI exposure^[1]. That figure measures technological exposure at the occupational level, scored at the task level and aggregated up to occupations by ISCO code. It is not a count of positions lost, not a count of redundancies, and not an employment forecast. Exposure versus displacement are two different things, and the real outcome still varies by occupation, by sex, by country income level, by adoption cost and by policy.

In the same index, only 3.3 per cent of global employment sits in the highest exposure category^[1], and because most occupations still contain tasks that require human input, the report concludes that the more likely trend is job transformation rather than the replacement of whole occupations. The distance between 25 per cent and 3.3 per cent is the distance between "some parts may be affected" and "almost the entire occupation sits in territory a machine can take over" — and it is the distance a headline always collapses.

The third number in the same index is the one I think matters most for design. The highest exposure category is not evenly spread — it accounts for 4.7 per cent of female employment against 2.4 per cent of male employment^[1]. That is why the "Access by group" metric in section 7 is not a garnish added for the beauty of an ESG report but a first-class metric of this chapter. In the same way, exposure differs sharply by country income level — roughly 11 per cent of employment in low-income countries against 34 per cent in high-income countries^[1]. A global number can therefore never stand in for any one Thai organisation.

There is another family of measures that gets mixed in with this one very often. The OECD estimated back in 2023 that the occupations at highest risk of automation account for roughly 27 per cent of employment across OECD countries^[2]. That 27 is no relation of the ILO's 3.3, and the two must never be set side by side as though they were the same instrument — the OECD scores an occupation's risk of automation across several technologies including AI, while the ILO scores task-level generative AI exposure. Different year, different population, different definition, and both are risk estimates rather than employment forecasts. The same OECD report states for itself that the observed impact on employment levels up to that point was "still limited".

Line all the numbers up and there is exactly one practical conclusion: exposure is a question for inquiry, not a reduction formula — and that is the first of this chapter's five operating principles.

💡 My view: if I had to pick one sentence from Chapter 11 to pin up in the HR meeting room, I would pick principle 1 in the book's own words — "Redesign tasks before changing headcount Exposure is a question for inquiry not a reduction formula." The order of those two things is far less a technical bottleneck than it looks; it is about whether an organisation lets a global number stand in for the analysis of its own work. I have never seen an organisation announce a headcount number first and analyse tasks afterwards with a good result, because once the number is out, the analysis that follows becomes a search for justification rather than a search for the truth.

The Five Operating Principles of This Chapter

I have taken principle 1 above. The remaining four are the frame of the entire post, and I will walk them one at a time in section order. Principle 2, train against real decisions and workflows — course completion is not proficiency, which is the business of section 4. Principle 3, preserve human authority for consequence — make accountability and contestability explicit, which lives in sections 2 and 3. Principle 4, provide notice, voice, privacy and remedy — trust depends on procedural fairness, which is the spine of section 5. And principle 5, share gains deliberately — measure job quality as well as output, which runs from section 5 through to the metrics table in section 7.

Read cold, the five look like slogans. Turned into commitments with an owner, evidence and a review date, they are what this chapter calls the workforce compact — and they are what separates an AI transformation people still want to work inside from a productivity programme that lays people off by other means.

2. The Unit of Design Is the Task, Not the Job Title

"Which positions will disappear" is too coarse a question to answer, because every position is a mixture of several kinds of task. The playbook separates a role into seven components: routine processing, prediction, judgment, relationships, physical work, exception handling and accountability. AI may take some over, augment others, and — the point most often missed — make the tasks humans still own more important, not less.

Those seven components are why the playbook starts from task decomposition for each role, filling in seven fields per task: Task, Frequency, Time, Knowledge, Error Consequence, Data and Feedback. The last field is the one most teams forget — does the task come back with any signal that it was done rightly or wrongly, and how slowly does that signal arrive? With no feedback at all, neither the person nor the system can learn anything from the task, and putting AI into it merely speeds up something nobody can tell is right or wrong.

Classify the Future of Each Task Five Ways

Once the tasks are separated, the next step is to classify the future of each one as one of five, with "it depends" not permitted as an answer. The five are eliminate — work that should not have existed in the first place, and that is usually discovered during this very mapping exercise; automate — routine work that is measurable and bounded; augment — creation, synthesis and preparation, where the person is still the one who decides; create — tasks that never existed in the old role, such as looking after the quality of what the system proposes; and retain under human authority — the work that carries ambiguity, relationship and consequence.

The least-used route in practice is "eliminate", even though it is the fastest and cheapest return available. Plenty of organisations start an AI project and find that the report a team spends two days a month producing has not been opened by anyone in two years. Getting AI to write that report ten times faster is not transformation. It is doing something that should not be done at all, faster.

I want to press one distinction the playbook draws deliberately and that consultants' slides routinely collapse — the five-way classification is not the same thing as the three columns in Figure 15. The five-way classification is the decision step: where does each task go? The three columns are the design surface: once everything is placed, what owner, what evidence and what escalation path does each group need? Do not merge the two into one picture, and do not renumber either.

Figure 15 is plain enough to look as though it says nothing, but its structure carries two layers of message. The first is the scope line under each column heading: AUTOMATE takes work that is routine, measurable and bounded, AUGMENT takes creation, synthesis and preparation, and HUMAN AUTHORITY takes work carrying ambiguity, relationship and consequence. Those three lines are criteria, not descriptions. If a task does not meet all three words in the left-hand column's line, it does not belong in the left-hand column yet.

The second layer is the three rows that repeat in every column — Owner, Evidence, Escalation. This is the part I most often see left out of a drawing, because it looks like paperwork; what it means is that every task must have the name of a person who is accountable, evidence that says whether it is being done well, and a path to hand it on when it exceeds its bounds, whichever column it sits in. A task being automated does not mean it has no owner — it means the owner's job changes from doing to supervising, and that is human oversight in the playbook's sense: a role designed with the information, competence, time, authority and usable controls to intervene, not a ceremonial approval box.

The word that has to be defined alongside it is accountability, which the playbook fixes clearly as ownership of decisions and their effects, supported by answerability, evidence, escalation, remedy and consequences — not responsibility handed to the model. The sentence sounds obvious to the point of dullness, but I have read several system design documents stating that "the system will be responsible for prioritisation", which in law and in practice means that nobody is responsible at all.

With the three columns laid out, what we are actually designing is not "replacement" but human–AI complementarity, which the playbook defines as a task-specific division of labour whose combined performance beats the realistic human-only and AI-only alternatives on the outcomes the organisation cares about. The load-bearing words in that definition are "realistic alternatives" — measured against humans working under real conditions, not against an idealised human. That is where the figure's footer line comes from: test human only, AI only, and human plus AI, which is the methodology post #7 already laid down.

3. Reassemble the Role, Do Not Add to the Load

The step that decides whether a work redesign succeeds or fails is not the classification step but the reassembly step. The playbook writes one sentence about it, and it is the sentence I would like everyone running this kind of project to remember: reassemble the role so that the routine work lifted out is replaced by explicit higher-value responsibility, not simply by a larger workload.

The most common silent failure looks like this. A team brings in AI to help draft documents. The time per document really does fall. A manager sees the number and raises the volume per person in proportion to the saving. At quarter end the productivity metric is better, but the engagement survey is worse, attrition among the heaviest users of the tool runs higher than elsewhere, and quality at the far end of the process has begun to slide in a way nobody is measuring yet. What happened is that the organisation converted "time saved" into "quota added" automatically, without anyone ever formally deciding to.

The fix is not to forbid raising targets. It is to force the allocation of saved time to be a decision with a signature on it, which is the business of section 5. At the level of role design, the fix is that every time we remove a task from a role, we must write down which task replaces it, and that new task must be a higher responsibility rather than more of the same volume. If you cannot write it, the design is not finished.

What the Early Experiments Tell Us — and What They Do Not

Humans in the Loop, from the MIT Industrial Performance Center, synthesises interviews and workshops with more than 50 companies across health, insurance, finance, manufacturing and retail^[4]. Before reading its findings you have to read its scope. This is a deliberately purposive selection of early cases, not a statistical sample. Its results are therefore signals for design, not statistical estimates of a whole population. Do not convert this report's observations into rates or prevalences, and do not write "most companies found that…" on a slide.

Within that limit, what the playbook takes from the report is that these companies' early experiments aimed at three things — bottlenecks, expert synthesis and learning curves — which the report itself names the bottleneck problem, the cafeteria problem and the learning-curve problem, with the further observation that some professional and technical work is shifting toward supervisory control: people moving from doing the work to supervising what the system produces. All of this is an early pattern, not a settled outcome.

Those three are very good at helping choose a starting point, and I use them often when a team asks "where should we start?". The answer is not "start with whatever takes the most time" but "start at the bottleneck of the process", because speeding up a step that is not the bottleneck changes the total time of the process not at all — an old lesson from process engineering that AI has not repealed, and the reason post #6 insisted on redesigning the whole workflow rather than tuning it a step at a time.

The Learning Curve Is the Debt You Cannot See

The third one is what worries me most over the long run, and it is a direct bridge from post #7. Easy, repetitive, routine cases are the training ground for beginners in nearly every profession. Junior lawyers grow up drafting hundreds of standard contracts, accountants grow up on straightforward reconciliations, claims officers grow up on cases nobody disputes. Hand all of those cases to the system in a single day and we get an efficiency gain this year and a capability gap in five years that nobody can fill.

The MIT IPC report also flags a companion risk, mental offloading — pushing the thinking onto the system until the ability to think it through oneself decays. That is a risk to learning rather than to short-term output, and it is why the "Time to proficiency" metric in the table in section 7 has to be genuinely measured rather than assumed.

The way out that I use and have seen work is do not hand over all the training cases. Reserve a share of the routine cases as work people do themselves without the system, and state in the design document that the share exists to build capability, not because the system cannot handle it. Without that reason written beside it, the share is cut at the next efficiency review, every time, because from the perspective of a cost table it looks like pure waste.

4. Skills Must Follow the Redesigned Workflow

The order of that sentence matters as much as its content. The playbook says skills must follow the redesigned workflow, not lead it. Plenty of organisations do it the other way round, buying an AI course for the whole company first and only then wondering which process to use it on. The result is twenty thousand people who have passed a three-hour online course, hold a certificate, and go back to doing everything exactly as before, because nothing in their daily work has changed.

Once the workflow is designed, the skills to be built separate into four clearly different tiers, and each tier needs a different way of teaching.

Beyond these four tiers, the playbook names a fifth group separately — the AI team itself — which needs three capabilities that are usually missing: Operations (running the system that has to work every day), Human Factors (designing so that people can genuinely use it and are not pushed into rubber-stamping) and Change Capability (the ability to take an organisation through a change). A team that is excellent at models and has none of the three will deliver a system that is technically correct and that nobody uses.

And the most indispensable item is the last one — frontline people need protected time to practise with real work. Protected means blocked out in the schedule and defended against the daily load, not "learn when you have a moment", which means not learning. In an organisation measured on items completed per day, failing to reserve the time formally is the same as ordering staff to choose between learning and their own metric, and nobody chooses the first.

A Prompt Course Alone Is Not Reskilling

This is operating principle 2 of this chapter — train against real decisions and workflows; course completion is not proficiency. The playbook gives a straightforward formula: building real capability takes five things together — short instruction, supervised practice, job-based assignments, coaching, and demonstrated proficiency.

I want to underline the third, because it is the one that most sharply separates the programmes that work from the ones that do not. The assignment has to come from that person's own real work, not from a case study on a slide. The reason is not motivation alone; it is that what we want is evidence that they do their job better, not evidence that they can do an exercise. And measuring by demonstrated proficiency on real work throws in something valuable for free: it exposes exactly where the process we designed on paper does not work.

The question that always follows is "how long does it take before someone counts as proficient?". The straight answer is that nobody can tell an organisation that, and that is exactly why time to proficiency is a metric to be measured rather than a constant to be sourced from elsewhere. Measure it on the first cohort against demonstration criteria announced in advance, then use that figure to plan the next cohort. An organisation that does this knows within two cycles whether its own programme works. An organisation that measures course-completion rates will never know at all.

5. The Workforce Compact

By this point we have redesigned roles and a skills plan tied to real work. What is still missing is the second half of the chapter's opening sentence — how authority, opportunity, risk and productivity gains are shared. That half has no technical answer. It is an answer leaders have to choose, and not choosing is itself a choice.

Worker Voice — Before the Choices Become Impossible to Reverse

The playbook uses worker voice in a sense far wider than "gathering opinions": meaningful frontline participation from problem definition through design, testing, monitoring, job redesign and skills planning, all the way to sharing the gains of the transformation. Notice that the list begins at "problem definition", which is the stage frontline staff are least often invited into, and the stage at which their knowledge is worth the most.

The MIT Sloan report Bringing Worker Voice Into Generative AI is built on more than 50 interviews^[5] and proposes four phases for bringing worker voice in: defining the problems, codesigning the technology and the work processes, education and retraining, and fair transition — with the observation that experiments starting from workers themselves tend to produce better-aimed problems, and that a participatory design body helps concerns get caught before the system goes live. All of it has to be adapted to each place's structures of worker representation, industrial relations, culture and law — the context of an American company with a union and a Thai company with a welfare committee are not the same, and the method should not be copied across directly.

Timing matters as much as method. The playbook fixes it: bring worker voice in before workflow choices become difficult to reverse, because once the system is wired into the core databases, the vendor contract is signed and the new metrics are announced, consultation becomes ceremony rather than design.

Five Commitments That Have to Be Written Down

The playbook lists five things people must be told, and I recommend writing them as a one-page document with the name of a responsible person on it, not as a slide in a town hall. The five are: what is changing, what data is collected, how that data affects performance decisions, which decisions remain human, and how errors can be challenged. The third and the fifth are the two most often written vaguely, and the two that decide whether people will trust the system.

Alongside them is the list of things to monitor, which the playbook fixes at five — work intensification, autonomy, privacy, psychological safety, and uncompensated review labor. The last one is the one I see most often and hear discussed least. Once a system starts producing proposals in volume, the reviewing work flows onto the same group of people with nobody counting it as extra work, because in the eyes of the measurement system it is "clicking confirm".

The Distributive Question — and Why It Needs a Signature

Operating principle 5 of this chapter is share gains deliberately; measure job quality as well as output, and the reason sits in one sentence of the playbook: productivity gains are not automatically shared. Leadership has to decide where verified time savings go among six destinations — customer value, quality, learning, reduced workload, growth, or financial return. Without that decision, AI may simply compress schedules and raise targets.

I would like you to notice the word "verified" in that sentence. Time saved as the vendor estimates it is not time actually saved, and time actually saved at one step is not time saved across the whole process — if drafting time falls by twenty minutes while review time rises by twenty-five, the organisation has saved nothing at all, it has merely moved the load from one group of people to another. The distributive decision therefore has to come after end-to-end measurement, not after reading the vendor's slides.

There is one further reason to do this out in the open. In the OECD's 2023 survey, roughly three in five workers were worried about losing their job to AI within ten years, and most of all the ones who actually work with AI^[2]. The number is not evidence that jobs will disappear — it is evidence about trust, and it measures expressed worry rather than outcomes. But for anyone who has to design a transition, worry at that level is a fact to design around, not a misunderstanding to be corrected by communication. And it is why this chapter treats trust and error-reporting comfort as first-class metrics. Someone who fears that reporting a fault in the system will come back as evidence that they are not needed will not report that fault, and the organisation loses the most expensive signal it has.

6. The Working Session — Role Redesign and Workforce Compact

The playbook gives the working session as a single paragraph. I have broken it into seven steps so that it can serve as an actual meeting agenda. One, select one role and map its tasks. Two, score each task on five dimensions — Frequency, Time, Error Consequence, Data Readiness and Human Value. Three, classify it as Eliminate, Automate, Augment, Create or Human-owned. Four, assemble the Future Role and find the Workload Gap and the Accountability Gap. Five, define the Skill, the Practice Assignment and the Proficiency Evidence. Six, agree the commitments on Data Use, Notice, Appeal, Redeployment and Feedback. And seven, name the Role Owner, the Worker Representative, the Pilot Cohort and the Review Date.

The constraint that matters is one role only. I have watched an organisation try twelve roles at once in a single session and come away with a table nobody dared decide anything from, because no role had been analysed deeply enough. Choose a role with many people in it, with clear routine work, and with someone willing to sit in the room as their representative — then take it through all seven steps.

Steps 1–3 · Scoring and Classifying the Tasks

The table below is one I have filled in with the claims-officer role at Aurora Assurance (a fictional case from the playbook), to show what a completed sheet ought to look like. The scores in the example use high/medium/low bands for readability; a real organisational worksheet should carry genuinely measurable numbers — occurrences per week and minutes per occurrence — rather than bands assessed by feel.

Look at the last row. Frequency and Time are dashes, because that task did not exist in the old role. It is a task that was created to take on the work the first three rows gave up, and its presence in the table is the evidence that the role has genuinely been reassembled. If a team's table has only Automate and Human-owned rows and no Create row at all, we are removing work from a role without putting anything back — and that is headcount reduction dressed up as work design.

Step 4 · Assemble the Future Role and Find the Gaps

This step is done on a single sheet with three columns: the old role, the new role, and the gaps that appear between them. There are two kinds of gap to find. The Workload Gap is when the time removed and the time added do not match; if the time added exceeds the time removed, we are designing extra load and calling it an upgrade. The Accountability Gap is a task that has moved across to the system's side without anyone being named to answer for its results.

In the example above, the Accountability Gap sits in the first and second rows, the ones classified as Automate — who is accountable when a document is categorised wrongly and the case joins the wrong queue? The answer has to be a person's name, not a system's name, and that person needs the information to see the error, the time to look, and the authority to order a stop. Missing any one of the three and we have a named owner but no real oversight.

Step 5 · Skills, Practice and Proficiency Evidence

The last column is one I add myself to every worksheet I actually use, because the first three columns always write up beautifully. The fourth is the column that says whether the organisation means it. A skills plan with no time in the schedule behind it is an aspiration, not a plan.

Steps 6–7 · The Workforce Compact Table

This table is the working session's final product, and it is a document I recommend posting somewhere staff can read it for themselves rather than filing it in an HR folder. The five commitments come straight from the playbook; the four right-hand columns are what make them commitments rather than statements.

Step seven is filling in the four names that give everything above an owner — Role Owner, Worker Representative, Pilot Cohort and Review Date. I have seen documents of this kind that were immaculate in every box except the last two, and the result was that they were never reviewed at all, until a complaint arrived and somebody finally opened the file. A review date fixed in advance is the only mechanism that keeps a set of commitments from turning into a historical document.

7. The Metrics That Matter

Chapter 11 gives a longer list of metrics than any other chapter in the playbook, which I take to be deliberate, because a work redesign measured on output alone always looks good in the short run. The table below is the playbook's list, with the Scorecard column added as this series does throughout, so that you can see which box of the organisational scorecard each metric lands in — and so that the whole chapter is not measured on a single dimension, time saved.

The most neglected metric in this table is Override quality. Most organisations measure only the rate at which people disagree with the system, and read a low rate as a good system, when a low rate may equally mean people have stopped checking. What has to be measured is quality: when a person disagrees, who was right, and when a person agrees, what share of the time they agreed with a wrong proposal. That pair of numbers has to come from expert back-sampling, not from the system's logs alone.

Failure Patterns

• Announcing job cuts before task analysis — once the number is out, the analysis that follows becomes a search for justification rather than a search for the truth, and the cooperation of the frontline disappears the same day.
• Teaching everyone the same Prompt course — a central course tied to no role at all produces certificates very fast and capability very slowly.
• Adding AI review on top of full workloads — asking people to check the system's output as well without removing any of the existing load is adding work that is never counted, and it is the shortest road to clicking confirm without reading.
• Monitoring staff without transparency — collecting tool-usage data and using it in performance assessment without notice destroys both the trust and the quality of the data collected, because people start working for a good-looking log rather than for good work.
• Rewarding usage volume — measuring success by the number of times the tool is invoked makes everyone use it on work it should not be used on, so that the number goes up.
• Removing junior tasks with no learning path — hand over all the routine cases that used to train people, then discover three years later that nobody in the organisation is ready to step up and decide the hard ones.
• Giving tools only to the groups already advantaged — start at head office and with the loudest teams, and the gap between groups widens on the organisation's own budget.
• Ignoring Thai performance — use English benchmark scores as evidence that the tool works, then leave frontline staff to discover its limits for themselves in front of a customer.
• Promising augmentation while pursuing an undisclosed automation target — the gravest of them, because when the truth emerges the organisation loses the trust and the information from the frontline at the same moment, and the next transition becomes far more expensive for reasons that have nothing to do with technology.

The first eight can be solved by design — with the sequence in section 2, the skills plan in section 4, and the commitments table in section 6. The last one cannot be solved by design at all. It is a choice about whether to tell staff the truth, and if the organisation has decided that the real goal is a reduction in headcount, the least damaging route is to say so plainly, with a plan to support it, rather than calling it augmentation.

8. The Road Ahead

If the whole chapter had to reduce to a single change in how you work, I would choose this one: change the unit of the workforce conversation from "the position" to "the task". The question "which positions will disappear" produces fear and numbers nobody can prove. The question "which tasks in this role should be eliminated, automated, augmented, created, or retained under human authority, and who is accountable for the result of each" produces a plan that can be carried out within a single quarter.

There are three things you can do immediately next week. One, choose one role with several people in it and complete the task-scoring table in section 6, with the people who actually do that work sitting in the room. Two, open the latest design document for the AI project about to go live and find the page that says where the time saved will be allocated — if there is no such page, that is the page to write before Release. And three, check whether the training plan you already have carries a "proficiency evidence" column and a "protected time" column; if it has neither, that plan is still only a timetable.

The playbook's next chapter changes the question from "people and work" to "components". Once roles and processes have been redesigned, an organisation discovers immediately that every team is building the same thing over and over — the same datasets, the same context services, similar evaluation sets, and dashboards measuring the same thing in different ways. The question of which components should be built once and reused across the whole organisation is the question that makes the next use case cheaper and safer at the same time.