Leading AI isn't counting PRs
I recently read a tech executive with a very direct message: the leaders who move on AI now will define the next decade, and the rest will wonder what happened. In his view, size no longer protects big companies: it's easier to get three people building something from scratch than to get a dozen VPs to agree on one decision.
His recipe has six steps:
- Make AI adoption a top-down rule, this week. No pilots.
- Set an AI budget that makes your CFO a little nervous, and track usage, not just cost.
- Ask non-technical teams to build something: let HR build its own recruiting system over a weekend.
- Put up a dashboard of PRs per engineer, that is, how many code changes each person ships, and let people compete.
- Have at least five people working on AI full time, reporting straight to leadership.
- Kill one hated legacy process every month and replace it with an AI-native one.
"If you don't understand AI tools yourself, you won't build the future: just a slightly faster version of what you already have."
Where I agree
With almost all of the diagnosis. The urgency is real, and AI can't be delegated three levels down: if the people in charge don't use it, they won't know what to ask for. I especially like step six. Removing one process nobody wants every month is a very concrete way to move forward. And I share the most human part of the post: with AI, many leaders become beginners again, and that's uncomfortable. But that's exactly where the learning happens.
Where I don't
There are two steps that I think, applied as written, do more harm than good.
Counting PRs per engineer. It measures activity, not value. As soon as a number becomes a target, people learn to move it: more changes, smaller ones, not necessarily better ones. I wrote about this in Being busy is no longer a badge of honour: with AI, generating work is almost free, so measuring how much work gets generated makes less and less sense. At Eurofighter we didn't measure how many things the team did, but how much faster documents got approved and how many hours engineers got back. That's what matters to someone.
Every team building its own tool, full stop. I love the idea of HR learning to build. But if every department puts together its own system over a weekend, in six months the company will have dozens of tools nobody maintains, with personal data scattered everywhere. It's what I wrote about in Building is easy now. Knowing what to build isn't, and what I had to solve at MEWS Partners: someone has to look at the whole ecosystem and decide what gets supported, what gets centralised and what gets retired.
What I'd do
- Leadership sets the destination, not the route. In aviation, the flight plan says where you're going and with what margins; the crew decides how to fly. Same with AI: clear goals from the top and freedom for each team to find its own way.
- Measure outcomes, not activity. Hours freed up, time until something reaches the customer, errors avoided. If the dashboard means nothing to a customer, it's the wrong dashboard.
- Build with simple rules. Anyone can experiment, but whatever stays and gets shared passes a minimal check: who maintains it, what data it touches and whether something similar already exists.
Where I think this is heading
Over the coming months I think many companies that put up activity dashboards will see the numbers go up and the quality not. Metrics will gradually shift towards outcomes. And a new role will appear in many teams: someone who doesn't build more than anyone else, but decides what's worth building and looking after.
Where the author is absolutely right is that waiting isn't an option. But moving fast isn't the same as moving well.
A question for you: if your company measured the impact of AI tomorrow, which number would you want it to look at?
The six-step recipe and the quote aren't mine: they were shared by a tech executive. The opinion and predictions are mine.
← Back to the blog