Your Business Got Really Good at Compensating

Ingenuity keeps the work moving. But when the workaround becomes the way you work, the compensation check gets cashed somewhere - in your people, processes, data or technology.

When something is not working quite right, another part of the organizational system picks up the load. At times, this is so effective that we do not realize there is a problem until the compensation itself starts causing symptoms.

A spreadsheet fills the gap between two software tools. An analyst reconciles numbers every month because two parts of the business never quite agreed on what they meant or maybe want at an enterprise level. A recurring meeting becomes the place where decisions get made because nobody is entirely sure who has the authority to make them anywhere else.

And because the business keeps functioning, we call it a process.

None of this is necessarily failure. It is often bootstrapping at its finest: evidence of resilience and ingenuity. People figure out how to get the work done even when the environment around them does not quite support it.

The problem is not that the workaround exists. But a problem certainly grows when the organization evolves and nobody takes a second to ask whether the workaround needs to evolve with it. And eventually that very compensation pattern becomes so normal, so ingrained in the day to day, that we mistake it for the desired way the organization should operate.

Of course, if all of these compensating mechanisms could advocate for themselves, we might already know there's a problem - especially when the phone rings…

• Your employee called. They'd like a raise for being the organizational spray foam holding everything together.

• Your spreadsheet called. It would like to be included in the holiday bonus pool.

• Your data quality rules called. They'd like overtime for catching the same problem 37 different ways.

• Your recurring meeting called. It would like hazard pay for every time someone asks whether it could have been an email. Apparently, the email wasn't doing its job.

• Your legacy platform called. It would like access to the EAP to work through everyone blaming it for an operating model it didn't design.

Everybody wants to get paid.

Joking aside, something is absorbing the cost when the way the organization needs to work and the way it actually works don't quite line up.

And sometimes that something is a person.

When the person becomes the process

Years ago, I worked with financial instruments that exposed exactly this kind of problem.

Some instruments traded like corporate bonds but were securitized products, or vice versa. The data sat awkwardly between established models and teams, and neither side could consistently or effectively handle them. In some cases, the same instrument ended up duplicated across databases - which believe me creates even more of a headache when you're peddling unique identifiers.

Want to guess what the workaround was? Me!

I had access to a restricted entry screen where I could manually identify which database record was the accurate one. It was far from elegant, but it kept the information moving and prevented bad identifiers from propagating.

I documented the process. I trained backups. I wrote job aids.

Then I went on maternity leave.

Months later, I came back and found that the work had simply waited for me. Since a fire didn't start, no one was compelled to fold it into their remit.

That is an important distinction. I was not indispensable because nobody else could physically perform the task. The organization had decided that continuing the manual process was easier to justify than investing in a genuine solution to what made the task necessary. But it was the culture that quietly decided not to execute on the manual process when mom was literally off duty.

There was no obvious ROI for fixing the underlying problem. So the bandage persisted.

I didn't have the authority to solve the underlying technology problem, and doing so would have required meaningful investment across two databases and asset classes. There were absolutely less elegant stopgaps available: better cross-training, clearer coverage, more deliberate team-leader oversight.

But those still required other people to understand and take responsibility for the complexity. Apparently, it was easier to let the person who already understood it keep handling it.  Sometimes you just can’t change the collective mindset, and sometimes there really is no other clear viable path around the collective obstacles - even when that solution is a single person and me!

I still wonder, several years later, what would happen if I ran a search today? Did someone eventually pick up the coverage? Did the underlying model change? Or did the errors simply keep accumulating somewhere nobody was looking?

Compensation can hide deterioration. Nothing has to explode when the compensating mechanism disappears. Things can simply become progressively less right.

When expertise becomes dependency

There is another version of key-person dependency, and it is less comfortable to talk about.

I've seen this version play out in data-related corporate hierarchies, or organizational family trees.

One person manually applied group names to bundle information assets associated with distinct contractual terms under a perceived organizational family umbrella. It was detailed work, and over time that person became the person who knew how to do it “right.”

Others were trained, but concerns about the quality of their work kept returning the task to the same person. Management had other priorities, the existing approach continued to get the job done, and the dependency remained.

