Your team has a promising AI proposal. The expected benefits are clear: less time preparing the work, faster delivery, and more capacity for customers. Someone has estimated the software cost and the effort required to implement it. Before approving the investment, answer this question: how will people learn the work once this part of it changes?
That question belongs in the business case, not after the fact. If a workflow helps develop capabilities the company will need later, changing it creates a responsibility to examine how those capabilities will develop next. The answer needs an owner, resources, and a way to judge whether it works. Otherwise, leaders can approve an efficiency gain while leaving a consequential part of the operating model unplanned.
Look Beyond the Job Title
Revelio Labs' September 2026 AI Labor Market Tracker, released October 1, attributes 90% of the year-over-year change in its work-activity measure to changes within occupations. That figure describes where measured change occurred; it doesn't mean 90% of work has changed or been automated. The tracker also reports employment growth at firms it classifies as AI adopters, with larger gains among senior roles than junior ones (Revelio Labs: AI Labor Market Tracker, September 2026).
These findings require care. The adoption classification uses job postings for roles that build or operate generative AI systems, which signals intent to implement AI and doesn't confirm successful deployment. Adopting firms were already growing faster before adoption. Professional profiles and job postings provide useful signals, but these comparisons don’t establish that AI caused the observed changes (Revelio Labs: Tracker methodology).
The leadership question I take from this is about what an organization can miss when it watches only its headcount. A role can retain its title while the employee's opportunities to investigate, practice, and receive feedback change substantially. That possibility deserves attention before the company needs a new generation of experts.
Identify the Learning Inside the Task
Consider a hypothetical commercial team introducing AI to prepare customer proposals. The system assembles requirements, estimates effort, and drafts the recommendation. Experienced account leaders review the result. The immediate business case might look very attractive. But suppose newer employees previously helped investigate ambiguous requirements, compare options, and discuss why a particular promise would be difficult to keep. Some of that preparation may have helped them understand the business, and there’s value in that.
Some of that preparation may also have been avoidable administration. Reformatting a document for the twentieth time is not necessarily a useful developmental experience. Neither is struggling alone with a problem and never learning why the answer was wrong.
Leaders have to distinguish the activity from the capability it was supposed to build. In this example, the valuable learning might be recognizing an incomplete requirement, understanding a delivery constraint, or knowing when to question an attractive estimate. Once those capabilities are explicit, the team can consider better ways to develop them. AI might make it easier to assemble practice cases, compare alternatives, and explore unfamiliar situations. Experienced colleagues can help check those cases and connect them to operational reality. The design question is which combination gives people useful experience at an acceptable cost. Keeping every old task would avoid that question just as surely as automating everything without examining it.
A Good Deliverable Is Only Part of the Evidence
EnterpriseBench, a preprint submitted September 29, 2026, evaluates AI agents using static business questions and interactive simulations involving incomplete information, delayed feedback, and planning. Across the models and methods tested, strong question-answering performance did not reliably predict interactive decision-making performance. These are controlled simulations of AI agents; they don't test human learning, and they don't represent every current model (arXiv: EnterpriseBench).
I would carry that distinction into workforce development cautiously as producing a polished answer and demonstrating usable understanding are two different things. For the proposal team, the employee's finished document can’t tell the manager everything. The manager also needs to know:
Can the employee identify information that’s missing?
Can they explain which assumption could change the recommendation?
Do they recognize when the system's output conflicts with the company's delivery capacity?
Can they reconsider the answer when the customer introduces a new constraint?
Management’s objective should be to discover whether the employee can use assistance thoughtfully and recognize when further inquiry or escalation is needed; unaided performance for its own sake matters much less. This is my proposed management application of the distinction, and EnterpriseBench didn’t test any training methods.
Give Development a Place in the Investment Decision
At Whole Enterprise™, the concept of Human Value Moves Upstream™ expresses an ambition for people to gain capability and agency as intelligence becomes more available and less of a human differentiator. Realizing that ambition requires a route into the work that organizations expect people to do next. For any significant redesign, I would add four commitments to the investment proposal.
Name the capability the business will need. Be specific enough to observe it. In the commercial team, that might mean recognizing when a standard offer can’t meet a customer's requirements. Include experienced employees whose work is changing as well as those entering the field. Seniority doesn’t make professional development unnecessary.
Design the replacement experience. Select a manageable set of past cases and remove the eventual answer. Ask employees to investigate, recommend a course of action, and discuss their reasoning with a qualified colleague. Then reveal what happened and examine where the case remains ambiguous. Include unfamiliar cases later to see whether understanding carries over. Treat this as an approach to test and improve.
Fund the work and assign an owner. Estimate the time needed to prepare cases, provide feedback, and review progress. Give the operating leader responsibility for the capability, with support from learning specialists and experienced practitioners. If all freed capacity is committed to higher volume, the proposal needs a credible explanation of when development will happen.
Specify evidence of progress. Assess whether people can investigate unfamiliar situations, use relevant evidence, recognize their limits, and make appropriate escalations. Track the quality and cost of the work alongside those observations. Course completion and tool usage alone will not answer whether people are becoming capable of the responsibilities you intend to give them.
The purpose is to make the developmental consequences of the investment visible. It does not require a precise financial value for every learning outcome. Record uncertain costs and benefits as assumptions, then use the pilot to improve the estimate.
Make the Tradeoff Honestly
The strongest objection is practical: managers are busy, development takes time, and an automation project should not become responsible for solving the entire talent system. That’s fair. Scale the response to the capability at stake. A minor formatting change may need no additional development plan. A redesign that removes much of an employee's exposure to customer diagnosis deserves closer examination.
For the proposal team, a limited pilot could reserve a small, explicit amount of experienced staff time for case review. Compare delivery quality, total effort, and evidence of learning with the prior arrangement. If the new approach consumes more time than expected or employees can’t apply what they learned, revise it before expanding.
External hiring is another legitimate option. Leaders may decide that acquiring a particular capability is preferable to developing it internally. But the business case should examine availability, integration time, and how new hires will learn the company's context. A plan to hire expertise later is still a workforce strategy that needs testing. Nor should leaders imply that development guarantees a promotion or preserves every role. Explain which responsibilities are expected to grow, what opportunities actually exist, and what remains uncertain. Employees need honest choices, not an abstract instruction to “become more strategic.”
Add One Requirement to the Next Pilot
The practical starting point is one meaningful workflow. Define what the agent may do, which decisions require approval, how the result will be checked, and how errors can be corrected. Then add a human-development requirement: identify one capability people should gain through the redesigned work, and the experience intended to build it. Assign someone to review both results. Did the workflow perform better? Did employees become better prepared for the responsibilities the design gives them? The answers may differ. Treat that difference as information for the next decision.
The evidence doesn’t yet tell us how to solve the apprenticeship problem across professions. It gives us reasons to investigate the changing work more carefully. My recommendation is to make that investigation part of the investment itself, with resources and accountability attached.
When you approve the next AI business case, ask who will own the development of the capability the company will need afterward, and where that work appears in the plan.
