Seven people spent a day practising AI adoption judgement. Some of the signals were genuinely encouraging. The day was also chaotic, overloaded and, at one point, had me quietly convinced it was falling apart. I've come to think those two outcomes are more connected than they first appear, and both have changed what I'm building next.
At the end of my last post I promised to write up the first Make AI Adoption Safe workshop properly. I've been slightly putting it off, mostly because the honest version is more complicated than either of the two stories I could easily tell about it.
The first story is that it worked. Seven people at the South Coast User Group spent Thursday 22 October practising how to make judgements about AI use cases, and by the end of the day there was some evidence that they could use the approach without me. The second story is that it was too much. There was too much paper, too many steps, too many terms, and a timetable that started drifting before lunch and never quite recovered.
Both stories are true. What I didn't appreciate until I sat down with my notes from the day is how much they explain each other.
The pile: a small part of what I printed for one six-hour day. Somewhere in here was a clue I didn't spot in time.
This is some of what I printed. Cards, forms, records, reference sheets, envelopes to be dealt out at particular moments, and A1 maps for the teams to build their judgement on. Every piece had a reason to exist. Looking at it now, I think the pile is the first piece of evidence in this story, and I probably should have read it before anyone else did.
What I was actually testing
The workshop wasn't designed as a training course. It was designed as an experiment, and its hypothesis was written down before anyone arrived. The hypothesis is Tim Hourigan's [CHECK: match the credit wording in your LinkedIn post], and it has stayed with me ever since:
"If AI increasingly provides the answer, developing expertise requires deliberately creating the experiences through which people learn to question, interpret and exercise judgement before they see the answer."
That sentence shaped almost every design decision. If judgement develops through the experience of making calls under uncertainty, then handing people a model at the start and asking them to apply it risks skipping the part that matters. So nobody got the answer first. People met an ambiguous situation, made a judgement about it, and only then received the structure that might help them make a better one. After that they practised it, had it challenged, had the circumstances changed underneath them and, right at the end, tried it on something they had never seen.
I've been calling that struggle-first. The idea is that the struggle creates a genuine need for the model, so when the model arrives it lands as an answer to a question people are already asking rather than as content to memorise. I still believe in that. The day taught me something important about where it breaks.
The hypothesis: written down before anyone arrived, so the day could argue with it.
The shape of the day, on paper
The day was built as six movements, each with its own job. Private first, then teams, then the record handed to strangers, and finally back to each person on their own.
The method on paper: from a private first call to an unfamiliar case worked alone.
1. 10:00 Commit. A first judgement on a real case, made alone and privately.
2. 11:15 Frame. Teams work their own case, asking for evidence only when they decide they need it.
3. 12:00 Operate. Make one control actually work when an event lands.
4. 13:25 Prove. Hand your record to the other team, who rebuild your decision cold.
5. 13:57 Adapt. The circumstances change, and the judgement has to change with them.
6. 15:15 Transfer. A case nobody has seen, worked alone.
On paper, that looks quite tidy.
At 10:00, we disagreed
The first thing everyone did was read the same short case and make a private call on it: Go, Pause or Stop. Nobody discussed it first. The split was four Go and three Pause [CHECK: confirm the count came from the cards people held up].
Same case, seven people, no shared language yet. Nobody is allowed to say "it depends" yet. 🙂
It would be easy to read that as seven people getting it wrong in different directions, and I don't think that's what it shows. Seven sensible people, most of whom hadn't met before, looked at the same situation without a shared way of describing it and reached different conclusions. That is roughly what happens inside organisations every day, except that there it usually happens in separate meetings and nobody ever sees the split.
Committing privately before any discussion mattered more than I expected. It kept the disagreement honest. Had the first call been made out loud around a table, I suspect the room would have drifted towards whoever spoke first, and we'd have lost the most interesting data point of the morning.
What appeared to work
The clearest signal came after lunch. Each team had spent the morning building a record of its judgement on a large map: what the case was, what evidence they had asked for, how they had sized the risk, which control they had chosen and how it held up when an event was dealt in. The teams then swapped maps, and each had to rebuild the other team's decision from the record alone, without the authors there to explain it.
Both teams did. They read the other map cold, questioned it sensibly and started evaluating a case they hadn't worked on. There's a detail here that I find more convincing than the tidy version. The written briefs meant to support this step arrived well after the swap, partly because in the general muddle I offered the wrong envelopes twice before finding the right ones. For a while the teams had only the map to go on, which turned out to be a harder test than the one I had designed. My note at the time just said "reusable capability".
The Living Judgement Map before anyone touched it: by mid-afternoon, this was the record that had to survive its authors leaving the room.
That matters well beyond a workshop. Most governance evidence is written by the people who made the decision and read by people who were in the room when it was made. The more useful test is whether it survives the people who created it leaving. Could somebody else understand what you decided, why you decided it, and what would make you change your mind?
The second signal came at the end. Everyone received a case they had never seen, sealed until that moment, and worked it alone before comparing notes with a partner. All seven used the same underlying approach to do it [CHECK: confirm all seven completed it]. I'm wary of making too much of this. It was the end of a long day and the approach was fresh in everyone's mind. Even so, they were no longer following me or their team, and that was the thing I most wanted to see.
The third thing is harder to measure. The day moved between individual, pair, team and whole-group work, and the room itself became part of the mechanism. People who mostly hadn't met before challenged each other's reasoning in ways that one person working through the material alone simply couldn't. One participant posted that evening, unprompted, describing the route and the Risk Spine accurately in his own words [CHECK: link only, or ask Asim before naming or quoting].
Then the wheels started wobbling
I kept a running log during the day, sending myself short messages as things happened, and reading it back is a slightly uncomfortable experience. At 11:30 I wrote that the teams were filling in the map and it was going well. By 11:44 the time was drifting and I was having to prod. At 11:51 I wrote that it felt like it was falling apart.
It wasn't, quite, although the drift was real. Framing the case was meant to take six minutes and took about twenty, partly because a map with six neat cells invites people to fill every one of them properly. That ate the window for asking for evidence, so one team wrote its first judgement and then asked for evidence, which is the right instinct in the wrong order. Both teams reached new steps at the same moment, so a short explanation I'd planned to give the whole room became the same explanation given twice, table by table. When we reached controls, the teams were trying to solve everything at once. Then I discovered the venue served lunch at one o'clock, which my plan hadn't known about.
By lunch we were nearly half an hour behind. On one step in the afternoon we were well over an hour behind, and the day only finished near its scheduled time because I cut three things completely: a segment on recognising where your own authority ends, a second round of the exercise where circumstances change, and a constraint designed to squeeze the teams' controls.
The drift, step by step: how far behind plan each part of the day started, and the three things that fell off the end.
Some of the overload was mine rather than the participants'. My envelopes were labelled with the clock time they were due to be dealt, which is helpful right up until the clock stops matching the room. My cues used codes I had to look up while facilitating. Offering the wrong envelopes twice wasn't a design flaw so much as a sign that I was carrying too much of the design in my head.
The feedback said what I already suspected: "a bit too paper-heavy and too many steps", "simplify", and my favourite, "a bit of teaching would be nice".
Fair.
"A bit of teaching would be nice"
That comment has stayed with me longer than any other, partly because it's so politely understated and partly because it points at the most interesting thing I learned.
The design rested on creating the need before teaching the model. I'd assumed the hard part would be resisting the urge to explain too early. What I hadn't thought through properly was the other end: what happens after the struggle, when people need help turning what they've just experienced into something they can use again. Creating the need for a model is not the same as leaving people to make sense of the struggle alone.
Reading the record back, I noticed something I hadn't expected. The plan did include teaching. There were short explanations for the whole room of the Risk Spine and of how to think about controls, placed just after the moments where teams would need them. Most of them never happened as planned. As the timetable drifted they were the first thing to go, replaced by me crouching at each table explaining the same idea twice. So the participants were right that there wasn't enough teaching, although the reason isn't quite the one I first assumed.
I think the lesson is that in a struggle-first design, consolidation is the most fragile part. The struggle protects itself, since people are in the middle of it and you can't easily skip it. The moments of making sense of it look optional under time pressure, and yet they are exactly where struggle turns into capability. If they aren't deliberately protected, they're the first thing a drifting day removes.
There was also a second kind of struggle in the room that wasn't productive at all. Some of the difficulty was the judgement itself, which is the whole point. Some of it was working out which sheet to use, why the numbering on the big map didn't match the smaller cards, and whether a term on one page meant the same as a similar term on another. That isn't productive difficulty. It's friction, and it competes for exactly the attention the real thinking needs.
I still believe in struggle-first. I'm less convinced by struggle-mostly. 🙂
The struggle creates the question. Teaching helps turn the answer into capability.
What the chaos may have revealed
There's an odd paradox in all this. Three planned parts of the day were cut completely, several others were compressed, and the people in the room still showed the signals I most hoped to see: a record another team could rebuild, and an unseen case worked through with the same approach.
One reading is that I got lucky. Another, which I find more interesting, is that some of what I built simply wasn't carrying enough weight. When I designed J01 I wrote down a principle that if a component doesn't build or evidence capability, it should go. It's much easier to apply that principle to somebody else's design than to your own, and it took a chaotic Thursday for me to apply it to mine.
The formal Journey with the day's lessons written over it: some of the mechanism held, some of what I'd built was in its way.
I need to be careful here. The parts I cut might matter a great deal over a longer period or in a different room, and one day can't tell me that. The final case was also shortened to fit, so the most encouraging signal came from a compressed version of the exercise. It does raise a useful question for the next run, though. With the time freed up, does a one-day workshop really need everything I designed for it, or was I trying to fit something longer into a single day?
The chaos may have accidentally helped identify what wasn't carrying its weight.
What this does not prove
Before going any further, it's worth being plain about the limits. Seven people took part, all of whom chose to be there. There was no control group. The morning and afternoon cases were different, so I can't compare the first judgement with the last in any rigorous way. Feedback came on named cards at the end of a long and sociable day, which tends to lean positive, and at least one participant is somebody I already knew. Nothing here establishes cause, and one workshop doesn't validate J01, Empower Your World or the wider Frontier Capability Organisation thinking.
These are signals, not proof.
The question I most want answered is whether anything survived Thursday. Each person left with a seven-day action [CHECK: were these filled in?], and I've only just written to the group with the revised materials and an invitation to check in. The first real test comes about a month after the day. I don't know the answer yet, and I'd rather say so than imply otherwise.
What changed in V2
The revisions fall into three groups: things to have less of, things to have more of, and things I deliberately protected.
Less covers most of the feedback. There are fewer terms and fewer overlapping models, much less paper, fewer steps and less for the facilitator to carry around in his head. The map now follows the Risk Spine directly, and much of what used to be separate forms has been folded onto it, with a single workbook for the day alongside [CHECK against the current release].
More is about making sense of things and finding your way. There's more deliberate teaching at the points where people need to consolidate what they've just done, consistent language across every piece, clearer signposting of where you are in the day, and clearer distinctions between the models that remain.
Protected is the part I care about most. The private first judgement stays, along with visible dissent, team reasoning, operating a real control, the cold reconstruction, changing circumstances and the final unseen case worked alone. So does the uncertainty. None of those were the problem.
Simpler doesn't mean easier.
V2 isn't designed to make the thinking easier. It's designed to make the unnecessary parts less hard.
The workshop is only one way into J01. Make AI Adoption Safe is a single Journey offered in four packages, and each takes the same ideas to a different depth. PUBLIC is free and open to anyone, and it's about seeing and understanding the problem: a shared language, the Risk Spine and the questions worth taking into your own conversations. REGISTERED takes that into a more personal exploration of what it means for you and your context. SELF is for practising on your own, working through structured scenarios to build your judgement deliberately over time. WORKSHOP is practising it together, with a group working through it in a facilitated day.
All four have changed since the pilot, since some of the learning wasn't really about facilitation at all. It was about how much structure people need, when they need it, and how you help somebody move from information to judgement.
The next experiment
I started the day wanting to find out whether deliberately created experience could help people build better AI adoption judgement. I finished it with some encouraging signals, a pile of things I wanted to change, and rather more respect for how hard it is to design an experience that develops capability without overwhelming the people it's meant to help.
That's a useful result.
Now I need to run it again, not to prove the first workshop was right, but to give reality another chance to tell me where it's wrong.
If building AI adoption judgement in a team sounds like a problem you're wrestling with, I'm looking for the next places to test this. If you'd be interested in being part of one of the next experiments, I'd love to hear from you.
Explore and participate
Explore Make AI Adoption Safe: the free, public set of materials
Next Experiments: let me know if, and where, you'd like to explore this further