There were more scalable and accurate ways to solve it. I recommended several.

Meanwhile, technology teams reasonably assumed that the resulting data meant what it appeared to mean. It was streamed downstream without a sufficiently clear definition or use case attached to it, and the compensation began creating new problems elsewhere.

Sometimes organizations create key people without intentionally ever deciding to. The process works, the expertise concentrates, everyone adapts around it - and eventually the dependency looks like the process.

The person is still not the whole problem. The more useful question is what the organization has allowed that person to compensate for - and what it has rewarded along the way.

The spreadsheet is not the villain

The same pattern shows up without a hero attached to it.

I have a hard time joining the collective sport of blaming spreadsheets. A spreadsheet is often doing exactly what somebody needed it to do. (There will always be a soft spot in my heart, along with a wholehearted chuckle, for an old vendor story. They acknowledged that Excel was still the predominant data governance tool of choice - and arguably worked well for the maturity level of most organizations.)

Maybe two systems do not talk to each other. Maybe the official system cannot accommodate the way the business actually operates. Maybe definitions are still being negotiated. Maybe the process changes faster than the technology can. Maybe the organization has never decided which source should win when the numbers disagree.

So somebody builds a spreadsheet.

Then somebody else adds a tab. Someone creates a macro. A monthly reconciliation appears. Eventually the file has a name like FINAL_v13_REALLYFINAL.xlsx and everyone agrees it is ridiculous.

But replacing the spreadsheet without understanding what it is compensating for can simply move the workaround somewhere more expensive.

The spreadsheet is evidence. Before eliminating it, ask what job the organization quietly hired it to do.

The control that keeps catching the same problem

Controls can compensate too.

A problem occurs. The organization responds responsibly and adds a control. The control catches the problem again. And again.

At some point, the control may no longer be protecting the process so much as compensating for a process nobody has fixed.

I oversaw more than one data quality program where rule sprawl developed with the best of intentions. A new issue surfaced, so another rule was added. Then another team needed something slightly different, so another version appeared. Exceptions needed monitoring. Known problems needed controls.

Before long, multiple rules were testing essentially the same thing - sometimes producing duplicate results and sometimes producing different answers to the same underlying problem.

The control was out of control.

Reports made the quality of the data look worse than it was because the same underlying issue appeared multiple times. Rule outputs provided confusing, if not conflicting, guidance about what needed to be resolved. And eventually the people closest to the data started adapting too.

Analysts who were expected to perform self-checks before moving their work downstream would sometimes rather skip the step than deal with the headache of interpreting the results.

That's an important signal.

A control designed to improve data quality had become complicated enough that people were finding ways around the control itself.

The answer isn't necessarily fewer rules. And it certainly isn't to stop controlling for data quality. It's to ask whether the controls are still doing what they were designed to do - or whether years of individually reasonable decisions have accumulated into another form of compensation.

The control can be working exactly as designed while the control environment no longer works particularly well.

In my experience, it can take an external change to create the opportunity to challenge that accumulation. In one case, I was standing up a more formal governance capability and modernizing the data quality program. In another, a technology change forced us to reconsider which rules were actually worth carrying forward.

Some simply weren't as critical as they had appeared when they were first created. Collectively, they were creating so much noise in the quality reporting that it was becoming harder to get traction on the issues that actually warranted action.

We can get very good at detecting bad data without changing the conditions producing it. We can reconcile the same discrepancy every month. We can escalate the same exception every quarter. We can build increasingly sophisticated monitoring around a decision the organization still has not made.

That is an uncomfortable distinction because controls are measurable. Fixing what is underneath them is usually messier.

Of course every organization has workarounds

Of course it does. And no, not everything needs to be fixed. That is the furthest from the actual point.

When a problem or opportunity surfaces, it warrants an unbiased assessment of what is happening. Is the way you are operating today setting you up for future success - or future headaches?

A workaround that made perfect sense when the company was smaller, the volume was lower, the team was different or the technology was less capable may still be the right answer.

I've knowingly kept compensation in place too.

There were meetings I continued holding even when some of the reporting inside them could easily have been an email. On paper, eliminating the meeting might have looked more efficient.

But the meeting was doing another job.

