Technical Debt Isn’t a Code Problem. It Never Was.

You know that feeling? The one where your team is shipping features just as fast as last quarter — maybe faster — but everything feels heavier. Every PR takes longer to review. Every deploy carries a small prayer. Every new feature breaks two old ones you forgot existed.

You’ve probably blamed the code. Maybe you blamed the engineers. Maybe you blamed Agile, or the lack of tests, or that one senior dev who left without writing documentation.

You’re looking at the wrong crime scene. Technical debt isn’t written in code — it’s baked into who you hired and what you asked them to do.

Let me tell you a story.

Imagine a company that needs to drive ten thousand screws. Not today, not tomorrow, but continuously, forever, because that’s the business. They put out a job listing: Screwdriver Driver Wanted. Must be fast. Must deliver.

They hire a guy — let’s call him Mike — who’s incredible with a screwdriver. Seriously, the best you’ve ever seen. He drives screws by hand faster than anyone on the team. Management loves Mike. Mike gets promoted. Mike trains new hires in the art of the screwdriver.

Here’s the thing nobody asked: Why are we using screwdrivers at all?

The real problem was never “drive screws fast.” The real problem was “join these materials together reliably, at scale, forever.” A power drill solves that in a way no amount of screwdriver skill ever will. But nobody defined the problem that way. They defined it as a speed problem, hired for a speed problem, and optimized for a speed problem.

Now the company has a warehouse full of screwdriver drivers. They’re all working hard. They’re all well-intentioned. And the system is getting slower, not faster, because every new screw is harder to reach, every joint is slightly misaligned from the last, and nobody has the tool — or the mindset — to step back and say, “We need a drill.”

This is your engineering organization.

The screwdriver driver isn’t a bad engineer. He’s the wrong engineer, hired for the wrong reason, solving the wrong problem.

Think about your last three hires. Did you define the actual problem — the one that’ll exist in eighteen months, not the one that exists in this sprint? Or did you write a job description that essentially said: “Must be productive immediately. Must ship fast. Must not slow us down”?

You hired screwdriver drivers. And now you’re surprised the system is full of screws that can’t be unscrewed.

Here’s where it gets painful. The usual fixes for technical debt — more code reviews, stricter linting, better test coverage, architectural decision records — none of them touch the root cause. They’re like buying Mike a nicer screwdriver. Ergonomic grip. Magnetic tip. It’s still a screwdriver.

You cannot code-review your way out of a hiring problem. You cannot refactor your way out of a requirements problem.

The compounding feedback loop works like this: Product management defines requirements in terms of features and deadlines, not in terms of the system’s long-term shape. Engineering hires for immediate productivity against those requirements. The hires produce code that meets the short-term need but creates long-term friction. The friction slows down delivery. Product management responds by tightening deadlines and demanding more features. Engineering responds by hiring more people who can deliver fast. More screwdriver drivers. More screws. More friction.

Everyone is doing their best. Everyone is making the problem worse.

I’ve watched this happen in startups and in enterprise teams. The symptoms are always the same: velocity charts that look fine but feel wrong, engineers who burn out trying to maintain a system nobody fully understands, and a creeping sense that the codebase is somehow rotting from the inside even though everyone is following best practices.

The codebase isn’t rotting. The decision-making is.

Every quick fix isn’t just a nail in the coffin of future productivity — it’s a hiring decision you haven’t made yet, disguised as a line of code.

So what do you actually do?

First, redefine the problem. Before your next hire, ask: what will this person need to do in two years, not two weeks? If the answer is “the same thing but faster,” you’re still thinking in screwdrivers. The real answer should describe a system that evolves, a person who can rethink the approach, not just execute the current one faster.

Second, change the requirements conversation. Product managers aren’t villains here — they’re operating under the same misaligned incentives. But someone needs to ask, at the planning stage: “What does this feature cost us in system complexity? What does it prevent us from doing later?” If nobody’s asking that question, you don’t have a technical debt problem. You have a requirements problem wearing a technical debt costume.

Third, stop treating technical debt as an engineering conversation. It’s an organizational one. The moment you frame it as “engineers need to write better code,” you’ve lost. The moment you frame it as “we keep hiring people to solve yesterday’s problem with yesterday’s tools,” you’re getting somewhere.

The system you have today is the system your hiring process was always going to produce. Change the hiring. Change the system.

Mike isn’t coming back to save you with a better screwdriver. It’s time to buy a drill — and to hire someone who knows the difference.