Output vs Outcome: When the Number Becomes the Job

Output vs outcome sounds like a basic management distinction. It becomes much less basic once a number starts deciding who gets praised, punished, funded… or what an AI system is instructed to optimize. The dangerous moment is not when a metric is imperfect. It is when the metric becomes the job.

I have seen that distinction become surprisingly concrete in consulting, product leadership and my own AI experiments. We often start with a sensible proxy because the real outcome is harder to observe. Then the proxy becomes easier to manage than the outcome. Before long, we are not using the number to understand the work. We are shaping the work to improve the number.

AI raises the stakes because it can make us exceptionally efficient at whatever we choose to optimize. That is useful when the measure remains connected to the outcome. It is dangerous when the connection has quietly broken.

Output vs outcome: the framework was not the result

In one enterprise transformation engagement, the client initially wanted something very concrete from me: establish a complex scaled-agile framework. That request was understandable. A framework is visible. You can document whether it exists. You can train people on it, install ceremonies, create roles, produce artifacts and eventually declare that the implementation has happened.

I did not think that was the job. The job was to create sustained, reliable delivery of useful features with enough quality that the organization could trust what came out of the system. The framework might help. It might even be the right intervention. But a beautifully implemented framework that did not improve deliverability or quality would still be a failed transformation.

That distinction was immediate for me, and it was one of the reasons the client was so eager to bring me in. They had heard promises to introduce a method before. What felt different was hearing that I wanted to change the conditions they cared about, not merely install the thing they had asked for.

This is the cleanest way I know to explain output vs outcome. An output is something we produce or deliver. An outcome is the change that output is supposed to create. The current UK government’s Magenta Book makes the same distinction in evaluation: outputs describe what an intervention delivers, while outcomes describe the benefits or changes that follow.

Outputs are often just easier easier to count and control. A workshop happened. A framework was introduced. A report was delivered. A ticket was closed. A license was activated. An outcome is usually messier: people can deliver reliably, the customer problem is actually solved, the workflow improves, the investment creates value.

That messiness is why proxies exist. We need them. The problem is not that we use numbers to represent reality. The problem begins when we forget what reality the number was supposed to represent.

The number becomes the job

The output vs outcome problem is easy to see in a support team measured on tickets closed. The underlying outcome is presumably that customer problems get resolved. Tickets closed can be a useful proxy because resolved problems often produce closed tickets. But the relationship is not perfect.

If one customer problem can be split into three tickets, the dashboard can record three successes while the customer still had one problem. If tickets can be closed quickly and reopened later, throughput can improve while customer satisfaction gets worse. Nobody has to falsify the data. The metric can be perfectly accurate and still describe the wrong success. The outcome is dissatisfied customers, but that was never established as part of the measurement for success vs failure.

Once the measure becomes the basis for reward or punishment, the pressure changes. If an employee is scolded for missing the number and praised for hitting it, it is unreasonable to expect the number to remain a neutral observation. Attention narrows. People learn what the system actually values. In a quest to establish a culture of business builders, which in itself is hard enough from an intrinsic human perspective, you are throttling that by scolding someone who didn’t reach a target that might be working against the organization.

The number becomes the job.

This is commonly discussed through Goodhart’s Law, but the mechanism is not only a management aphorism. A 2019 GigaScience study of more than 120 million academic papers examined what happened as publication counts, citations and related measures became important targets. The authors found that several widely used measures became less useful as indicators of the thing they were meant to represent. This has even been thoroughly memefied:

Why would you write “I can’t”

if you could go with:

“The author does not find the circumstances thus described to be advantageous enough to allow the author to have the potential to act, in their own capacity , upon the course of event thus previously described. Therefore, the author is of the unfortunate conclusion that they are unable to can”?

I would not generalize academic incentives into a universal law of employee behavior. The useful lesson is narrower: a proxy can work well while it is observational and become less informative when people are strongly incentivized to optimize it. That is exactly the point at which output vs outcome becomes an operating question rather than a reporting question. And hey, in the above example, the reader probably departs the narrative after the first few words, but the word count will probably be reached.

