What to teach each role about AI, from the board to the front line.

The company-wide AI course was a success on paper. Nearly everyone finished it, passed the quiz and collected a badge. A quarter later, the finance team still built the month-end pack by hand, and no manager had asked for anything the tool produced.

One course for everyone teaches that the tool exists. It can’t teach when the tool helps in a particular job, where it fails on that job’s cases, or what each person is now expected to do differently. Those answers differ by role, so the curriculum should too: leaders, managers, the people whose work is changing, and the people who build and run the systems.

Why does one course for everyone fall flat?

To fit everyone, it has to be generic, and generic examples don’t transfer. An accounts payable specialist learns nothing about invoices from a demo that writes a marketing email. It also treats every role as a user, when a manager’s real job is to change a routine and a leader’s is to decide where AI should and shouldn’t go.

The template has six columns: role, goals, topics, format, practice task and measure of success. Here it is in two tables.

What do leaders need to learn?

Judgment, not tool tips. Leaders need enough hands-on use on their own material to calibrate: where the output impresses and where it is confidently wrong. Then they need the questions that decide whether a use case is worth doing. Is it frequent and bounded? Is the data reachable? Who owns it? What does a finished task cost, review included, and what does a mistake cost?

When leaders skip their session and send their teams instead, managers learn the tool but not the priority, and the new output never reaches the leadership meeting.

What do managers need to learn?

Managers decide whether the new output becomes routine or stays optional, which is the heart of a new everyday practice. They learn the redesigned workflow in detail and what a real review looks like: a reviewer who approves everything in seconds isn’t reviewing. They learn to read use and results together, and to answer the questions their teams will ask them first. Will this replace me? Who checks it? What data does it see?

Their practice task is the most practical of all: run one real team meeting built around the new output.

What do people whose work is changing need?

Most of the training time belongs here, and almost none of it should be slides. Small groups work through their own recent cases with the new tool in front of them, awkward ones included: the invoice with a handwritten correction, the complaint that mixes two orders, the supplier email that switches from Turkish to English halfway through. Train in the language the team actually works in: Turkish, English or both.

People learn four things by doing them: how the tool fits their steps, how to check its output against the source, when to override it and how to record why, and when to hand a case on. Prompting skills help where people write their own requests, but checking habits matter more.

Time it well. Train people when their new workflow is ready, not months ahead; skills practiced on a tool you can’t use yet fade fast.

What do builders and IT need?

Builders need what ordinary software work doesn’t teach: evaluation sets from real cases, output that varies between runs, retrieval and permissions, review design, monitoring and prompt-injection defenses. IT needs the operational side: identity and access, data flows and processing locations, logging, vendor terms and cost controls.

Courses give vocabulary; pairing on a real workflow gives judgment. The note on what software engineers need to learn goes further.

How do you sequence and measure it?

Sequence by dependency. Leaders go first, because their priorities set what managers ask for. The teams whose work is changing come next, with their managers, just before the workflow changes. Builders train alongside the first build. Wider AI literacy for everyone else follows, once there are real internal examples to learn from.

Measure changed behavior in the workflow, not course completion: the new output in the routine meeting, time per case and rework against the baseline, override reasons recorded and read, AI use moving into approved tools.

A completion rate tells you who attended, not what changed.

Here is an illustrative example, the curriculum for a finance function:

1. Leadership working session. The finance director and the heads of controlling, accounts payable and treasury work on their own month-end material, choose supplier invoice processing as the first workflow, name the accounts payable lead as its owner and agree the baseline.
2. Managers. The accounts payable and controlling managers learn the review step and rebuild their weekly meeting around the exception list the system produces.
3. The accounts payable team. Small cohorts practice on their own recent invoices, credit notes and corrections included, checking supplier, amount and purchase order before approving each draft, and recording why they changed one.
4. Builders and IT. A finance systems analyst pairs with the engineers on the evaluation set.
5. Everyone else in finance. A short literacy session and the one-page guide.

Success shows up in the accounts payable queue, not in a training report. The illustrative finance AI champions engagement has the same shape: sessions built on real finance tasks and a weekly routine managers ask for.

Measures before sessions

Fill in the two tables for one function, starting with the leaders’ row, and write each measure of success before designing a single session. If you want a partner for the sessions, AI enablement runs role-specific training on real tasks, in Turkish and English.