How to Get Tech Debt Prioritized

Dev Leader Weekly 144

Jun 15, 2026

TL; DR:

Decision-makers are detached from your code
“The code is a mess” never wins
Reframe tech debt as future velocity
Join me for the live stream (or watch the recording) on Monday, June 15 at 7:00 PM Pacific!

How to Get Tech Debt Prioritized

This week’s topic comes from a post on the ExperiencedDevs subreddit. A developer was asking for perspective on getting their manager to prioritize tech debt. It used to get prioritized, they said, but lately their manager keeps pushing back because the team needs to deliver features. If you’ve been writing software for any length of time, you know this one -- the age-old battle between shipping more things and making the code better. And if you haven’t hit it yet, it’s probably just about to happen.

You can check out my full thoughts on this in the video below:

This Is a Prioritization Problem, Not a Code Problem

The first thing I want to get out of the way is that this is genuinely tricky, and it’s tricky because it isn’t really one problem. It’s a prioritization problem, a communication problem, and a perspective problem all bundled together. If you’re more junior and this is happening to you for the first time, it’s easy to feel confused and frustrated by it -- like you’re clearly right and nobody will listen. So it’s worth slowing down and understanding what’s actually going on underneath.

Tech debt almost always accumulates the same way: a few things stack up, and whoever owns prioritization -- a product owner, an engineering manager, some combination of those roles -- has to make a call. And the more removed those people are from the code, the less direct understanding they have of how specific areas of the codebase affect your ability to ship. I don’t mean that conceptually. I mean very specifically: they are not going to know that this class or that module is the thing slowing you down, because they’re not spending time in there.

I’ll be honest about my own seat here, because it’s relevant. I’m an engineering manager at Microsoft -- I’ve been there just under six years, and I’ve been programming for over 20 years. But in my role, I don’t write code. It’s not that I’m not allowed to; it’s that there are enough other things I’m responsible for that it doesn’t make sense for me to spend my time there. So there are absolutely situations where I am simply not aware of where the tech debt is. I have to rely on and trust my team to bring it up. And when they do, I expect them to be able to articulate why it matters. That last part is the whole ballgame, and we’ll come back to it.

The Two Forces Working Against You

When you zoom out, there are two big forces shaping these conversations from the prioritizer’s side.

The first is constant pressure to deliver more, often with less. Before Microsoft, I was at a startup, and there it was a never-ending stream of “how do we get more things done?” There’s truly an infinite amount of work, and a lot of it feels like strategic bets -- things you’re not certain about but believe you have to try. At a big company, it’s a different flavor of the same thing: less uncertainty per bet, but a massive surface area of teams all pushing their own initiatives. Either way, the pressure is “more, faster.” I went deep on how that infinite pile grows as you get more senior in More Experience, More Overwhelmed.

Layer on the current climate -- hiring slowing down, teams shrinking, and the “we made a strategic pivot to AI, so where’s the 10x productivity?” expectation -- and the “do more with fewer people” drumbeat gets even louder. I hear this constantly: leadership bet on AI, and they’re relying on the people building things to show the return.

The second force is detachment from specific areas of the code, which we already talked about. Put those two together -- relentless delivery pressure plus distance from the codebase -- and you have the exact conditions where tech debt loses. Not because anyone is stupid or malicious, but because the people deciding are focused on shipping value to customers, and you’re handing them an argument about classes and methods.

How the Debt Actually Piles Up

Let me walk through the mechanism, because it’s so common it’s almost mechanical.

Say you want to build feature A in a one or two week window. The north star design is “do X, then Y, then Z.” If you did all of it properly, it might take a month or two. But you look at the window and go: we can definitely get X done, we’ll get partway into Y, maybe finish it with a tweak, and we will not get to Z. But that’s fine -- we’ll ship A on time and come back for Z next sprint.

So you ship. You got X, part of Y, and no Z. The feature works. You’re now in an intermediate state with a bit of debt baked in -- and then the question comes: what’s more important, the next batch of customer value, or going back to finish Z? If the feature already shipped and already works, finishing Z is almost never the higher-value option. If Z had been truly necessary, it would have blocked the release in the first place.

Now multiply that by every feature your team ships -- two, three, five, six of these at once -- and you can see how you just keep bleeding debt. I genuinely believe nearly every line of code we write is debt to some degree, but here I mean the specific, visible gaps you know you left because you took a shortcut to hit a date. And I don’t mean “shortcut” as an insult -- it’s often not “oh my god I can’t believe I wrote that.” It’s just “we didn’t get the full thing done, the feature works, and what’s left isn’t visible to the customer.” The frustration is that it keeps happening, sprint after sprint, and that constant churn is its own kind of tax -- closely related to the productivity drain I covered in The Context Switching Problem Every Dev Faces.

