Engineer's guide to convincing your Product Manager to prioritize technical debt

Another way of looking at this is hiring Technical product managers, aka, folks who have moved to product management from software engineering. This automatically means you have engineers and product managers talking the same language from day one and you don't have to package tech debt as "value propositions". Being software engineers themselves, the PMs at our company usually have a good understanding of when to move slow now (to move fast later), when it's acceptable to apply band aid fixes to keep the ship moving forward or when it's "everything is on fire, this needs a complete rewrite!" time

especially when technical debt originates from unknown or forgotten business requirements. Shouldn't take apart the toaster when its actually a microwave because that may actually kill us.

Hah, if only. My last PM position I was right there with engineering pushing for this. Our issue was convincing the C-suite, who were more nervous about our PE owners wanting to divest in 2ish years, so were in full "fatten the pig for market" mode, believing technical stability and foundations could be the problem of the new owners. And then getting frustrated at PM and Eng because roadmap items took longer to deliver because of the complexities or other issues surrounding tech debt.

This is kind of a weird one. Like, this isn't bad advice for advocating for yourself in general, and it's a far sight better than the approaches that I have seen at a lot of companies (i.e. "complain loudly enough until they give in" or "never, we just never address technical debt and we hope that doesn't come back to bite us"), but even still, I read this and I get the vibes of a dysfunctional organization hiding behind the scenes. Engineers shouldn't _have_ to try to beg, borrow, and steal time to work on technical debt. Moreover, "technical debt" in this article seems like it's being used more as a synonym for "crappy code" than the actual original debt metaphor -- there's no discussion of "interest" (i.e. accumulated costs over time), or payoff events (cases where the debt comes due all at once), or important business milestones (which can drastically affect whether you can even afford to pay attention to technical debt at this time), etc.

Honestly, this shouldn't be something that non-leadership engineers should be concerned with at all. They should be working with engineering leadership to ensure that technical debt is identified and classified, so that engineering leadership can work with product leadership to prioritize the payback of technical debt at an appropriate time, in the appropriate order. Trying to solve this problem at the level of individual teams and individual PMs means that the larger scope of the business's needs aren't available to be considered. Is there a funding round coming up? A big partnership announcement? A hiring round? A hiring freeze? You don't know, and you won't necessarily be told, even if you ask.

On top of that, the standard of measurement for improvement is flawed. The article is suggesting that "technical debt" as a whole is doubling the amount of time it takes to do features, but that's just not the way it works. Technical debt isn't just "crappiness of your codebase" -- you'll never solve that, no codebase is perfect. Technical debt should be tracked as individual, specific issues that will have specific negative effects (the database doesn't have appropriate indices and will get slower over time causing increasing performance issues, the version of the third-party API we're using is being deprecated and if we don't upgrade, we'll have a production outage, our User class has grown out of control and any feature that touches it effectively touches most of the app, causing bugs to appear at a much higher rate and slowing releases of these features, etc). I'm summarizing because this is already a long comment, but these issues should be even more specific than that: you need to describe the issue, the cost to fix it, the pain it's causing now, the pain it will cause over time and what that time frame is, and if there's any events that will require you to have the debt solved Or Else. Talking about technical debt with this information available gives concrete information about why it's valuable to solve. Talking about it with "we will move 2x faster" is unlikely to convince anyone, because software development isn't that reductive. You cannot guarantee that flat, project-wide improvement, and people will remember the time they spent three months not building features for no benefit they can understand.

I feel like the approach specified in the article will work -- at best -- once. A lone engineer doesn't have access to sufficient information to truly make a case for why this is a good time for the repayment of a particular piece of technical debt, can't see the full spread of potential technical debt that _could_ be solved and should be considered, can't adequately convince people as to the benefits of having resolved the technical debt, and honestly shouldn't be spending their limited political capital trying to get their personal pet peeve fixed. If technical debt isn't getting fixed appropriately, that's an engineering leadership issue, and you should be working with engineering leadership to try to help them understand any debt they're not aware of so it can get prioritized appropriately, and then afterwards, work with them to make sure that the specific, visible improvements and "catastrophes avoided" are recognized and respected.

That's only if the engineer doesn't have it previously documented in writing, on record, that any delays are due to the mess, and that the mess needs to be fixed the right way. It certainly should not come as a surprise. This is what I meant by "inform them".