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

Snipe/nitpick: start with the topic at hand before using the phrase "Let’s get back to this week’s thought."

You never started. Full page ad right out of the gate. Pass.

Jokingly: my problems compound, now procurement/finance needs convinced?

Somewhat Seriously: Please tell me the revelation is deeper than "have data, buy it from my friend"

I think best is not to ask the product manager for permission to address technical debt but to do it as a regular part of the job. And it's better to do this in an ongoing manner vs letting it pile up until nothing works anymore.

Quantifying the improvements you get from addressing technical debt is a losing game. Most likely you will have to bullshit some numbers together.

I think this is all good advice when you're working with a PM who is making some reasonable forms of semi-objective decision making.

None of this is helpful when your PM has no business strategy to align with, prioritizes based on what's going to make them look good, and sheds responsibility to the developers when things aren't going well.

It makes me wonder, if you're working with a PM who would even consider the information in the article, would you have to gather it for them?

The PMs who I've work with that conscientious as such already have some grasp of the problem. They see slow delivery of features, bug reports, and listen to the engineering team moaning. They get out of the way on stuff they aren't qualified to decide on. They just make sure that tech debt work stays within a reasonable scope and time budget.

You shouldn't have to "convince" anyone, only to inform them. If they don't trust you to look after the software, they will ultimately get what they deserve, which is a software that doesn't work and is unmanageable beyond repair. As an engineer, your job is to do engineering, not to engage in people manipulation. My policy is to not protect evil manifested as product-greed. Sometimes it's better to let it burn.

Most technical debt is imagined at lower experience levels. Shitty and brittle code is not inherently debt - it’s only debt if you have to pay it back to get something else you want. Otherwise it’s “free money”.

Debt is garbage that fights you every day in delivering project goals. Everything else doesn’t need to be addressed now, or maybe ever. Write down what limitation it might introduce and move on. Just hope you have the history and experience to properly solve that problem later - it’s either on the project maintainer or business, and they are only good at their job if they know which will matter.

I have an internal rating scheme I use to classify debt based on risk / lost opportunity:

1. Efficiency

2. Feature Quality

3. Growth

4. Continuity

Efficiency projects lost productivity to the development team. It should eventually be addressed or you will lost momentum in hard to measure ways. Examples: Developer tooling issues, lacking documentation, failure to reach consensus, stable code with suboptimal API design.

Quality projects continuous customer impact due to bugs within certain vertical areas. Examples: Poorly coded features at the “leaves” of your code that don’t affect other areas but block improvement of itself.

Growth projects failure to meet a subset or all future deliverables. A failure is defined as anything that doesn’t meet required timelines to capitalize, or becomes downright impossible. Examples: Bad system architecture, data modelling, shared component that cannot scale to planned future requirement.

Continuity means what we currently have is going to fuck us at any moment. It’s a time bomb that gets worse passively. Examples: Security, major vendor deprecation, declining system stability.

Many developers I’ve worked with have never bothered to categorize debt, which is their fault. Many gravitate toward 1 and 2, but 3 and 4 are true debt today. The others may or may not evolve into 3 and 4 over time. You keep an eye on them but don’t argue about them until they will definitely become 3.

This is easy because a 2 flips to a 3 as soon as the code is even talked about being shared, or if it’s DX related and you’ve been asked to stretch it to the point productivity can be predicted to measurably decline. Come with numbers to prove your case, it will become easier and the evidence based approach plays much better than feelings and complaining.