Things I keep learning the hard way.

I’ve sat in enough AI demos to know the pattern. Someone shows a slick prototype. People lean in. Then someone asks, quietly: where does this data come from — and who owns it when it’s wrong?

That’s usually when the room cools down.

Getting a model to summarise or draft something is getting easier. What stays hard is the environment you drop it into: fuzzy workflows, unclear ownership, three definitions of the same metric, a process nobody can fully explain.

In those conditions AI doesn’t clean things up. It scales the confusion. Confident answers land on shaky foundations, and people either over-trust them or quietly go back to the spreadsheet.

So when a team asks if they’re “ready for AI,” I don’t start with model choice. I start with boring questions:

• Can we agree what “good” looks like for this decision?
• Who is accountable when the output is wrong?
• Is the data stable enough that yesterday’s answer still means something today?

If those answers are soft, it’s not really an AI project yet. It’s a clarity project wearing a tech costume. Clarity work is slower and less glamorous. It’s also usually where the value is.

When a program slips, the first instinct is often more process. Another status pack. Another forum. Sometimes that helps. Often it just gives the same misunderstanding more places to hide.

What I see more often isn’t a shortage of process. It’s a shortage of shared assumptions.

Business wants speed. Risk wants control. Engineering wants a clean design. Data wants definitions that hold. All reasonable. Not automatically compatible. If nobody makes the trade-offs explicit, each team optimises locally — and the program pays later in rework, delay, or a launch nobody trusts.

The useful work, for me, isn’t “driving the plan.” It’s noticing where people are talking past each other early enough to do something about it.

That can look small: pause a meeting and write the decision on the board. Ask two teams to define the same field in one sentence. Check whether “done” means the same thing to delivery and operations.

Not glamorous. But delivery tends to move when people are on the same map — not when they’ve filled in more templates.

Process still matters. I just think it works best after alignment, not as a substitute for it.

I used to think the job was getting the numbers right. That still matters. But I’ve watched too many technically correct dashboards die a quiet death.

Someone opens it once. They can’t tell if the figure is gross or net, point-in-time or rolling. They ask a colleague. Shrug. Next week they’re back in the spreadsheet they already trust.

The system didn’t fail on accuracy. It failed on trust.

In practice, trust means a person can answer three questions without chasing five teams:

1. What does this number mean?
2. Where did it come from?
3. What should I not use it for?

When those answers are hard to find, people invent their own versions of the truth. That’s how you end up with three “sources of truth,” each defended by a different team.

So I treat transparency as part of the deliverable — ownership, definitions, lineage at a useful level, and the caveats written somewhere humans will actually read.

A sophisticated system that people don’t understand loses to a simpler one they do. Trust is the output. Accuracy is necessary. It isn’t enough.

Large programs look organised on a slide: workstreams, owners, milestones. On the ground, the pain shows up in the seams — where one team’s output becomes another’s input, and nobody fully owns the join.

I’ve seen it in onboarding that crosses HR, IT and vendors. In reporting that depends on three platforms that all think they’re authoritative. In migrations where mapping was “done” but business validation was still an afterthought.

Inside a single team, people can usually make progress. Between teams, assumptions leak. Tickets get thrown over walls. Dependencies show up late. Everyone is busy — and the critical path is still waiting on a conversation that never quite happened.

That’s why I spend time on interfaces: data contracts, decision rights, handoff criteria, and the awkward question of who is accountable when two “greens” still produce a red outcome.

If you only improve what sits neatly inside a workstream, you can look successful while the program still struggles. The work that changes outcomes is often the unglamorous stitching between parts — making the seams visible, then making them somebody’s job.

There’s a temptation, especially in transformation and AI programs, to solve ambiguity with more capability. More platforms. More automation. More dashboards. More agents.

Sometimes you need those things. But if the underlying model of the work is confused — roles, definitions, decision paths — scaling it just distributes the confusion faster.

Before we invest in scale, I ask a blunt question: if we did nothing fancy, could we explain this cleanly on one page?

If we can’t, we’re not ready to industrialise it. We’re ready to simplify.

Simplification isn’t cutting corners. It’s choosing fewer concepts people can actually hold: one ownership model, one definition of a critical field, one path for exceptions instead of five.

Only after that does scale help. Automation on top of clarity creates leverage. Automation on top of ambiguity creates expensive noise.

I still like ambitious systems. I just prefer ambition that starts with something a human can explain without a forty-slide appendix.