Where most of my time goes
AI, and the value it is supposed to produce
Agents don't make a slow company fast. They make a precise company faster and an imprecise one busier. Almost everything I do in this area comes out of that one asymmetry, and almost none of it is about which tools you buy.
Why do most AI programmes produce activity instead of value?
Because the constraint sits before anyone builds. In the organisations I have taken through this, well over half the time from idea to production is spent deciding what to do, arguing about who owns it and defining it precisely enough to start. Agents compress the build step, which was never the bottleneck, so throughput stays flat while work in progress climbs.
Mandates
What I actually get asked to do
- 01
Find where the value is, asset by asset
Across a portfolio or across a single business: which processes have data behind them and a decision worth improving, and which are a slide. Most AI opportunity maps I'm shown rank ideas by enthusiasm.
- 02
Diagnose why delivery is slow, precisely
Not a maturity score. A named list of limiting factors split into what the company chooses to do, how it does it, and why the pattern survives even though everyone can see it. That third one is where the incentives live.
- 03
Install spec-driven development
Getting a company to say what it wants precisely enough that an agent can build it and a person can check it. That's a change in how business and technology work together, which is why it isn't a training problem.
- 04
Run an agentic delivery programme
Around eight weeks, several workstreams in parallel, twice-weekly problem solving instead of stage gates. Real output on real systems, with the method left with your team rather than in a document.
- 05
Rebalance the technology organisation
Most functions I see are badly shaped rather than badly sized — heavy on coordination, thin on definition and review. Shape before headcount, every time.
- 06
Fix what the board sees
Three numbers, reported the same way every month, including the months they look bad. You'd be surprised how much of the perceived problem is a reporting problem.
Questions I get
We bought the tools and nothing changed. Now what?
That's the normal outcome, and it's diagnostic rather than disappointing. It means your constraint is upstream of the build step. Measure what share of lead time is spent before anyone writes code — in the companies I've looked at it's usually well over half. Until that comes down, better tools just make more work in progress.
Does this mean we need fewer engineers?
Usually it means a different shape, not a smaller number. What I typically find is too many people coordinating, too few who can define a problem precisely or review generated work well, and an architecture layer that's stopped producing successors. Cut before you fix the shape and you lose the wrong people.
Is this only for software companies?
No, and the gains are often bigger elsewhere. A retailer, an insurer or a media group has more genuinely specifiable work and less internal resistance to the idea that specification is a discipline. Regulated businesses do well too — they already write things down.
How fast does a board see anything?
A diagnosis is four to six weeks and is useful on its own. A delivery programme runs about eight weeks and should put working output into a real system inside that window. A programme that only produces a method hasn't proved the method.
What happens after you leave?
The method has to sit with named people inside the company or it decays in a quarter. That's a design constraint on the engagement, not an afterthought — I run the sessions with the team doing the work, not with a committee watching it.
If your AI programme is busy but the numbers haven't moved
That's the most common reason people call me, and it's diagnosable in a few weeks. Tell me what you've tried.