Why “The Code Is a Mess” Never Wins

Here’s where most engineers shoot themselves in the foot. The argument they bring sounds like: “As a software engineer, I think we should focus on this. Here’s why.” And every reason is about the code -- this class is convoluted, we hate touching this module, we want to refactor for cleanliness.

Now put yourself in the prioritizer’s chair. They’re weighing “spend a week rewriting some classes” against “fix these three critical customer-reported bugs and ship these two features the sales team can use to chase five new customers.” Why would they pick the cleanup? The framing was lost before the conversation even started, because it was built entirely around things they don’t focus on and can’t easily evaluate.

It’s almost like you’re set up to automatically lose. And that’s a genuinely lousy spot -- being forced to pit your tech debt against visible customer value, using the one language the other side doesn’t speak.

Actionable Tip -- Before you pitch tech debt, run it through this filter: strip out every reason that’s about the code itself, and see what’s left. If there’s nothing left, you don’t have a business case yet -- you have a preference. Keep digging until you can express the cost in terms of delivery, bugs, or time.

Reframe It in the Language of the Business

The move is to translate. Instead of “this code is a mess,” make it about speed, risk, and waste on the work they already care about.

Concretely, it sounds more like this: “This isn’t some legacy file we haven’t touched in four years and never will. We are actively in here right now. Two of the bugs this sprint are in this exact code, and we keep breaking it because it’s convoluted and we can’t test it effectively. If we slow down for a week and clean it up, the two features you want next -- which we already know live in this same area -- get easier. They’ll take half the time going forward, and we’ll stop bleeding these recurring bugs.”

See the difference? You’ve connected the cleanup to future velocity, reduced bugs, and less wasted time -- and you’ve anchored it to specific upcoming work the prioritizer has already hinted at. You’re not asking them to value clean code. You’re showing them how the debt is actively taxing the roadmap they care about. That’s the same spirit as deciding to talk to your manager about burnout -- don’t lead with the vent, lead with the pattern, the impact, and what would actually help.

The more you can express tech debt as “this will speed us up on related work” or “this will stop these bugs that are clearly hurting our velocity,” the better your odds. “The code is a mess” is a feeling. “This is costing us two bugs a sprint and doubling the time on the next three features in this area” is a business case.

The Manager’s Side of the Table

I want to address the manager dynamic too, because the original poster felt their manager was the obstacle. From where I sit, an engineering manager carries real responsibility not to turn the business’s delivery pressure into a crippling weight on the team. A good manager absorbs a lot of that and provides some shelter -- not by hiding it entirely (the team should understand the context), but by refusing to amplify it. Amplifying pressure isn’t productive and it isn’t helpful.

That shielding role is exactly what I dug into in The Management Trap in Software Engineering -- a lot of management is absorbing chaos so your team can stay focused. But there’s a real risk in being the person who soaks up everything, which I broke down in The Hidden Cost of Being the Team Hero. The point for you as the engineer: your manager is very likely getting this pressure from above, and your job in that conversation is to make it easy for them to advocate for the cleanup to their stakeholders. Hand them the business case, not the complaint.

The Hard Truth: Some of It Will Never Get Done

I’ll close with the uncomfortable part, because pretending otherwise doesn’t help anyone. My entire job is prioritizing things, and at the end of the day you have to accept that some things simply will not get done. There is an infinite amount of work -- I have business-critical features to ship for my teams before you even get to tech debt or bug fixes -- and it is quite literally impossible to do all of it.

That means some of the stuff you talked about, planned, and said “oh, we’ll get to it” about may genuinely never happen. And honestly? That can be completely fine in the end. The skill isn’t getting everything done; it’s relentlessly ordering things by value and working through them, accepting that the bottom of the list might never come up. If that constant triage is wearing you down, you’re not alone -- I wrote about that exact feeling in ADHD, Burnout, and Building a Career That Fits Your Wiring.

So find the opportunities to bring tech debt up, and organize them from the perspective of the person doing the prioritization. What will make it clear to them why it’s valuable? That means framing it around value to them -- not value to you. It’s a frustrating thing to navigate, but reframing your perspective makes it a whole lot easier.

If you’ve got a specific situation you’re wrestling with, you can submit it anonymously over at codecommute.com and I’ll try to make a video response.

Dev Leader Weekly

Discussion about this post

Ready for more?