Faster tasks aren’t faster outcomes
Almost every engineering team I speak to can show me a task that AI has made faster. Far fewer can show me an outcome that now arrives sooner.
On one of the online webinars I run for engineering leaders, a technology leader who had run a large engineering organisation put the problem in a single sentence. “People are trying to speed up tasks as opposed to getting to outcomes,” he said. They speed up their own day-to-day work, he explained, but the outcome they’re all contributing to doesn’t move.
That gap is where most of the promised value from AI is sitting right now, uncollected.
The gain is real, and it’s small
He reached for an old analogy. When factories first replaced steam pipes with electrical cables, they saw an efficiency gain of around 10 to 15 per cent. It came from small things, like no longer storing coal or cleaning soot off the building. Then it stalled for decades. The reason, he said, is that “they hadn’t relayed the factory floor.” The real gain only came once the layout and the processes were redrawn around what electricity made possible.
Dropping AI into an unchanged organisation is the same swap. His own team saw it. Early gains in throughput were modest, and bug rates went up before they came down. He was also clear that the gains were real once the work changed. An application his team had estimated at around three years of work was migrated in a matter of weeks, as a side project. He could say it would have taken three years only because he had detailed delivery data on how the team worked. He didn’t use that data to measure individuals, which he thinks is a mistake. He used it to understand how work moved through the whole team.
The economics have flipped
For most of software’s history, development was the expensive part, so teams did a lot of work up front to make sure it was worth building. He argued that has reversed.
“It’s cheap to get work done. It’s very expensive to work out what’s worthwhile doing,” he said.
If that’s true, a lot of the structure built around the old economics starts to look like friction. Separate product, engineering and commercial teams spend much of their time in meetings working out what each other is doing. His answer was to put small delivery units alongside the people who feel the result: call centre, fulfilment and customer service teams, close enough to give feedback within days. “You can’t have a separate product team from an engineering team,” he said.
An engineering leader at a product company, on the same session, described the same effect from a different direction. An engineer sitting next to a designer or a product manager, he said, is like magic.
Same tools, five to ten times apart
Another guest raised the part nobody could fully explain. In his experience, there are two kinds of people using the same tools. One group uses them to do their old work faster. The other uses them to build differently. He put the difference at five to ten times, and said he couldn’t work out where it comes from.
My own read is that it’s less about the person than the room they’ve been given. If your structure, your roles and your measures all assume the old work, people will use AI to do the old work faster, because that’s what they’re being asked for. The second group has been given permission, and a reason, to change what the work is.
What redrawing the floor looks like
Nobody on the webinar had a finished blueprint, but the pieces were consistent.
Map the value stream, then organise around it. Most processes exist because work moves from one team to another to another, not because anyone designed an end-to-end path. The technology leader’s advice was to map the whole route from idea to result and ask where work changes hands, then pull those handoffs together.
Change the job from tasks to objectives. He moved his teams from job descriptions to job objectives. It’s too hard, he said, to tell people “this is your job now”. Instead, “the job is now get the outcome done.”
Measure the outcome, not only engineering. A head of engineering at a large organisation made the point that engineering is the easy part to measure, because the work leaves a trail. Most of the AI use, and most of the cost, sits with product, design, commercial and data teams whose work doesn’t show up in the same tools. If you only measure the engineering slice, you’ll see tasks speeding up and miss whether the outcome did.
The workforce planning question underneath
If your plan for AI is a line in the budget for licences and an efficiency percentage against existing roles, you’ve planned for the swap from steam to electricity. You’ll forecast a small gain and you’ll get it.
The larger gain depends on a different question. What work needs doing, end to end, and what capability does it take? That’s the shift we keep coming back to in Beyond Headcount: planning around the capability and outcome you need, not around the roles and seats you already have.
Who this is for
I’m putting these webinars together for engineering leaders who are actually in it, running teams that are adopting AI, wrestling with what to trust it with, and figuring out what it costs when nobody’s watching. If that’s you, and you’d find it useful to compare notes with others facing the same thing, I’d genuinely like you there.
If you’re interested in being at the next online webinar, reach out to me.