The Age of Decommission

Protect the expertise you will need next.

Automation does not remove the organisation. It redraws who absorbs the work.

A process can be automated while the organisation around it becomes more brittle: layers vanish, roles blur and the people left behind carry the unmeasured exceptions. The agent is a redesign event, not a headcount number.

What it feels like

The unnerving feeling that everyone’s title still exists while the places where decisions used to land have disappeared.

You are not confused by change. You are detecting a missing owner.

Everything is supposed to be simpler now.

It doesn’t feel simpler.

The titles remain. The meetings still happen.

The person who used to settle an awkward question hasn’t been fired, exactly. They’ve been moved into a programme role, or made responsible for enablement, or told to focus on strategy.

But the question now travels. It visits a queue, a platform team, a policy inbox, a manager who says it isn’t theirs any more.

You’re not attached to hierarchy for its own sake. You’re trying to find the person who can still make a decision stick.

That isn’t nostalgia for a manager checking every line before it left the building. It’s the ordinary need to know where an exception goes once the routine has been automated and the routine is no longer the work.

You’ve got deadlines, a customer waiting, a case that won’t fit the new categories, and no appetite for becoming the archaeologist of somebody else’s operating model.

Taking the faster route isn’t weakness. Asking an assistant to prepare the recommendation isn’t a failure of nerve.

The machine removed some of the friction that used to eat your afternoon.

Of course that feels like help.

Nothing wants your job. Something quieter is happening to the chart.

Automation redraws the organisation before it removes any of it.

It takes a decision that used to land with a named person. It divides that decision into preparation, approval, execution, evidence and recovery. Then somebody discovers nobody was named for one of the pieces.

2010 — A manager checks the work before it leaves.

2018 — The workflow routes the approval automatically.

2024 — The assistant prepares the recommendation.

2026 — The approval is still there. Nobody’s sure who owns the rule.

Subtraction is the wrong picture

The old picture of automation is a subtraction. A task disappears, then a role, then a layer.

The process record describes something less clean.

Before anybody makes a staffing decision, your redesign starts with a signed current-state map. Volume and demand mix. Elapsed and touch time. Error and rework. Spans and layers. Decision delays. Skills. Cost. Exceptions. Informal escalations.

Temporary parallel work. System maintenance.

Third parties.

Discovery is usually time-boxed at four to eight weeks. It isn’t a chart exercise.

It’s an attempt to see what your job description forgot.

That matters because the missing work is usually where the organisation hid its competence.

You can show the case that doesn’t follow the official route. The complaint needing a policy judgement. The data error only one analyst recognizes. The outage that sends a local team back to a spreadsheet.

The first product should be a map and a list of hypotheses. Not a declaration that your function is now AI-first.

A reduction without that map isn’t efficiency. It’s an unpriced bet that your exception will stay small.

The future map makes the bet visible.

It separates what automation eliminates from what it merely accelerates, what it newly requires, what gets more complex, and what stays yours.

It names your control points, customer recovery, data ownership, rule and model maintenance, platform dependence.

An automated step isn’t gone because a screen says it ran. It’s gone when somebody accepts the output, maintains the input and owns the fallback. Usually you.

Which is why you want at least three futures.

The expected case. A conservative case with more exception handling. And a disruption case where the tool is unavailable or the policy changed.

That isn’t pessimism. It’s a refusal to build a structure that only works when the machine is having a good day.

An Austrian insurer in the OECD record received more than 5,000 emails a day and used AI to sort them into sixty subject areas before human review.

Classification can change the entrance to a process at that scale. It doesn’t abolish the difficult cases that arrive after classification.

The chart is drawn in verbs

Once the work is named, several familiar drawings are available to you.

A functional structure with specialist homes. A value-stream team. A platform-and-pod model. A shared service. Or no reorganisation at all.

A serious shortlist is two to four options. More looks like open-mindedness while making sure nobody compares the decisions they move.

And the useful test is flatly unglamorous.

Run a priority conflict, a customer complaint, a rule change, an outage, a talent shortage and an audit request through each one. Count your meetings, handoffs, approval points, days to resolution.

The better chart isn’t the flattest one. It’s the one with a credible owner at every consequential decision.

This is where titles start lying to you.

A new role isn’t real because it has a new name, a competency badge and a line on a slide.

Its charter names your outcome, core activities, delegated decisions, limits, measures, required knowledge, learning path, relationships, and whether the role is permanent, transition-only or rotational.

