Stop piloting. Change one process end to end.
Pilots don't die for technical reasons. They die because putting one into production means someone's job changes, and nobody wants to be the person who said that out loud. We start there.
Book a callSounds familiar
Twelve pilots ran last year. Two are in production, and nobody agrees which two.
Half the team uses it already and won't say so, because we never said they could.
We bought the licences. The process is exactly the same as it was.
What's actually going on
AI rarely fails on capability now. It fails on the sentence nobody says in the steering meeting: if this works, this role gets smaller. So pilots get funded generously and production gets postponed indefinitely. The pilot is the safe place — it doesn't require anyone to give anything up.
The other half is quieter. People are already using it, unofficially, with no agreement about what's allowed, what gets checked, and who carries it when it's wrong. That isn't a tooling gap. It's a permission gap.
What we do
Find the two or three places where automation holds up
Put one into production before anyone designs a programme
Say whose work changes, and what they get instead
Write the rules for what's allowed, what's checked, who signs
Reshape the roles around what the tools now do
What this isn't
No AI strategy deck. No innovation lab.
No tool rollout without a changed process.
In your organisation
The permission question is org design. Who may decide an AI output is good enough to send, and who carries it when it isn't — that's decision rights, not prompting.
What you end up holding
Automation only where it holds up in production
Roles reshaped around what AI now does
Rules for what's allowed and who checks
Related
Who you'd work on this with
Robert Vogt
Reads why the tools a company bought never moved anyone. The answer is rarely the tool.
robert@unmade.ch
Jeremy Zahner
Works out what a team can safely settle for itself once a machine writes the first draft.
jeremy@unmade.ch