Outcome over output

It has never been easy to measure productivity in software development.

The topic keeps popping up on my radar after we have embraced AI in the form of large language models (LLMs) and agents.

How do we measure productivity in software development when we no longer write the code ourselves?

Increasingly, we are no longer writing the code we were previously measured on. Or: at least, what developers were previously paid to produce.

Perhaps you as a developer have never been measured directly on the number of lines of code (LOC) you produced in a day, a week or a month. I have personally never been measured on that number at the workplaces I have worked for in Denmark. Luckily we were smarter than paying the author by the word he wrote!

It is more likely that you have been measured on story points, features or tasks closed in a sprint.

Whether or what you have been measured on before, AI agents are a welcome occasion to update how we look at productivity and efficiency. Because it has never been easier to produce a lot of lines of code.

I recently revisited Martin Fowler. Back in 2020 he published an article titled:

Outcome Over Output

It is quite interesting to reread this article now, because it was written 2 years before the AI wave started to roll.

In November 2022, OpenAI released their first large language model, ChatGPT, which started the wave for most people. Some might say that at the time it mostly looked like a ripple on the ocean. Right, it was fun to get ChatGPT to write wild stories about a pilot who saves a dolphin from a killer whale by defending the dolphin with his pilot boat. Or to produce a confirmation song that made the guests' toes curl up. But for many it was mostly a gimmick, a party trick. Back then I had a hard time seeing how an artificial intelligence that was not able to count the number of i's in "Mississippi" could revolutionise programming. Or change or affect practically every profession, for that matter. Fast forward to 2026, and things look somewhat different.

Fowler writes in the article that "you get what you measure". In other words: if you measure (and reward) directly on output, you will probably get more output. His point back then was that we should instead measure and reward outcome, the effect of what we deliver.

He writes, among other things:

"If a team delivers lots of functionality - whether we measure it in lines of code, function points, or stories - that functionality doesn't matter if it doesn't help the user improve their activity."

And:

"If you focus appraisal of success on output, then everyone is thinking about how to increase the output. So even if it's tricky to determine how a team's work affects outcome, the fact that people are instead thinking about outcomes and how to improve them is worth more than any effort to compare teams' proficiency in producing the wrong things."

AI as an organisational amplifier

AI has rightly been called an "organisational amplifier" or a "force multiplier" (e.g. in the DORA 2025 report), and in this context it means that if you are already measuring the wrong things, or not getting the results you want, then it only gets worse if you throw AI on top of it all.

Activity has become much easier: AI agents stand ready 24/7 to deliver code, designs, slides, documents etc. endlessly - if you have your tokenomics under control (yes, it IS a word).

Another concept that appears on the radar is technical debt - because it has never been easier to produce technical debt than with AI agents on board. But that will have to be another article.

Therefore: Outcome over activity

It is a bit like turnover vs. result:
Turnover can be sky-high - but without generating a profit.
And plenty of activity and output can certainly be there - but without effect.

In a world with AI agents as producers of software, it becomes even more important to aim for:

Outcome over activity.

Value over volume.

Or: Make a difference - don't just make a lot.

Whichever punchline we choose, it is more relevant than ever to look at which outcomes you want for every single initiative, project or change you launch.
It may seem difficult to define outcome, but measuring activity instead is not the solution. And remember - as Fowler says - that measuring output has never really worked out well either.

So try the experiment: aim to define outcome over output in your next project/iteration/sprint/space voyage.

Because it does not matter how fast you run if you are not running in the right direction.