The steering, not the brake

There is a particular kind of person who hears about a problem and starts thinking about how to fix it before the meeting has finished. Most teams want more of these people, not fewer. They are usually the ones who get things done.

What nobody warns you about, when you're trying to put AI at the centre of how a business works, is that the same instinct, in the wrong week, will go and solve the wrong problem at the wrong end of the chain, on a budget that turns out to be expensive.

A few weeks ago, on a call about something else, a dev on a client's team asked us a question in passing. We followed the thread. By the end of the call we had uncovered a piece of work that nobody senior had heard of, that was solving the wrong part of the problem, on the wrong infrastructure, at roughly thirty-five times the cost it needed to be.

This was not negligence. The team had spotted a real gap and started building, quietly, the way capable people sometimes do. The dev who asked the question wasn't hiding anything. The work simply hadn't surfaced anywhere it could be seen. A few people knew. Most of the people who needed to know didn't.

The fix they had chosen would have worked, in the local sense that it would have closed the immediate ticket. It would also have committed the organisation to about £7,000 a year in infrastructure for a problem we already had a £200 answer to, at a point in the chain that discovery had already shown was the wrong one. We needed to fix the start and the end. They were fixing the middle.

We see this often, in companies that have decided AI belongs at the centre of what they do. A capable internal team, told to move, finds a problem and starts solving it. They are doing the job they were hired to do. The piece that's missing isn't talent or motivation. It's a way for the work to be seen before it's far enough along to be expensive to redirect.

We sometimes hear, from the same teams, that process slows AI work down. We don't think that's quite right. Process isn't there to block the work. It's there to steer it.

What we're putting in

On the engagement that prompted this Note, the answer isn't a gate. It's three small habits.

First, educate the dev. Show them which resources are the right ones for which class of problem, so the question "should we build this here, with these tools, on this budget?" has a quick, honest answer.

Second, bring them into discovery. The work that goes into deciding what to fix is almost always invisible to the person who ends up fixing it. If they have sat through the conversation that ruled out the middle of the chain, they don't quietly rebuild the middle of the chain.

Third, make the process visible. Advertise it. A process that lives in one person's head will get worked around. A process the whole team can see, and trust, gets used.

None of this is unique to AI. What AI changes is the cost of getting it wrong. The infrastructure is pricier, the strategic implications bigger, and a motivated team can ship something faster than the wider organisation can absorb it.

If your team is producing AI work you didn't know was in flight, the issue isn't that they are moving too fast. It's that nobody else has a hand on the wheel.