It also says what moved to a supplier, a central service, a local team, or the automated component. And what stayed with you.

Name tasks but not authority and your old manager stays in the process as an unofficial approval. The hierarchy didn’t go away. It got harder to see.

You can recognize a shadow hierarchy by the tone of a meeting.

Everybody agrees the decision sits with the team. Then somebody waits for the former owner to nod.

Or the agent produces a perfect draft, and you, with no recorded delegation anywhere, have to decide whether the rule applies.

The correction is simple. You’re not confused by change. You’re detecting a missing owner.

The human version has an equally sharp distinction.

Redeployment isn’t a completed course, an encouraging manager, or a promise that your new skills will be useful somewhere.

It’s a funded destination role, protected training time, a receiving manager, and a start date.

During the first operating cycle, transition learning often needs a tenth to a fifth of work time protected for it.

That allocation admits you can’t rebuild judgement from the scraps left after normal output. It also admits that not everybody can or wants to take every new role.

More authority, more precisely

The agent makes this old problem finer-grained, and the direction surprises people.

The more work disappears from the ordinary path, the more precisely your remaining authority has to be described.

Reading, drafting and committing are three different kinds of work, and only the last one is irreversible.

That’s an organisation chart drawn in verbs.

Whoever defines the purpose isn’t necessarily whoever approves. The approver isn’t the runtime. The runtime isn’t the downstream system that records your change.

So don’t replace a manager with a broad prompt.

Give it only the operation it needs. Bind that to narrow authority. Put a gate before any act whose consequence is material or hard to reverse.

And this is the part of reorganisation that feels genuinely uncanny.

Your assistant produces a calm explanation with the texture of ownership. Its final message still isn’t the transaction.

The authoritative evidence is downstream. A confirmation number, a record version, a timestamp.

One of those says the system believes it finished. The other says something in the world changed.

Lose that distinction and you absorb the work without the authority to repair it.

Completion is not success

None of this proves an organisation got better by finishing its transition.

In one 2025 McKinsey survey, 79% of redesigns were reported completed and implemented, while 63% met most objectives and improved performance.

Completion and success are separate claims.

The same restraint applies to cause. A removed layer doesn’t prove a cost reduction if a hiring freeze did the work. A new role doesn’t prove quality improved if somebody fixed a system defect the same month.

Your measurement note has to name scope, period, baseline, missing data, concurrent changes, and adverse effects.

The tests are deliberately awkward.

A stable weekly service can use a twelve-week baseline. A seasonal one needs a full annual cycle.

A median improvement means little if your ninetieth percentile got worse for complicated cases.

Your scorecard can demand zero unassigned critical decisions, current charters for every live role, named ownership for every shared service.

Then trace your last ten high-frequency decisions and your last five high-consequence exceptions.

A name on a chart isn’t decentralisation until that person has actually made the decision.

Memory gets the same treatment, and it’s the test most organisations skip.

Give your receiving team rare, historically important cases. Ask them to find the source, explain the old rationale, identify the expert, and produce the route without help.

Watch completeness, time, and how much correction they need. Return at thirty, ninety and a hundred and eighty days after a major transfer.

That’s what your vanished layer contained. Not headcount. Shortcuts to the reason a rule exists.

There’s no comfort in pretending every new structure will be coherent, and no virtue in treating the old one as sacred.

The reviews have a cadence. Weekly for early operational defects. Monthly for spans and decisions. Quarterly for role health and cost. And after any system, policy or demand change.

Ask for stable service over three review cycles, no unresolved critical decision gap, and a verified memory test before anybody calls it settled.

If it fails, the boundary changes, capacity returns, or the change reverses.

The announcement was never the proof.

Automation doesn’t make the organisation disappear. It distributes it.

Some of that distribution is good. A routine answer reaches your customer sooner. A specialist stops spending the morning routing mail. An assistant makes a recommendation legible.

But distribution also lets everybody keep their title while nobody owns the rule, the exception, the evidence or the recovery. Which leaves you.

The unsettling thing isn’t that a machine took the work.

It’s that the work moved, and the right to decide didn’t move with it.

Put this to work

  1. A credible redesign begins with an observed current-state process map that includes exceptions, informal escalations, and temporary work.
  2. Future-work design separates eliminated work from faster work, newly required work, complex exceptions, and human-only decisions.
  3. Role charters must state delegated decisions, limits, measures, interfaces, and required knowledge as well as activities.
  4. Redeployment has a funded destination role, training time, a receiving manager, and a start date; training alone is not mobility.
  5. Structural, service, capability, mobility, and organizational-memory measures test different claims about redesign success.
  6. Agent systems require different named owners for proposal, approval, tool execution, policy enforcement, and recovery evidence.