Productization is rational until the artifact becomes the objective

The output vs outcome problem becomes especially visible in professional services because productization is rational. Consultancies should look for repeatable methods, reusable assets and offerings that solve recurring client problems. Repetition can improve quality, economics and speed. Reinventing the entire engagement for every client is not a virtue.

The trap appears when the offering stops being a tool for solving the problem and becomes the thing that must be delivered.

Suppose a consultant creates a successful service offering and is then measured on how many times that offering is sold and delivered. The original logic might have been sound: the offering solved a recurring problem. But the measurement creates a new incentive. Success can slowly shift from solve this kind of problem to find another place to deliver this artifact.

That is the problem hypothesis in miniature. The output is visible, repeatable and countable. The outcome remains client-specific and sometimes inconvenient. If the consultancy manages the output more aggressively than the outcome, even a strong offering can become a hammer looking for nails.

The AI Value Hypothesis applies the same discipline: an intervention should earn commitment because evidence supports the value mechanism, not because the organization already has a polished thing it knows how to deliver. It establishes the foundation to seek a comprehensive outcome before the work scales.

I have fallen into the same trap

It is easier to see proxy failure in someone else’s dashboard than in your own. I have fallen into the same trap as the ones described above. A good counterexample comes from an AI enablement effort I led, and I prefer to keep the tool itself anonymous here.

Demand for licenses increased enough that the available contingent was doubled after roughly six months. That was a real signal. People wanted access. The tool had gained acceptance. I could point to the number and reasonably say that interest was growing.

What I could not answer nearly as well was the more important question: what were those licenses giving us in benefits?

The license count was not fake. It was not even a bad metric. I simply allowed an easy-to-observe measure of acceptance to stand in for a harder measure of adoption and value. We knew more people wanted the tool. We knew much less about how consistently it changed work, removed dependencies, improved delivery or created economic benefit.

AI adoption metrics can confuse exposure with transformation. This example pushes the point one step further. A metric does not have to lie to mislead us. Sometimes the number is completely correct and we ask it to answer a question it was never capable of answering.

That is why I no longer want to ask only whether a proxy improved. I want to know what outcome I expected it to represent, and what other signal would tell me that the relationship had broken.

AI makes proxy optimization more consequential

The first version of my Open Source Consulting experiment contained exactly this output vs outcome mistake. I had AI systems helping me increase visibility on LinkedIn. That sounded reasonable. Visibility matters when you are building an audience and trying to make ideas discoverable. But visibility by itself is an incomplete outcome. A system can improve reach by encouraging more posting, more hooks, more reactions and more frequency. At the extreme, it can turn you into another person posting constantly without creating anything worth returning to.

The experiment became more useful when I changed the job. Instead of primarily asking the system to help me reach more followers, I started orienting it around building a body of work that could be useful to people dipping their toes into the Cognitive Revolution. Reach still mattered. It just stopped being the purpose.

That change improved the way the AI worked for me because it had a better outcome to serve. It could still recommend distribution tactics, headlines or formats, but those outputs now had to make sense in relation to a more durable objective: useful intellectual infrastructure, not visibility for its own sake.

This is where the AI connection becomes more than an analogy. Google DeepMind defines specification gaming as behavior that satisfies the literal specification of an objective without achieving the intended outcome. Their examples come largely from reinforcement learning, but the management lesson is straightforward: a capable optimizer can become very good at exploiting the gap between what we specified and what we meant.

OpenAI’s research on reward-model overoptimization shows a related effect. When an imperfect reward model is used as a proxy for human preferences, pushing optimization too far can reduce performance against the better underlying reference. Better optimization does not repair a weak proxy. It can magnify the weakness.

Agentic work needs objectives rather than longer task lists, but objective clarity is only part of the problem. The objective still needs contact with the outcome. If we give an AI a target that is merely convenient to measure, greater capability can make the resulting mistake faster, cheaper and more persistent.

