Tech debt is more of a cultural problem than a technical one
Looking beyond the code to see where debt really begins.
Most conversations about tech debt go nowhere.
You’ll hear about legacy code, refactoring cycles, outdated frameworks, or systems that were never meant to scale as fast as they did. The discussion usually sits squarely with engineers or systems teams, as if it’s purely a tech problem.
In practice, tech debt is almost always cultural. It’s the by-product of leadership decisions, incentive structures, and the way different teams talk to - or ignore - each other. If you look closely, the code or system quirks are just symptoms. The root cause is cultural.
The textbook definition misses the point
Tech debt is often described as the gap between doing something properly and doing it quickly. A shortcut taken today that builds up “interest” tomorrow. That’s true in theory, but it misses how decisions are actually made in commerce businesses.
The reality is that shortcuts don’t just happen in the code. They happen in trade meetings where the push for a campaign date trumps system readiness. They happen when finance signs off a budget but refuses to resource the ongoing maintenance. They happen when a new channel or market launch is announced before the operations team has mapped out fulfilment.
By the time the code is written or the ERP customised, the debt is already baked in.
Three cultural sources of tech debt
1. The obsession with speed
“Launch now, fix later” is a cultural mantra in fast-growth environments. It’s understandable; markets move quickly, competitors are relentless, and opportunities are fleeting. But when speed becomes the only KPI, debt becomes inevitable. The problem isn’t moving fast; it’s that speed is pursued without accounting for the clean-up. Maintenance and refactoring never get prioritised because the culture doesn’t reward it.
Fail to cleanup repeatedly, and it massively impacts your speed. In time, the net result of prioritising speed over quality is slower pace. Painful truth.
2. Ownership gaps
One of the most common patterns is blurred ownership. Marketing wants flexibility. Ops want stability. Systems/Tech wants clarity. Finance wants predictability. When no one owns the end-to-end system, everyone assumes someone else is accountable. Debt accumulates in the gaps; in half-finished integrations, in manual workarounds, in “temporary” spreadsheets that somehow run critical processes years later.
3. Incentives that reward the wrong outcomes
Teams are praised for shipping features, cutting costs, or driving revenue. Rarely are they rewarded for reducing friction, eliminating complexity, or tidying up legacy systems. As a result, maintenance becomes invisible work. Teams quietly firefight around debt because they’re not incentivised to remove it. Leadership then assumes everything is fine, until the cracks appear at peak trading.
When cultural debt becomes customer pain
The interest on cultural debt shows up in places customers can feel.
Returns processing that takes weeks because the system wasn’t built for two-way flows.
Stock levels that don’t match reality, leaving shoppers frustrated at oversold items.
Checkouts that falter under peak load because scalability was never properly planned.
These aren’t abstract “technical” issues. They’re cultural choices that degrade the customer experience and erode trust. The irony is that the same culture that prioritised speed in the first place often ends up slowing the business down later.
Fixing tech debt without touching the code
Cultural problems require cultural solutions. You don’t start by rewriting systems; you start by rewriting how decisions are made.
Set clear ownership. Every critical process needs an accountable owner who has the remit, and budget, to maintain it.
Align incentives. Celebrate teams who prevent fires, not just those who put them out. Reward the reduction of friction as much as the launch of a new feature.
Bake maintenance into the roadmap. If there’s no space for debt reduction in planning, it will never happen. Treat it as a standard cost of doing business, not an optional clean-up exercise.
Encourage long-term thinking. Leaders need to ask: “What’s the cost of this decision in 18 months?” rather than “How fast can we ship this?”
None of this requires a single line of code. It requires a shift in culture, a willingness to slow down in the right places, assign accountability, and recognise that sustainability is as valuable as speed.
Closing thoughts
Tech debt isn’t something developers sneak into the system when no one’s looking. It’s something leaders, managers, and teams collectively create through the culture they set. If you only see it as a technical problem, you’ll treat the symptoms and miss the cause.
Commerce businesses that want to scale without collapsing under the weight of their own decisions need to accept that tech debt is cultural first, technical second. Fix the culture, and the systems will follow.