Leadership with AI

Twenty decisions logged over four weeks, each with a probability attached, then scored against what actually happened. The cheapest instrument that exists for finding out whether your judgement is any good.

1. Fix the template. Date, the decision, options considered, what you expect to happen, confidence as a percentage, what would prove you wrong, and the date you will check. Seven fields, one screen.
2. Log the ordinary ones too. Hiring, prioritisation, an architecture call, whether to escalate. Twenty in four weeks is roughly one a day, not just the dramatic ones.
3. Commit a number every time. "Likely" is unfalsifiable; 70% is not. Force the percentage even when it feels arbitrary — especially then.
4. Record the conditions. Time pressure, who was in the room, what you did not know. The patterns in your misses usually live here rather than in the reasoning.
5. Score at four weeks. Bucket predictions by confidence — the 60s, 70s, 80s, 90s — and check how often each bucket was right. A Brier score if you want one number for it.
6. Name one bias with evidence. Overconfident about your own team's delivery, anchored on the first estimate, over-weighting the loudest voice. One pattern, two examples, one change you will make.

Scope guard: the scored review is the project. A journal without it is a diary and teaches nothing.

One weekly process your team actually runs — measured, redesigned around what models are genuinely good at, then measured again, including what got worse.

1. Map it as it really is. Every step, who does it, how long it takes, what triggers rework. Time it by observation rather than by asking; the gap between the two is usually around 40%.
2. Baseline two numbers. End-to-end cycle time and the error or rework rate, over at least three runs, before you change anything. Without a baseline there is no result later.
3. Classify every step. Judgement, retrieval, transformation or coordination. Retrieval and transformation are where models help; judgement and accountability are what you keep.
4. Redesign the flow, not the steps. If drafting drops from an hour to five minutes, review becomes the bottleneck. Say what the new bottleneck will be before you run it, then check whether you were right.
5. Run it for three weeks. Same two measurements, same method, same people. Keep the old path available so nobody is stranded when it fails.
6. Report the costs honestly. Review burden, quality variance, the person whose job got duller, and the failure mode you did not see coming. Something always gets worse, and a report with no cost section is not believed.

Scope guard: one workflow, two metrics, three weeks. Four processes redesigned at once produces four unmeasurable changes.

Your team's actual one-page standard for AI-assisted work — written, argued about with the people it governs, and revised in front of them.

1. Sort the work into three bins. Assistance unrestricted, assistance requiring disclosure, assistance requiring a named human check before it leaves the team. Fill each with your team's real artefacts: commits, customer emails, designs, analyses, hiring notes.
2. Define "checked" per bin. Read for plausibility, verified against a source, or reproduced independently. Three different standards — say which applies where.
3. Fix accountability in one sentence. Whoever ships it owns it, whatever produced it. Everything else in the document follows from that.
4. Say what is off limits. Data that may not leave, and decisions that may not be delegated — performance reviews, hiring rejections, incident cause statements — plus any disclosure that is legally required.
5. Take it to the team. One session, three genuinely ambiguous cases drawn from your own recent work. Record every disagreement instead of resolving it in the room.
6. Revise in public. Publish v2 with a short changelog naming what changed and whose objection changed it. That changelog is what makes people follow the standard.

Scope guard: one page, no tool names, no exceptions process longer than the standard. A policy written alone is a policy nobody follows.

A twelve-month plan you would put your name on: sequenced workflows, honest costs, outcome measures, and a written condition under which you stop.

1. Sequence on evidence, not enthusiasm. Three or four workflows in order, chosen on volume, measurability and reversibility. State why the first is first.
2. Cost it fully. Licences and inference, plus what people leave out: training hours, review time, integration engineering, and the productivity dip in the first six weeks.
3. Measure outcomes, not usage. Seats filled and prompts sent tell you nothing. Cycle time, error rate, cost per unit of work and customer-visible quality do.
4. Plan the capability. Who is trained on what by when, and who reviews whose output. Adoption fails on review capacity far more often than on technology.
5. Own the risks by name. Data exposure, quality regression, vendor dependence, skill atrophy in juniors. Each gets a named owner and a specific control, not a paragraph of concern.
6. Write the stopping condition. The number and the date at which you halt or reverse. A plan with no way to fail runs for two years regardless of results.

Scope guard: three or four workflows, not a transformation programme. Every quarter carries one measurable decision point.