Point of View

Same Score, Different Disease: What Two "Equally Hard" Projects Taught Me About Diagnosing Enterprise Friction

A few years apart, I ran two enterprise initiatives that, on paper, looked almost identical in difficulty. Both slipped their timelines by months. Both required extraordinary personal effort to rescue. Both would score, on a simple 1-to-5 severity scale, almost exactly the same: one landed at 4.0, the other at 3.7. If you only looked at that number, you'd conclude these were the same kind of hard.

They weren't. One was a trust problem wearing a technical costume. The other was a legitimate technical crisis with almost no politics in it at all. And the fact that they scored the same is exactly the trap I want to walk through, because it's the reason most enterprises misdiagnose their own transformation problems and then apply the wrong fix.

The Instrument: A Decision Friction Index

Over the past year, working through a series of past engagements, I've been building something I call the Decision Friction Index, or DFI. The idea is simple to state and harder to apply honestly: score how much friction blocks a decision or initiative from moving at the speed it should, across three independent dimensions.

Structural friction is about decision rights: is there a named owner, a clear escalation path, an org design that matches the decision being made. Political friction is about incentives: are teams protecting their own turf, avoiding visible risk, genuinely misaligned on what success looks like. Mechanical friction is about the physical reality of the work: legacy systems, missing tooling, process steps that exist for no reason anyone remembers.

Every real situation is some mix of all three. The value of separating them is that each one needs a completely different fix, and a single overall severity number hides which fix you actually need. Which brings me to the two cases.

Case One: The Data Platform Everyone Agreed On, and No One Would Touch

The first case was a real-time data streaming platform for a large investment management firm. The business case was uncontroversial: replace an 8-hour batch ETL process that fed trade, compliance, and fund data across the firm with a Kafka-based platform that delivered the same data in near real-time. Everyone in the room, from portfolio management to compliance to the CTO's office, agreed this was worth doing. It promised a 60 percent reduction in feed costs and a real cut in manual errors. Nobody objected to the goal.

What happened next is the part worth paying attention to. Every downstream team that needed to consume the new streaming data kept telling us, in monthly executive meetings, that they had the capability to adopt it. Month after month, the commitment was there in words. When it came time to actually flip the switch, none of it had happened. We ended up writing the consumer-side integration code ourselves, quietly, because letting the initiative visibly fail at the CTO level was not an option for anyone in that room, including us.

At the same time, no downstream team would dedicate the hours needed to validate that the new platform's data matched the legacy system to the required precision. So we built an internal data quality certification tool from scratch, on our own budget, essentially to prove our own work was correct because no one else would check it.

None of this was a technology problem in the way it got described at the time. Kafka works. Streaming architectures are well understood, and there was even an easier on-ramp available that nobody raised: a managed offering like Confluent could have let teams get comfortable operating the ecosystem before taking on full platform administration themselves. Tellingly, that build-versus-buy question was never seriously debated. It wasn't on the table, because the real blocker was never "can my team learn to run this." It was "will my team put its name on this." What was actually happening was that adopting this platform meant a downstream team had to admit, on the record, that they now owned a new kind of operational risk, in front of a CTO who was watching the whole program closely. Nobody wanted to be the name attached to that risk if something went wrong. So the technical complexity of "understanding how Kafka replay works" became the polite, defensible reason to stall, when the real reason was that nobody wanted the exposure.

Scored on the DFI: structural friction was moderate, a 3, because ownership for downstream adoption was genuinely never assigned clearly. Mechanical friction was a 4, partly self-inflicted, since our own release planning ignored the fact that half the org disappears in December. But political friction was a 5, the highest score in any case I've logged so far. This was, underneath the technical language, almost entirely a trust and visibility problem.

Case Two: The System Nobody Was Fighting Over, and No One Could Read

The second case had almost the opposite shape. A retail organization needed to replace a core system that had mediated every transaction across every store for roughly forty years. Every point-of-sale event, every inventory movement, every vendor and logistics handoff ran through it. It was, in the most literal sense, the backbone of the company.

The trigger was not internal politics. The original vendor was no longer in a position to support the product, and over the years, meaningful access to current source code and documentation had effectively disappeared. The system itself was written in old C, full of function pointers and manual memory layouts that no engineer on the current team had ever worked with. The original toolchain used to build it was long gone as well, so what code we could recover could not simply be compiled and modified as it stood. A subsequent merger then made the situation urgent: the system's store and division logic was hardcoded, and the organization needed it to represent a different footprint of locations than the one it had ever been designed to handle.

There was no meeting where someone stalled to protect their reputation. There was no team quietly failing to deliver on a promise. This was a shared, undeniable crisis: an unreadable, unbuildable, mission-critical system with no vendor and no documentation, during a period, notably, when reverse-engineering tools were nowhere near where they are today. Reconstructing it meant going module by module, by hand, rebuilding the logic in Python, and slicing the rollout into tiers by risk so the business could keep running while the rebuild happened underneath it.

Scored on the DFI: mechanical friction was a 5, about as severe as this dimension gets. Structural friction was a 4, mostly because the merger introduced real governance complexity about which stores and divisions would even exist going forward, and because nobody had planned for a rebuild at this scale. But political friction was only a 2. This was, refreshingly, not a turf war. Everyone wanted the same outcome and was working the same problem from different angles.

The Same Number, and Why That's the Point

Run the overall math and these two cases land close together: 4.0 and 3.7 on the same five-point scale. If severity were all you measured, you'd walk away thinking these were comparable transformation challenges, roughly equal in difficulty, needing a roughly similar response.

They needed opposite responses. The investment bank case needed a governance fix: a named owner for downstream adoption, an executive willing to absorb visible risk on behalf of the program, and probably an incentive structure that didn't punish the first team to admit a gap. No amount of additional Kafka training would have solved it, because the stalling was never really about understanding streaming architecture. The retail case needed technical firepower and patience: engineers willing to read four-decade-old C code line by line, a risk-tiered rollout plan, and enough runway to rebuild something nobody currently understood. No amount of stakeholder alignment workshops would have made that codebase easier to read.

This is the real argument for separating friction into its component parts rather than reporting a single severity number. A 4-out-of-5 tells a client that something is badly stuck. It tells them nothing about whether the fix is a governance conversation or an engineering excavation. Get that wrong, and you spend a quarter running alignment workshops on a legacy-code crisis, or pouring modernization budget into a trust problem that no amount of tooling will resolve.

Why This Matters Beyond These Two Cases

I've written before that most enterprise delay traces back to decision latency rather than a shortage of technical capability, and that agentic AI is now making that gap harder to hide rather than easier to close. The Decision Friction Index is the diagnostic layer underneath that argument. It's an attempt to answer, case by case, not just "how stuck is this" but "stuck on what, exactly, and who needs to act."