Questions

What should be mapped before an automated process changes the organization?
The current-state map records the process boundary, customer outcome, automation scope, sponsor, process owner, constraints, volume, demand mix, elapsed and touch time, error, rework, spans, layers, decision delays, skills, and cost. It also includes temporary parallel work, system-maintenance roles, third parties, exceptions, and informal escalations. Job descriptions alone omit the work that keeps a nominal process operating.
Why is a new organization chart not enough after automation?
A chart shows reporting lines but not whether a consequential decision has a credible owner. A redesign tests service interfaces, accountabilities, manager spans, escalation paths, and the decisions moved from a layer to a team or platform. Realistic cases such as a priority conflict, outage, rule change, talent shortage, customer complaint, and audit request reveal whether authority works under demand.
What work remains after a process is automated?
Future-work mapping separates work eliminated by automation from work made faster, newly required, more complex, or still human-only. It identifies control points, service recovery, data ownership, rule or model maintenance, and platform dependencies. An automated step is not gone until someone accepts its outputs, maintains its inputs, and owns the fallback when the system is unavailable or wrong.
What makes a redesigned role real rather than a renamed job?
A role charter states the outcome, core activities, delegated decisions, limits, measures, required knowledge, learning path, key relationships, and whether the role is permanent, transition-only, or rotational. It also names work moved to an automated component, centralized service, supplier, or local team. A task list without decision authority leaves the old hierarchy to reappear through informal approval.
When does redeployment actually count as redeployment?
Redeployment counts when a person has a funded destination role, protected training time, a receiving manager, and a start date. Training without a demand destination is a holding pattern rather than mobility. Durable placement also needs evidence after transfer, including retention after 90 and 180 days, role accountability, and performance in the receiving role.
How can an organization tell whether a flatter structure still has clear decisions?
A structural scorecard can require zero unassigned critical decisions, current charters for 100% of live roles, and a named owner and service measure for 100% of shared services. It then traces the last 10 examples of each high-frequency decision and the last 5 high-consequence exceptions. The trace shows elapsed time, people involved, evidence, and whether the formal decider actually decided.
Why do averages hide whether automation has made the organization brittle?
A median cycle-time improvement can conceal a worse 90th percentile for complicated cases. Measurement therefore separates automated from non-automated cases, new from experienced employees, and locations or business lines with different support. A design that handles 95% of normal cases but cannot safely handle the remaining 5% can be unacceptable when that tail carries material risk.
How is organizational memory tested after roles or layers disappear?
A memory test selects rare, historically important cases and asks the receiving team to locate the source, explain the prior rationale, identify the responsible expert, and produce the correct route without help. Completeness, time, and correction need are scored. Decision logs, source-owner lists, exception libraries, and skills maps are retained and re-tested at 30, 90, and 180 days.
What is the difference between an agent preparing a change and an agent making it?
Read-only retrieval can disclose information but does not alter a record; a proposal creates a reversible draft; a commit changes a business, legal, or physical state. Those effects need different tool constraints and owners. A policy engine independently checks the tool name, arguments, resource, principal, state, budget, and current approval before a commit executes.
Why is an approval request not the same as an approval?
An approval is a workflow decision bound to an action type, affected resource, exact arguments or digest, supporting evidence, policy version, requester, approver, and expiry. It records one of four outcomes: approve, reject, request further evidence, or cancel. If the source record, tool argument, or policy changes, the earlier approval does not authorize the changed action.
Who owns an agent action when several systems are involved?
Ownership is split deliberately. The agent prepares a bounded proposal; the authorized approver decides whether it may proceed; the runtime enforces policy and resumes only after a valid decision; the downstream system commits the state change; and the trace records request identity, policy, credential scope, tool result, approval, and recovery event. A model’s completion message is not the owner or proof of the transaction.
How should a redesign claim be qualified when several things change at once?
A measurement note states scope, period, baseline, comparison method, missing data, concurrent changes, and adverse effects. It distinguishes improvement associated with automation or structural change from improvement caused by a demand shift, new staffing, a hiring freeze, a system repair, or a changed definition. Layer removal does not by itself prove cost reduction, and project completion does not prove operational success.