The Proximity Problem: Why the People Closest to the Fix Are the Last Ones Who Can Sell It

You find the problem. You prove the solution. You do the math. And nobody does anything about it.

If you've spent any time running operations or are a manger, you know the feeling and you've probably blamed the wrong thing for it. It's tempting to call it politics, or short-sightedness, or a leadership team that doesn't get it. Usually it's something quieter and harder to fight: proximity.

The pain loses signal as it climbs

Picture a support team buried in tickets. The same category of error, over and over, hundreds a month. Someone close to it the ops manager, the person who actually reads the queue digs in and finds the cause. A check is missing upstream: the system flags things as errors before confirming they're actually errors. Add the check, and ticket volume drops by half.

The fix is two, maybe three weeks of developer time. Call it sixteen grand. The manager runs the numbers, proves it with real data pulled straight from the database, and takes it up the chain.

Nothing happens. It gets nodded at, agreed with, and quietly pushed down the backlog. Then again the next quarter. The bug is probably still there.

Here's what's actually going on. At the bottom, the pain is unbearable it is the job.

One level up, it's a line item. Two levels up, the team absorbing those tickets is offshore and cheap, so the cost barely registers. By the time it reaches the people who could greenlight the fix, the signal has faded to almost nothing.

That's the proximity problem: a problem only gets fixed when the pain reaches someone who has both the authority and the motivation to act on it. Most of the time, those two things live at different altitudes in the org.

It's not indifference, it's a different language

The instinct is to read this as executives not caring. That's the wrong read, and acting on it just makes you the person who keeps escalating and keeps losing.

They're not indifferent. They're operating on a different set of signals. The manager's pitch was fluent in operational efficiency tickets, error rates, developer hours. The people who could fund it speak revenue. A $16K fix framed as "cuts ticket volume in half" lands flat. The same fix framed as "we're burning five people's worth of capacity every month on work that shouldn't exist here's what they could be doing instead" is at least speaking the right language.

But translation isn't a magic trick, and this is the part nobody likes to say out loud: sometimes the problem genuinely doesn't rise to the level of concern. Sometimes you've done everything right and the answer is still no, because you're solving for a sponsor who was never going to care. Recognizing that early saves you a quarter of escalations. Pushing harder rarely changes it.

The vanishing sponsor

There's a mirror image of this on the other side of the budget cycle, and it's where a lot of software rollouts go to die.

An executive champions the purchase. They fight for the budget, win it, kick off the initiative and then they're gone. They believe they handed off a clean charter: go build the thing, make our lives better. What the implementation team actually inherits is a pile of constraints, tradeoffs, and competing priorities that never surfaced during the approval process. The edict to make things better doesn't make them better.

The rollouts that work almost always have someone with authority who stays in the gap. Not running the project holding space for it. Absorbing the complaints. Backing the team when adoption gets bumpy. Making it visible, repeatedly, that this matters. Pull that person out and the new platform becomes another login people perform to satisfy management. Nobody fills out the status column, because nobody with weight behind them is making the case that they should.

A sponsor isn't a budget holder. A sponsor is someone who's still present three months after go-live.

What it looks like when proximity works

The clearest version of this I've seen lately had nothing to do with software. It was a garage door.

Three companies came out to quote a replacement. Two of them did exactly what a shareholder-first playbook would tell them to: size up an ignorant customer, quote the simplest install, maximize the margin, move on. The customer doesn't know what he doesn't know, so why educate him?

The third did something different. The technician led with a question what are you actually trying to solve here? instead of a number. Then he translated. He explained that the broken spring meant the door was no longer counterbalanced, which meant it could drop. "You've basically got a guillotine over your car." Suddenly a vaguely-broken-door problem was legible to someone who is not a garage door expert. He offered options the customer didn't know to ask for: twenty years on, the same money buys a meaningfully better door from a different supplier.

Then, after the check had cleared after the transaction was, by every shareholder metric, complete they called back. They'd noticed a small detail they'd missed and wanted to come finish it properly. They could have skipped it. The customer would never have known.

None of that happens by accident. It happens when the people closest to the customer are trusted to exercise judgment, and when the company's incentives reward serving the person with the problem instead of extracting from them. The person answering the phone vouched for the technician unprompted. The technician volunteered the cheaper, better option. That's a whole operation oriented around the same thing and it's exactly what gets thinner as organizations scale, roll up, and start optimizing for the dashboard instead of the doorstep.

The question underneath all of it

A bug that never makes the sprint. A rollout that stalls after the sponsor walks. A customer who leaves feeling processed instead of helped. Underneath all three is the same question:

How much of your operation is actually pointed at the person with the problem?

Not the shareholder. Not the dashboard. Not the quarterly number. The person whose ticket is in the queue, whose door is broken, whose job depends on the thing you bought working the way it was supposed to.

When an organization loses track of that because it scaled past the point where the answer is obvious, or because the incentives quietly stopped rewarding it process debt piles up fast. Tickets accumulate. Workarounds calcify into permanent rituals. And the people standing closest to the problem keep raising their hands, keep getting nodded at, and keep watching the obvious fix go nowhere.

The proximity problem is real. It's not inevitable. But closing it takes someone with enough altitude to hear a signal that's faded almost to silence and enough curiosity to go find out what it actually means.

Process Debt is a podcast for operations leaders navigating the gap between buying software and making it work. New episodes drop weekly.