A team shortens a step. The step was taking too long, the shortened version performs the same function, and the measurement confirms the gain: faster, cleaner, better received.
Months later something downstream is worse, and nobody connects it to the change. The connection is hard to see because the two effects live on different dimensions. The gain was measured in time. The loss landed on quality, on context, or on a signal that something unusual was happening, and none of those was being measured in the first place.
This pattern is common enough to be worth naming. An efficiency improvement is evaluated on the dimension it was designed to improve. The dimension it degrades is usually the one that had no metric, which is frequently why the step looked inefficient to begin with: it was performing a second function nobody had named.
Key takeaways
- Steps frequently perform a secondary function that nobody documented and nobody measured.
- Efficiency changes are evaluated on the dimension they improve, so the degradation goes unobserved.
- The absence of a metric on the degraded dimension is often the reason the step looked wasteful.
- The loss is usually delayed, which breaks the causal link between the change and the effect.
- A short test before accepting a change catches most of these: measure what the old version produced that the new one does not.
- The pattern argues for measuring before optimizing rather than against optimizing.
Where the secondary function hides
Five places it shows up, and the shape is the same in each.
The part of a conversation where the detail arrives
Interactions have a warm-up. The first exchanges establish context and the specific information tends to arrive later, once the person has moved past the general description into the particular case.
Shortening an interview, a call or an intake conversation improves the experience on every measurable dimension. Whatever was arriving at the end stops arriving, and nothing reports its absence.
The free-text field
Structured forms are easier to complete, easier to analyze and faster to process. The open field that gets removed was where people described the case that the categories did not cover.
Removing it improves completion rates and data quality in the structured fields. The exceptions that were being described there become invisible, and the organization loses its only channel for learning that its categories are incomplete.
The approval nobody could justify
A review step with a low rejection rate looks like a candidate for removal. The rejection rate is the measured output.
The unmeasured output is that a person looked at each case. Some proportion of what they caught was never recorded as a rejection, because they resolved it by making a phone call, correcting an input or asking a question that changed the submission.
The meeting that seemed redundant
A recurring meeting with a thin agenda is an obvious efficiency target. The agenda was its visible function.
Its other function was incidental coordination: people discovering what adjacent teams were doing, raising something that had not become a problem yet, and maintaining the informal routing map that makes escalation fast.
The local adaptation
A market runs a variant of the standard process. Standardizing it removes configuration cost, training variance and maintenance.
Some variants exist for a real local requirement. The ones that do not are worth removing, and distinguishing between them requires knowing why each was introduced, which is information that was rarely recorded.
Why the loss stays invisible
Three mechanisms, and they reinforce each other.
The metric does not exist on the degraded dimension. The step was performing a function nobody had named, so nobody was counting it. After the change there is no before-and-after comparison to make.
The effect is delayed. Quality degradation, missed exceptions and weakened coordination surface over months. By the time they are visible, several other things have changed and attribution has become impossible.
The gain is reported and the loss is not. The person who made the improvement reports the improvement. The downstream effect lands with someone else, who has no reason to connect it to a change in another team.
The combination means the organization learns that the change was good and never learns the rest.
The shape of the trade
Why the two sides are measured differently
| The gain | The loss | |
|---|---|---|
| Dimension | Time, cost, satisfaction | Quality, context, signal, coordination |
| Measured before | Yes, that is why the change was proposed | No, which is why the step looked wasteful |
| Timing | Immediate | Delayed |
| Attribution | Clear, to the team that made the change | Diffuse, lands elsewhere |
| Reported by | The improver | Nobody |
The asymmetry is structural. Both effects are real and only one of them has a reporting path.
The test
One exercise catches most of these, and it takes less time than the change itself.
Before accepting the improvement, measure what the previous version produced that the new one does not.
Concretely: take a sample of the old process output, apply the change retroactively, and compare. A shortened conversation can be tested by truncating completed ones and measuring what is lost from the final portion. A removed field can be tested by analyzing what was written in it. A removed approval can be tested by asking the reviewer what they did beyond approving and rejecting.
Three properties make this work.
It is cheap. A sample of a hundred cases is usually enough to see whether the loss is negligible or substantial.
It produces a number on the dimension that had none, which is the whole point.
It runs before the commitment, when the change can still be adjusted rather than reversed.
The outcome is frequently that the loss is small and the change proceeds with more confidence. Occasionally the loss is large, and finding that out costs an afternoon instead of two quarters.
What to ask before removing a step
| Question | What it surfaces |
|---|---|
| What does this step produce that we measure? | The visible function |
| What does the person performing it notice while doing it? | The secondary function |
| What was happening before this step existed? | The problem it was introduced to solve |
| Who receives the output, and what do they do with it? | Downstream dependencies |
| If it disappeared tomorrow, what would break first and when? | The delay before the loss becomes visible |
| What would we have to start measuring to know it was gone? | The missing metric |
The second question is the productive one. Someone performing a step for years notices things while doing it, and that noticing is frequently the function that matters most.
What this argues for
Not for keeping inefficient steps. Several of the examples above describe work that genuinely should go, and the test will show that.
The argument is about sequence. Measure the dimension at risk before making the change, so the comparison exists afterward. That is a small addition to the design of an improvement and it converts a guess into a result.
There is a second implication for improvement programmes generally. A portfolio that reports only gains is reporting one side of a set of trades. A function that can occasionally say that a change was reversed because the measured loss exceeded the gain has a more credible portfolio than one where every initiative succeeded.
Where Horizon fits
Horizon is an AI-powered continuous discovery platform. Its connection to this pattern is that secondary functions are known by the people performing the step and recorded nowhere.
Discovery Cycles run AI-led interviews that ask what people notice while doing the work, what they do beyond the recorded output, and what they would warn someone about. Those questions reach the secondary function, which a process map describes only by its visible purpose.
The Process Library records what each step produces, including the parts that generate no system record, which is what makes a before-and-after comparison possible later. The Insights Dashboard holds findings against processes with traceability to the input behind them, so a change made in one function can be examined against what a downstream team described.
The practical effect is that a process map built from practice names more of what a step does than one built from design intent, and the secondary functions are exactly the part that design intent omits.
Checklist before an efficiency change
- What dimension does this improve, and what dimension could it degrade?
- Is the second dimension currently measured?
- If not, can you establish a baseline for it in a week?
- Have you asked the person performing the step what they notice while doing it?
- Do you know why the step was introduced?
- Have you tested the change retroactively against a sample of past cases?
- Who downstream receives the output, and have they been asked?
- How long would it take for a degradation to become visible?
- What would you have to monitor to detect it?
- What result would cause you to reverse the change?
Question 10 is the one that distinguishes an experiment from a commitment.
Common mistakes
Measuring only the dimension being improved. Produces a result that is accurate and partial.
Treating a low rejection rate as evidence a review is unnecessary. The rejections are the recorded output. The questions, corrections and calls are not.
Removing a free-text field for data quality. Improves the structured data and removes the channel through which the organization learns its categories are incomplete.
Standardizing variants without establishing why each exists. Removes the ones that were compensating for a real local requirement along with the ones that were not.
Shipping before testing retroactively. The test costs an afternoon and runs while the change can still be adjusted.
Reporting a portfolio where everything succeeded. Indicates that losses are going unmeasured rather than that none occurred.
FAQ
Why do process improvements sometimes make things worse?
Because a step frequently performs a secondary function that nobody documented. The improvement is measured on the dimension it was designed to improve, and the degradation lands on a dimension that had no metric, which is often the reason the step appeared inefficient in the first place.
How do you measure what a process change removes?
Take a sample of output from the previous version and apply the change retroactively. A shortened interaction can be tested by truncating completed ones and measuring what is lost from the final portion. A removed field can be tested by analyzing what people wrote in it. The exercise is cheap and it produces a number on the dimension that had none.
What is a second-order effect in process optimization?
A consequence that appears on a different dimension and at a different time from the change that caused it. The gain is immediate and attributable. The effect is delayed and lands with a team that has no reason to connect it to a change made elsewhere.
Should you keep a step with a low rejection rate?
Not necessarily, and the rejection rate alone does not settle it. Ask the reviewer what they do beyond approving and rejecting. A substantial part of what a review catches is frequently resolved through a question, a correction or a call, none of which appears in the rejection count.
Does this argue against efficiency programmes?
No. It argues for measuring the dimension at risk before making the change, so a comparison exists afterward. Most of the time the test shows the loss is small and the change proceeds with more confidence. Occasionally it shows the opposite, and finding that out early costs an afternoon.
Measure the thing you are about to remove
An improvement that is correct on its own terms can still be a poor trade, and the way to tell is to have a number on both sides before committing.
The dimension that lacks a metric is usually the one carrying the function nobody named, which is the same reason the step looked like a candidate for removal.
See it. Fix it. Own it.