The Role Change Check

Use this before a tool takes over the tasks of a role, whether you are reducing the role or only handing it a few tasks. Nobody has written down what a role does beyond its task list, and memory is a poor source. So the check starts from evidence: the role’s own records, read by an AI, give you a ledger of what the person actually does. The ledger feeds a one-page decision record that you sign before anything changes and reopen at six and twelve weeks.

Step 1: Gather the records

Pull four to eight weeks of what the role leaves behind: sent email, chat threads, meeting notes, tracker comments, and the status packs they produced. You do not need all of it. Two weeks of real traces beats an afternoon of recall.

Step 2: Have an AI draft the ledger

I'm reviewing the role of [role]. Below are four to eight weeks of their emails, chat messages, meeting notes and tracker comments.

List everything this person did that a task list would not record. For each item give:
- Function: sensing (picking up what never enters a system), aligning (keeping teams and sponsors reading the work the same way) or resolving (settling things between teams)
- Evidence: one example from the records, with its date
- Who relied on it: the people or teams who benefited
- Confidence: "clear in the records" or "inferred, confirm with the role holder"

Rules:
- Use only what is in the records. Do not invent functions.
- If a category has no evidence, write NONE FOUND.
- Do not recommend whether to keep or remove the role.
- Leave names out of your answer and use role titles.

Records: [paste them here]

Before you paste records about a real person into a third-party AI tool, check your organisation’s policy on personal and commercially sensitive information. Strip names and figures first if you are unsure.

Step 3: Check the ledger with people

Take the draft to the role holder and to two people who rely on them. Every “inferred” line is a question for them, and they will add things the records missed. Then fill in the last column yourself:

Function: [one line]
Evidence: [example and date]
Who relies on it: [people or teams]
After the change: [a named person with stated hours, a tool with a named reviewer, or UNOWNED]
How well: [fully / partly / not at all]

Any row marked UNOWNED, or covered “not at all”, is a gap to close before the change goes ahead. A role with NONE FOUND across the board is a role that is mostly tasks, and it clears quickly.

Step 4: Set a baseline

Choose three or four things that would show a lost function early, and write down today’s value with the date. Pick them from the ledger, one per function that matters. Examples: days between a problem starting and it being raised; how often a sponsor contacts the team unprompted; the number of issues found late; disagreements between teams with no recorded decision. A reading means little alone, so the comparison is the same project before the change.

Step 5: Sign the decision record

One page, written before the change and before you see any results.

Role and change proposed: [what is being reduced, automated or moved]
Date and decision owner: [name, date]
Functions at risk: [from the ledger, with how well each is covered after]
Gaps to close first: [every UNOWNED or "not at all" row, with who closes it and by when]
Baseline (dated): [the three or four readings from Step 4]
Re-measure at: [6 weeks and 12 weeks]
Proceed if: [for example, no function UNOWNED and no reading worse than baseline at 6 weeks]
Pause or reverse if: [for example, two or more readings worse than baseline]
If we are wrong: [how long before we would notice, and what it costs to rebuild]
Would change my mind: [one finding that would make me proceed, one that would make me pause]

Setting the rule first matters. Otherwise the readings get interpreted to fit the decision already wanted. The thresholds above are starting points; set your own.

Worked examples

A programme coordinator team, cut of 20% proposed

Four coordinators build the weekly status pack, chase actions and route approvals. The details are illustrative.

Ledger (from six weeks of records)
Sensing: hears from delivery leads that Team B's test environment is unreliable, well before there is a ticket. Evidence: chat, 3 Sep. Relied on by: the programme manager. After: UNOWNED.
Aligning: rewrites the sponsor's priorities in plain language for each team in the pack's opening paragraph. Evidence: pack, 10 Sep. Relied on by: three teams. After: UNOWNED, since the pack is automated and the rewrite goes with it.
Resolving: brokers scheduling clashes between two shared teams and records the outcome in the RAID log. Evidence: email, 17 Sep. Relied on by: both teams. After: the programme manager, partly, about 2 more days a month.

Baseline (week 0)
Two teams named the same unticketed workaround. Two people on one team gave different reasons for their work. Two clashes in the last month, one recorded.

Decision record
Change: automate the pack and chasing now; hold the 20% cut.
Gaps to close first: move two coordinators' freed hours onto sensing and aligning.
Proceed with the cut if: both functions have an owner and no reading is worse than baseline at 6 weeks.
Pause if: two or more readings are worse at 6 weeks.

A monthly portfolio report compiler

One analyst spends three days a month compiling the portfolio report from team submissions. The figures are illustrative.

Ledger: collects submissions, reconciles figures, produces the report. Sensing, Aligning, Resolving: NONE FOUND.
After the change: an AI draft reviewed by the portfolio manager, about 30 minutes a month.
Decision record: proceed. Check the first two reports against the submissions. Redeploy the analyst's three days.

The first role holds functions nobody had written down, and the ledger found them before anything changed. The second clears in minutes.

Notes

The records are the point. A job description lists tasks and a role holder describes what they remember. The ledger shows what happened.

Name the successor. A successor is a named person with stated hours, or a tool with a named reviewer. AI moves work into review and exception handling, so count that time.

Keep the evidence. If the decision is questioned later, the ledger and the dated baseline are the defence.

When it does not apply

• It informs a business case. Any formal consultation or legal and HR process a restructure requires still applies.
• It is a diagnostic from a few weeks of records, so it gives evidence for a decision, and the proof comes from watching delivery.
• A team small enough that everyone talks daily will find the answers without it.
• If nothing would change a decision already made, skip it.
• Rebuild the ledger at each review. A function covered “not at all” this quarter may be partly covered by the next set of tools.

What this feeds

It feeds the AI-native project manager piece: once AI takes the admin, the freed hours go onto the functions this page marks UNOWNED.