It kept pressure on the people who needed to participate. It reinforced that building the capability mattered. And it gave me a way to see whether people were beginning to arrive prepared, take responsibility and exercise the authority expected of them.

Once that happened, the meeting had done its job.

Efficiency isn't always eliminating the workaround. Sometimes it's knowing why you're keeping it.

Ingenuity and resilience can backfire when nobody reassesses them as the organization evolves. But the goal is not a workaround-free organization. That would be its own kind of over-engineering.

The goal is knowing where the compensation exists, why it exists, what it costs, and whether it is still the right trade.

The workaround is information

I have written before that frustration is information. I think workarounds are too. They tell us where the organization has adapted.

That adaptation may have been brilliant. Many of the processes we eventually label inefficient started as somebody solving a very real problem with the resources, authority and information available to them.

That history matters. Because before we decide what to do with the workaround, it helps to understand what it was asked to solve in the first place.

So instead of starting with:

• How do we eliminate this?

• Who created this mess?

• What software should replace it?

Try teasing out:

What is this workaround compensating for?

That question takes us upstream.

Sometimes the answer is mechanical: a system limitation, a broken handoff, missing automation, a process that no longer fits the volume of work.

Sometimes it is about meaning: two teams are using the same word differently, the business has not agreed on the definition, or the outcome itself is not as clear as everyone assumed.

And sometimes it is behavioral: people have learned which shortcuts are rewarded, which decisions are safer to avoid, or who will step in if they wait long enough.

But I'd argue that most often it is some combination of all three.

A familiar reason compensation sticks

There is also the question of what the organization has done to reinforce the workaround.

If the person who saves the day gets praised, the project that finishes fastest gets celebrated, or the uncomfortable issue gets quietly parked, the compensation may be doing more than filling a gap. It may be learning how to stay.

But compensation doesn't require anyone to reward it. Sometimes it persists simply because it works well enough to keep the underlying problem from demanding attention.

If you're interested, turn to What You Reward, You Multiply to read more about how what happens next can teach an organization which behaviors to repeat.

Do not wait until after the next crunch

There will always be another crunch time.

And every time the workaround gets you through it, you gather more evidence that the workaround works.

That makes it remarkably easy to say, “We'll deal with this after things settle down.”

That dynamic reared its ugly head in What You Tolerate, You Maintain too.

Sometimes you need to feel a little of the pain now if you want the organization to prioritize avoiding a much bigger pain later.

Key-person risk. Scale. Cost. Repeated errors. A process nobody fully understands anymore.

None of those automatically means redesign everything. But combine them and you have a very good reason to start pulling at the thread.

You don't need to investigate everything

You don't need an inventory of every workaround in your organization. And you certainly don't need to investigate all of them.

Start with what the business is trying to do.

Are you trying to grow? Reduce risk? Enter a new market? Change the business model? Improve margins?

Then look for what is making that harder than it needs to be.

Pay attention to what your employees are already telling you. Not just what appears in a survey, but what keeps getting explained away or normalized.

And look for concentration. Where does the same friction appear across multiple teams? Where are several parts of the organization compensating for the same unresolved issue?

Those are good places to get curious.

Start with why

The intervention does not have to be sophisticated. In your next team meeting, take one of those recurring workarounds and ask:

Why do we continue to operate like this?

And don't accept "because that's our process" as the answer. Investigate more:

• Ask what problem the process originally solved.

• Ask whether that problem still exists.

• Ask what would happen if you stopped doing it tomorrow.

• Ask who or what would absorb the impact.

• Ask whether the workaround is helping you accomplish what you're trying to accomplish - or quietly making it harder.

You may discover that the workaround is still the smartest answer available.

Great. Keep it.

You may discover that it made sense three years ago and nobody has reconsidered it since.

You may discover that removing it would simply move the compensation somewhere else.

Or you may discover that what looked like a small inefficiency is actually carrying far more organizational weight than anyone realized.

The point isn't to eliminate every workaround.  It's to know which ones are still carrying a useful load - and which ones are carrying a load the organization should no longer be asking them to carry.

A workaround becomes dangerous when the organization forgets what it was working around.

Your business may have gotten very good at compensating.

The better question is whether it still needs to.