Measuring in Different Times

On inherited structure, competing clocks, and metrics nobody questions

A few years ago we were brought in to help a company in the retail and manufacturing industry modernize a set of internal software tools that were past their prime. The math was straightforward. Turnaround time on the affected tasks would drop. Maintenance costs were projected to come down. And it opened a real path toward scaling the business without scaling headcount at the same rate.

There was a catch. Rolling out the change meant interrupting some existing processes for a while as things switched over. As such, the metrics tied to those processes would take a hit for a quarter, maybe two. After that, we all felt confident that the numbers would recover and then some. The project was set to pay for itself fairly quickly.

It never launched.

The stakeholders whose metrics would dip looked at one to two calendar periods of worse numbers and were not willing to take such a risk. And it wasn’t exactly because anyone disagreed with the math. But the math lived on a different clock than the one they were being measured against. They calculated in months and quarters, we projected across 1-2 years.

Now it would be quite easy to tell it as a story about risk aversion. I could also talk about people protecting their bonuses tied to performance metrics. It could also be a story about an organization too scared to invest in its own future. But personally, I just don't think that's what happened. Everyone in that room acted rationally, given what they were accountable for. The people who wanted the initiative were right. The people who blocked it were also right, by their own numbers. From within the constraints each person was given to operate in, all of their choices were logical and nobody made a bad decision. The structure around them made their decisions inevitable.

I’ve come to think of it as organizational debt. We talk about technical debt in software all the time. We talk about all the shortcuts and quick fixes that pile up in a codebase until the system gets harder to change than it should be, not because any one choice was wrong, but because nobody paid down the accumulated cost of all those choices together. Never fix a broken system - or touch code that nobody understands anymore. But organizations build the same kind of debt. It's sitting in reporting lines, KPI definitions, and org charts that nobody designed so much as inherited. They just get carried forward as the markets change, business adapts, products and services get added or sunset.

If you think about it, we did inherit it, more literally than most of us realize. The org chart as we know it, the boxes and lines and the layers of hierarchy, has roots in 19th century (!) railroad management. Railroads were the first businesses to face a coordination problem at a scale nobody had dealt with before: trains running on shared track, on a timetable, across huge distances, where one bad handoff meant a collision. And to such a problem the hierarchical chart was a genuinely brilliant answer. It assumed work flowing in one direction, authority matching physical position in a chain, and everyone operating on roughly the same clock - if you disregard timezones maybe. But trains don't distinguish between quarterly versus annual thinking. A train is either coordinated with the rest of the system or it isn't.

The vast majority of today’s organizations are not coordinating trains anymore. Most of us are doing knowledge work, where the coordination problem looks nothing like synchronizing physical objects on fixed track. Moving parts are mostly metaphorical. But a lot of us are still organized as if our work still matched this mental model, because the operating model got inherited long after the problem it was designed to solve went away.

Nowhere does that inheritance show up more clearly than in time horizons. In the example of our project, the initiative's owner was thinking in the timeframe it takes for an investment like this to mature, probably a year or more. The stakeholders being asked to absorb the dip were being measured quarter to quarter. Both of those are legitimate ways to run a business. The problem wasn't that either clock was wrong. The problem was that nothing in the organization's design made those two clocks sync up with each other before the decision had to be made.

Peter Drucker made a version of this point decades ago. He argued that innovation should never be owned by the same people responsible for day to day operations. His reasoning wasn't about talent or bandwidth. It was about incentive. Operations people are, correctly, measured on keeping the current machine running smoothly. Asking them to also own initiatives that are speculative, that might disrupt the very processes they're accountable for, puts them in an impossible position. They're not being asked to take a risk. They're being asked to damage their own scorecard. And in some cases the gain might show up on somebody else’s card.

That's exactly what happened here. The stakeholders who blocked the initiative weren't the wrong people to have opinions about it. They had great ideas and invaluable insights into process gaps, unmet needs, constraints, and opportunities. But they were the wrong people to make the final decision, because the org gave them no way to separate "is this good for the company" from "is this good for my number this quarter." Nobody built the mechanism that would have let both questions get asked honestly, in the open, at the same time.

What would that mechanism have actually looked like? Not heroism, and not someone finally being brave enough to eat the hit. It comes down to naming, explicitly, which KPIs would dip, by roughly how much, for how long, and what the projected recovery curve looked like on the other side. Turning "trust me, it pays off" into a specific, time-bound hypothesis with milestones that the whole room could evaluate together. We can frame such hypotheses, but incentives and org structures need to align accordingly to allow the hypotheses to be tested.

If we take one step further, we should also ask a harder question. It’s one that most organizations never get around to asking. Are we protecting these metrics because they’re still telling us something true about the business? Or because revisiting them feels riskier than whatever they’re currently blocking? Sometimes a KPI that made perfect sense five years ago can quietly stop measuring what matters. Yet it keeps dictating decisions anyway, purely because nobody dared questioning its validity.

Most of us aren't blocking good initiatives out of fear or bad faith. We're just much more adept at reading our own clock and nearly illiterate in reading anyone else's. It’s what the structure trained us to be and what we’re incentivized to do. The operating model was built for a different kind of work, in a different century, still running quietly underneath ours.

Somewhere in your organization there's a version of that retail and manufacturing initiative right now. Maybe a quarter or two of worse numbers that stand between where you are and something better. And underneath it, there’s a metric nobody's revisited in a while, quietly dictating decisions because challenging it might be an even harder problem to solve.

What is it deciding, and is anyone allowed to disagree?