Management guides priorities toward the needs of the business, i.e. money, usually. You can sell and market new shiny things.

If you can’t quantify the boring necessary tasks with dollars and deliverables then don’t be surprised when you get “oh yeah whatever.”

I’ve had to fight so damn hard with my own teammates who rail on and on about tech debt but won’t do an ounce of lift to turn the kvetching into an actual business proposal. For some reason devs have such a hard time conceptualizing that they are also one of the stakeholders to the business.

Here’s one that I made happen.

“Setting up new 3rd party integrations takes $x hours of work (here’s the cards) costing roughly this much in engineer time. Based on our sales trajectory we expect to do this many next year costing this much. The team believes that if we develop a framework for these integrations we can cut the time spent for each one to this. Our metric for success will be measured by having a dev who didn’t work on the framework convert an existing integration in the test environment.”

I’ve never gotten a green light so fast from our product management.

This is great. I think there should be more resources that explain this dynamic and especially how to have productive conversations around tech debt with management.

The benefits of addressing some tech debt can be hard to quantify. An architectural change could enable you to add new integrations or otherwise build new features faster, but you can't always predict the magnitude I'm advance. I agree that some devs can exaggerate the importance of this though.

I still think you need to sometimes look at software as requiring some base level of regular maintenance funding, like a fleet of vehicles gets regular cyclic maintenance in any transport company.

It's true that they guide priorities toward the need of the business but it's also true that they don't. There's empire building, favors and horse trading to be done between managers. There's also battles to be waged for territory.

And while I do agree that's important to learn how to frame things in terms of the business benefit there are going to be things that aren't as simple to translate into a straightforward benefit and KPIs. If you're working on something that just increases developer happiness to help with things like general productivity and retention measuring the benefit for any one thing isn't always going to be feasible.

Every manager I've had apparently thinks making sure the Standards of Business conduct training being done before any other group has their SBC training done is the most important part of their business. Their second most important part is their bonus followed by lying to their employees about nonexistent funding cuts and the high-end of pay bands. I've had lots of managers, I've had managers I talk to multiple times a week and managers that I never spoke to but they all seem to have one thing in common and that's to get the most out of me with the least in return. It wasn't until I started looking at other position did I suddenly start getting merit increases and large bonuses, funny how that works.

It’s amazing how many managers want microservices and distributed even for something that’d fit on a single small instance (when done properly).

This can be true too.

I had a SVP keep pushing for an innovative approach to X. I told my boss it must be in her development plan.

My bosses laughed, but it’s true, even VPs have development plans and when the CEO tells them to do something “innovative”, well, they make sure they do it, feasibility or need be damned.