How to Train Managers to Redesign Work with AI

An AI training programme for managers needs to end with a change they can make in their team's work. Give each manager a real process to examine, examples to judge, and a bounded experiment to lead. Then check what changed after they return to the team.

Define the management task the training will change

Choose an observable capability. A manager might need to identify where a team gathers context, distinguish a correct draft from a plausible answer, or assign reviewers to a new queue. Describe what they will demonstrate at the end of the programme and what they will do differently at work.

A learning-and-development discussion about AI readiness for managers asks how to show a financial benefit and change daily behaviour after tool training. It provides a concrete reader question, rather than verified evidence of a company's results. Your programme needs its own starting measures and follow-up evidence.

Keep introductory tool skills short and relevant to the chosen task. Managers need to know how to use the approved tool and its data boundaries. They also need to know who accepts an output, how exceptions move through the process, and what staff can stop doing after the change.

Agree the manager's authority before the workshop. Can they change a local handoff, allocate review time, or run a draft-only pilot? Which changes need a process owner, security review, or another department? Training won't remove an approval obstacle the manager has no authority to resolve.

Bring completed work and exceptions into the room

Ask each manager to bring a narrow recurring workflow and a sample of completed cases. Include ordinary work and cases that needed clarification, correction, or escalation. Use redacted or synthetic examples where the training environment doesn't have permission to process the real records.

Capture the starting position: volume, time spent on each step, waiting time, corrections, and the accepted result. Record who performs the work and which systems they open. A team member who does the task should help prepare the map; a manager's process diagram may omit a workaround that staff use every day.

For an illustrative support workflow, the team receives a request, finds the customer account, checks the approved policy, drafts a reply, reviews it, and sends it. Include cases with an ambiguous account or a policy exception. The AI opportunity may sit in gathering and drafting, while the customer commitment still needs an authorised decision.

Write the required result in plain language. “Respond faster” leaves quality undefined. “Prepare a reply using the current account record and approved policy, with unresolved questions flagged for the reviewer” gives the group something it can test. Keep the starting map and measures for the follow-up comparison.

Run a two-hour workflow workshop

The following agenda is a proposed format, not a tested guarantee of productivity. Keep the group small enough that each manager explains their map and gets feedback. Have a facilitator, a process specialist, and access to technical advice for questions that affect implementation.

Use the same sample cases when comparing the existing and proposed process. Record the time to an acceptable result, including checking and correction. Keep the facilitator from repairing every answer for the manager; the manager needs to demonstrate that they recognise the problem and route it correctly.

End with a short decision record. State the eligible cases, the proposed assistance, the work it replaces, the remaining review, and the approvals needed before a pilot. If the group finds missing data or unclear rules, assign their repair instead of inventing an AI experiment to fill the agenda.

Teach managers to judge the output

Have managers assess an answer before they see the model's explanation of it. Ask them to check the source facts, required fields, and proposed action. A convincing explanation doesn't establish that a customer policy or calculation is correct.

Francesco Dell'Acqua and colleagues' 2026 paper on AI and knowledge-worker performance reports a randomised experiment with 758 BCG consultants. AI improved performance on tasks within the tested capability boundary and reduced correctness on a task outside it. The experiment used the April 2023 version of GPT-4; its results don't establish the performance of today's models on your workflow.

Use that task-dependent result as a reason to evaluate the actual work. Include a polished answer that gets an important fact wrong and a case that needs escalation. Ask the manager to explain the evidence required for acceptance, then compare their judgement with the process specialist's review.

Distinguish missing source facts from poor instructions. If the account has no confirmed delivery date, a more elaborate prompt doesn't create it. The manager should flag the missing record and assign a business action. Test whether they can recognise when the assistant should leave a question unanswered.

Teach review with the controls the team will use in production. Show source references, the original request, and the relevant rule beside the draft. Define what the reviewer can approve and what needs another authority. Record serious errors separately from a general quality score.

Redesign the handoffs and approval steps

Draw the proposed process after reviewing the samples. For each assisted step, decide which old activity it replaces and what new work it adds. An AI draft that staff re-enter into another system may save writing time while leaving the main obstacle untouched.