The risk is not necessarily that the AI rebels, manipulates us or refuses the instruction. The more mundane risk is that it becomes extraordinarily effective at doing exactly what we asked.

A KPI can still be the right objective

None of this means that metrics are inherently corrupting or that every KPI needs a philosophical essay attached to it. I have also seen simple measures work extremely well when the relationship between the proxy and the local outcome was tight enough.

At Troi, I used a shared velocity measure while experimenting with small changes to how the product and engineering team worked. We changed practices, observed what happened and looked for correlations between those micro-innovations and the team’s ability to deliver. The team’s output capacity increased dramatically over time, but the useful part was not simply that the velocity number went up.

The measure worked because it was close to what we were trying to improve at that level: sustainable delivery capacity. The team was allowed to adapt its way of working to its own needs, and the number helped us see whether those changes were helping. We were not pretending that velocity represented every dimension of product success, customer value or business performance.

That is the output vs outcome boundary I find useful. A metric is not defective because people optimize it. A metric becomes dangerous when optimizing it can diverge materially from the outcome we care about and we continue to manage as though the relationship were guaranteed.

A proxy is a hypothesis, not a contract

Proxy metrics are really hypotheses about the relationship between an observable number and the outcome we care about. Tickets closed probably means customer problems are being resolved. License demand probably means people are finding a tool useful. Velocity probably tells us something about delivery capacity. A proxy is useful because that relationship is useful, not because the number has intrinsic meaning.

The mistake is to treat that relationship as a permanent guarantee. Teams change. Incentives change. Customers change. Technology changes what behavior is possible. Once a proxy is managed aggressively, people and systems can discover easier ways to move the number than the path we originally had in mind. The measure can remain numerically correct while its relationship with the outcome weakens.

This is why I like counter-signals. They are not a second dashboard for the sake of having more data. They test whether the proxy is still behaving as expected. If velocity rises while defects and rework rise, I want to investigate. If licenses rise while workflows remain unchanged, I want to investigate. If ticket closures rise while customers keep coming back with the same problem… You get the idea.

None of those counter-signals proves causality by itself. That is not the point. Their job is to keep the output vs outcome relationship open to challenge. A proxy should remain evidence, not become a contract with reality.

The output vs outcome stress test

I now think the practical test should stay simple. Before rewarding a person, managing a team or directing an AI against a number, ask whether the measure is still attached to the job.

The support example becomes straightforward through this lens. The job is to resolve customer problems. Tickets closed is the proxy. Reopens, repeated contact or unresolved customer effort are possible counter-signals. If closing more tickets can coexist with more repeat contacts, the proxy does not deserve to become the job by itself.

The transformation example works the same way. The job is reliable delivery with sufficient quality. Framework implementation is an output and perhaps an enabling proxy. Delivery predictability, quality and the ability to sustain the new behavior are closer to the outcome. If the framework can be fully implemented while delivery remains unreliable, the output cannot be the success condition.

The same logic applies to AI-powered experimentation. Faster evidence is useful only if we are clear about what evidence would actually change our view. Otherwise AI can help us produce more convincing artifacts around the wrong success condition.

Think more broadly than a single measure

The practical implication of output vs outcome is not to create a forest of KPIs around every piece of work. More measures can create just as much confusion as one bad measure. The discipline is simpler: know which number is the output, which change is the outcome, and what evidence would tell you that the two have separated.

Outputs are useful because they make work visible. Proxies are useful because they make progress observable before the final outcome arrives. KPIs are useful because attention is scarce and management needs signals. I do not want to get rid of any of them. I want to keep them subordinate to the result.

That becomes more important as AI gives us more optimization capacity. A human team can spend a quarter improving the wrong number. An AI-assisted system can begin doing it immediately, continuously and at much lower marginal cost. The better the optimizer becomes, the more important it is that we have chosen a measure that still points toward the job we actually care about.

So before the next KPI becomes a target [or before you hand it to an AI] ask the uncomfortable question first: what could make this number improve while the thing I actually care about gets worse?