Some of the work automation removes was an apprenticeship. Reviewing documents, investigating exceptions, and reconciling discrepancies give junior staff repeated exposure to the patterns experienced colleagues recognize at a glance. Nobody budgets for that exposure, so nobody notices when it disappears.
The result can be a team that delivers with its current experts and tools but is no longer developing the people who will succeed them. The gap may stay hidden until a senior colleague leaves or a system fails.
There is evidence for a related recovery risk. In a controlled navigation task, Endsley and Kiris found that lower situation awareness under automation was associated with slower decisions after a system failure. That result does not establish how quickly a company’s bench thins. It does show why a fallback should be tested, rather than assumed from a job title or training record.
A capability decision, not a tooling decision
An effective Center of Excellence raises capability across the whole organization. That includes making tools useful and supporting adoption. It also includes deciding, deliberately, which skills the new operating model still requires and where those skills will now be built.
A productivity dashboard shows the hours automation saved. It shows nothing about the experience people stopped gaining. Leadership’s job is to make that tradeoff explicit before it surfaces as a succession problem or a resilience problem.
An illustrative example
Consider a group that automates first-pass review of contract documents. A model extracts terms, flags deviations, and routes exceptions to senior staff. Junior colleagues handle far fewer documents end to end.
Two years on, the group needs to promote someone into the role that negotiates the hard clauses, and finds that nobody below the current senior tier has read a contract end to end since the automation landed. The work that built that judgment was the “inefficient” first-pass review. Nothing on the dashboard ever showed the debt accruing.
The version of this story that ends well starts identically. The same automation lands. But before cut-over, the group writes down which parts of the first-pass work were training future negotiators and keeps a deliberate share of files flowing through junior staff by hand: as scheduled practice, scored against the same deadline the automated path must meet.
That practice is also the recovery plan. When the model’s vendor changes its output format and the automated route breaks for a week, the group carries the workload manually, because the capability was never allowed to lapse.
Four questions before automating
- What judgment does this work build? Name the senior skill the routine task is quietly training. If the answer is none, automate freely.
- Where will that judgment be built afterward? If the answer is nowhere, you are about to take on talent debt. Decide how much, on purpose.
- When did someone last do this by hand, and did they meet the deadline? If nobody can answer, the fallback exists only on paper.
- Who could carry the workload if automation failed? Count them. Compare the count with what the workflow’s own deadline would demand.
Ask again a year after adoption. A training plan describes an intention. Observed performance shows whether the capability is actually there.
None of this argues against automation. It tells you where the bench is thinning so you can choose the debt deliberately, or refuse it. The question every operating model has to answer is whether the organization is still building the judgment it expects to rely on.