A few years ago, I was helping untangle an integration between two business systems.
Nothing unusual there.
Systems evolve. APIs change. Businesses grow. Integrations need attention.
Then we hit a simple question:
“Why does this specific customer never get synced?”
Silence.
Someone kinda sorta remembered that it was probably an old bug.
Another thought, it might have been a request from the head of sales.
A third person remembered that a developer had intentionally excluded it years earlier, but couldn’t remember why.
Eventually, someone shrugged and said, “Let’s just leave it. It’s working.”
Except it wasn’t.
Nobody knew whether it was working because it was correct or because everyone had become afraid to touch it.
I’ve seen versions of that conversation more times than I can count.
Not just around integrations.
📊 Around reports.
💬 CRMs.
🧮 Pricing models.
⚡️ Automations.
☑️ Approval workflows.
🔐 Permissions.
💻 Even entire products.
Somewhere along the way, the original reason disappears.
The business keeps moving, but the understanding doesn’t move with it.
We have a name for the accumulation of shortcuts in software.
Technical Debt.
I’m starting to think we need a name for accumulated shortcuts in understanding.
Context Debt.
We lose context much faster than we realize
Businesses change constantly.
People join.
People leave.
Platforms are replaced.
Processes evolve.
Vendors come and go.
Projects finish.
Meetings happen.
Decisions get made.
Very little of that context is captured.
Instead, it lives in Slack messages that nobody can find. In meeting notes that nobody reads. In the head of the operations manager who’s been there for eight years. In the consultant who finished their project eighteen months ago. In the engineer who moved on to another company.
Every time that happens, a tiny piece of understanding disappears.
Not enough to break the business. Just enough to make the next decision a little harder.
Context Debt doesn’t announce itself
Technical Debt is often visible.
Performance slows down. Systems become fragile. Developers avoid certain parts of the codebase.
Context Debt is quieter.
It sounds like:
“That’s just how we’ve always done it.”
“I wouldn’t touch that workflow.”
“I think there’s a reason for it.”
“I’m not sure who built that.”
“It was before my time.”
Nothing appears broken. Until someone wants to improve something.
That’s when Context Debt starts charging interest.
Projects take longer because people spend weeks rediscovering old decisions. Consultants repeat work that was already done. New employees relearn lessons the business already paid to learn. Teams become reluctant to change anything because nobody fully understands the consequences.
The cost isn’t measured in bugs.
It’s measured in hesitation.
This isn’t a documentation problem
The obvious response is, “We just need better documentation.”
Documentation helps. But documents rarely capture why.
They explain what a workflow does.
They don’t explain why it exists.
They describe the integration. Not the customer who requested the exception. Not the commercial decision behind it. Not the workaround that became permanent after a vendor delayed a feature by six months.
Context is richer than documentation.
It’s the collection of decisions, conversations, trade-offs, and experiences that explain how a business actually operates.
Why I think this matters more than ever
For years, businesses could get away with losing context.
Eventually, someone figured things out. Especially when you hire amazing people.
Today, that context is becoming a competitive advantage. Businesses are integrating more systems than ever. Automation is becoming standard. AI is beginning to participate in operational decisions.
Every one of those initiatives depends on understanding how the business works, not just what data it stores.
The companies that preserve that understanding will move faster. The ones that don’t will keep paying to rediscover it.
Maybe we’ve been measuring the wrong kind of debt
Technical Debt matters. It always will.
But I wonder if we’ve been paying attention to the wrong thing.
Most businesses don’t struggle because their software is impossible to change.
They struggle because nobody remembers why it was changed in the first place.
That’s a different kind of debt.
And unlike Technical Debt, it doesn’t belong to the engineering team.
It belongs to the entire organization.
I think we’re only beginning to understand how expensive it really is.