[rqtwteye]

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.

[bravetraveler]

+1. If the feature or whatever is delayed because of 'hurdles'... sorry, technical debt, the business is lucky I'm here to deal with it.

The PM wasn't hired to make these decisions, they will not be required [for this]. Error budgets, delivery, operations, and what I see when I open my editor are all core to my job description. I'll refactor it/have my team do so... and argue with others about why we shouldn't at the same time.

I know this isn't ideal, I don't care - that's why I'm here. I've worked with too many people who internalized the field sabotage manual. I've been hired, promoted, and stolen for my ability to cut through nonsense.

My role (SRE) was made as a consequence of institutionalized technical debt. It provides nothing really new, hopefully picking up slack [that others created] while avoiding unproductive feedback loops.

This scene from "Breaking Bad" comes to mind. Apologies for the language, the character is known for it:

    Chemist: Who do you think you are?
    Jesse: I'm the guy your boss brought here to show you how it's done. And if this is how you run your lab, no wonder. You are lucky he hasn't fired your ass. Now, if you don't want that to happen, I suggest you stop whining like a little bitch and do what I say.

I have, and will, write RCAs for the roles we [and our technical debt] played in outages. I've published more of my product than any given development team, let's try.

[NAHWheatCracker]

Sadly true.

In the time spent gathering believable information to present, you could probably address a reasonable number of small tech debt items.

Large tech debt items probably can't be resolved without some major business-impacting issues. At which point, you might rather not be around.

Regarding bullshitting numbers, I think it's especially a losing game when you are presenting numbers to more experienced professional bullshitters.

[manvillej]

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.

[rqtwteye]

"I think it's especially a losing game when you are presenting numbers to more experienced professional bullshitters."

I think pro bullshitters know it's all BS. The real problem are the people who haven't realized that yet :-)

[j45]

Seeing it as risk is important. If they choose to overlook it, it's being clear that its not being held responsible for things going bad by doing what is asked (something different).