In the support example, an assistant can prepare account context and a reply for a reviewer. The redesigned handoff must show where that draft appears, who checks it, and how they approve or return it. If staff must keep creating a second manual draft, the process still has duplicate work.

Keep reviews that protect a required decision. Before removing a check, identify its purpose and confirm who can approve the change. A faster extraction step doesn't justify removing an authorisation limit. The manager needs to understand the control before redesigning the surrounding work.

Plan the exception route in the same detail as the ordinary route. Name the person who handles a missing account, disputed policy, or rejected output. Agree what happens when the reviewer is absent or the tool is unavailable. An unanswered exception queue can become the new source of delay.

Use the workflow ownership guide to assign business and technical owners for the pilot. Managers should leave the workshop knowing which decisions they own and whom to contact when a system repair is needed.

Set clear expectations with the team

Before the pilot, explain which cases qualify, what staff will do differently, and what still needs human judgement. Show a completed example and an exception. Give staff a route to report a bad result without counting every rejected output as a failure to adopt the tool.

Protect learning and review time in the team's schedule. The manager needs to account for the new tasks rather than adding them to an unchanged workload. Agree how staff record corrections and keep that capture step brief enough to complete during ordinary work.

Be direct about workforce questions. State what leadership has decided and what is still undecided. Don't promise that roles can never change if the company hasn't made that commitment. The manager can explain the pilot's current scope and how staff feedback will affect the next decision.

Avoid rewarding prompt volume or penalising someone for using the manual fallback correctly. Review completed outcomes, quality, and whether staff followed the agreed boundaries. A manager who catches a dangerous draft has demonstrated part of the capability the programme intends to build.

For a PE-backed business, agree whether any measured capacity will reduce a queue, avoid hiring, or support another task. For a startup, include maintenance and review work in the delivery plan. A corporate team also needs a way to coordinate handoffs across departments that have different managers.

Coach the manager through the first month

Within the first week, check that the manager has met the team, obtained the required approvals, and confirmed the baseline. Start only the bounded pilot the owners accepted. A workshop exercise doesn't authorise production access or customer communication.

During the next two weeks, hold short reviews of actual cases. Ask the manager to bring an accepted result, a correction, and an unresolved exception where those exist. Examine the cause and the next action, rather than filling the meeting with screenshots of tool use.

Distinguish a coaching need from a system obstacle. A manager who can't explain the acceptance criteria needs practice and feedback. A missing connector or source record needs an assigned technical or business repair. More training won't fix that dependency.

At the end of the month, compare the current process with the starting map. Check whether the promised duplicate work disappeared, whether review is still manageable, and whether staff know the exception route. Include work the team abandoned or returned to the old process.

Decide whether to continue, revise, or stop the experiment. Document the evidence and the owner of each repair. If the sample is too small or the workload changed substantially, extend the comparison with a stated reason; don't declare a financial result from incomplete coverage.

Measure management capability and completed work

Assess the manager with a comparable task before and after the programme. Ask them to map a workflow, identify a flawed output, and assign an exception to the correct decision maker. Use a stated rubric and a process specialist's review so confidence alone doesn't determine the result.

Measure workplace transfer separately. Check whether the manager changed an approved handoff, coached the reviewer, and acted on a reported failure. Record the implementation obstacles too. A manager may demonstrate the required judgement while waiting for another team's access approval.

For operating results, count eligible work and accepted assisted work, then include review and additional support in the time comparison. Consider an illustrative four-week period with 250 requests: 200 qualify, 160 complete through the assisted process, and 40 fall back. The other 50 don't qualify.

If each of the 160 assisted requests saves three minutes after normal review, the saving is eight hours. If extra troubleshooting takes 45 minutes each week, it consumes three hours over the four weeks, leaving five hours of net capacity. This calculation assumes no saving on fallback or excluded cases and keeps initial training and setup effort separate.

Five hours of capacity isn't automatically a cash saving. Decide how the team uses it and check the financial effect using the time-to-cash guide. Use the baseline method for a fair comparison and state any changes in demand or quality.

A programme is ready to expand when managers can demonstrate the judgement, lead the approved process change, and explain the measured result with its limits. If the only evidence is attendance or enthusiasm, inspect the workplace handoff before buying another course. The next training investment should address the capability the manager still needs.