Last week I joined a panel hosted by Christoph Beckmann on the topic of tech debt. I spoke about how it's defined and how to approach it because it consistently ranks among the top three reasons engineers leave companies or the reason companies fail.

What struck me during the discussion was how tech debt perfectly captures my frustration with the artificial divide between tech and "the rest" of the company. Maybe that's just confirmation bias talking. Either way, this is an opinion piece.

Let's zoom out briefly. When I say "tech and the rest," tech is obvious. But "the rest" needs clarification. I'm not dismissing it - in fact, quite the opposite. "The rest" is the business. Tech, however, often doesn't see itself as part of it.

Phrases like "that's a business decision" or "business stakeholders want this" are common in tech and quietly reinforce this split. The underlying belief: tech is separate. An island. But this mindset isolates teams and individuals, and it hurts both company outcomes and employee satisfaction.

I made this mistake myself at Lieferando.de. As CTO, I expected everyone to understand tech jargon but made little effort to understand the language of other departments. I didn't learn their numbers or how their parts of the company worked. That arrogance led to isolation and a limited grasp of the broader business.

This same mindset also explains much of how tech debt accumulates - and why it's misunderstood.

Tech debt is often used by engineers to influence prioritization. It works, in part because articles constantly warn that tech debt kills innovation and companies alike. The term rattles execs, whether seasoned or new. But because the label is so powerful, it's also misused. Teams overpromise the benefits of fixing it - faster delivery, better quality, more agility - and when those don't materialize, trust erodes. Eventually, leadership starts to see tech debt work as a morale play: time spent to keep engineers happy.

That's the wrong lens.

I treat tech debt as a system constraint - part of the business system, not just the tech stack. This isn't about code smells flagged by tools. It's about what slows you down in areas where change happens often. If a part of the system rarely changes, it's not slowing you down. That kind of debt accrues no interest. Leave it alone.

Engineers should meet the same expectations as anyone else: justify investments with numbers. If you can't quantify the ROI, the issue isn't measurement - it's that there's no company-wide definition of engineering performance. Most of the time, fixing tech debt should improve that. So measure it.

Lastly, I stick to a simple rule: the Scout Rule. Leave the place a little better than you found it. Clean the code you touch. Make it easier for the next team to set up camp. If no one does this, eventually you'll need a full shutdown just to restore order - and that costs revenue.

My principles on tech debt

• 1️⃣ It only matters in areas of frequent change
• 2️⃣ ROI must be measurable—no exceptions
• 3️⃣ Fix it alongside priorities, never as a separate project

But more importantly, please stop calling anyone but tech the business: You are the business!!!