The symptom
An activity metric counts how much of something happened — calls made, cases closed, steps completed, hours logged. An outcome metric measures whether the thing the activity was meant to achieve actually happened. The two are related but not interchangeable, and the symptom worth watching for is an activity metric that improves while a nearby outcome metric, measuring the actual purpose of the activity, moves in the opposite direction. Handling time falling while rework rises is a clean, recognisable instance of exactly this pattern: the activity got faster; the outcome the activity existed to produce got worse.
The instinct when this happens is to search for a hidden or complex explanation — a root cause buried somewhere in the system, an unintended consequence of some other change happening at the same time. That instinct is not wrong often enough to be dismissed, but it is worth resisting as a default, because the more mundane explanation — the change itself was simply not well designed or well implemented — is available and should be checked first, precisely because it is less interesting to discover and therefore more likely to be overlooked in favour of a more elaborate theory.
Why it happens
Activity metrics are attractive because they are easy to define, easy to influence directly, and produce visible movement quickly. Outcome metrics are harder to define precisely, often lag the activity that produces them, and are influenced by more factors than any single change can fully control. This asymmetry in how easy each type of measure is to move creates a structural temptation: a change aimed at improving an activity metric can succeed completely, by its own definition, while doing nothing for — or actively harming — the outcome the activity was ultimately there to serve. The pattern is an old one: V. F. Ridgway’s 1956 study of performance measurement in Administrative Science Quarterly found that single, multiple and composite measures can each produce undesirable consequences for overall performance.
The mechanism is compounded when a change to a process is designed without meaningful input from the people who actually perform the work being changed. Someone reviewing a process from the outside can identify, correctly, that three sequential steps look redundant and could plausibly be consolidated into one. What that outside view often cannot see is the specific reason each step existed in its original sequence — a check that only functions properly if performed independently of the step before it, an order of operations that was not arbitrary even though it was never formally documented as load-bearing. Removing a step that looks redundant from a process-map view can remove a genuinely necessary check from a hands-on view, and the two views frequently disagree without either being obviously wrong on its own terms.
What leaders often conclude, once an activity metric has moved favourably, is that the change worked and can be considered resolved. What the evidence in this kind of case usually suggests is narrower: the change worked at the level it was measured, and whether it worked at the level that actually mattered is a separate question that requires checking a different metric entirely — one that is often not tracked with the same immediacy as the activity metric that prompted the change in the first place.
What it looks like in practice
Consider an organisation where a team consolidates three sequential review steps into a single combined step, specifically to reduce handling time — a reasonable and clearly stated objective. Handling time falls as intended, and the change is initially recorded as a success. Shortly afterward, rework — cases that have to be reopened and corrected after being marked complete — rises sharply.
A review of the change finds a specific and unglamorous explanation: the consolidation was designed without input from the people who had been performing the three original steps, and the particular sequencing chosen for the combined step makes one of the original checks structurally impossible to complete properly within the new format. This is not a case with a deeper hidden cause waiting to be uncovered. The subsequent search for one, once undertaken, finds nothing beyond an ordinary design failure: a genuine but avoidable oversight in how the change was put together, not a subtle systemic issue requiring extensive investigation.
The instructive part of this case is less the specific failure and more what it reveals about the relationship between the two metrics involved. Handling time is an activity metric — it measures how the work is done. Rework is closer to an outcome metric — it measures whether the work was actually done correctly the first time. A process change can succeed entirely on the first while failing badly on the second, and an organisation that tracks only handling time, without a nearby check on rework or quality, would have no visibility into the failure until it had already accumulated real cost.
Notably, the eventual correction in this case did not require an elaborate investigation once the search for a hidden cause was set aside. The design flaw was visible as soon as someone asked the people performing the new combined step what, specifically, the step now made difficult that had previously been straightforward — a simple, direct question that a purely metrics-based review, focused on the handling-time and rework numbers alone, would not have prompted anyone to ask.
Looking for your own sector? The Other Sectors page points to the closest match.
Questions worth considering
- When an activity metric improves following a process change, has the corresponding outcome metric — the one the activity actually exists to serve — been checked in the same period?
- Were the people who perform a process consulted before a step in that process was removed or consolidated, or was the change designed entirely from a process-map view?
- When an initial, unglamorous explanation for a problem turns out to be correct, is the organisation able to accept that and stop looking — or does it tend to keep searching for a more complex cause?
More on this topic: Performance.
Your team is facing similar challenges?
Subscribe to The Riddle Ledger
Perspectives are sent as they are published, with no promotional email, and you can unsubscribe at any time.