I agree with a lot of this article, but I think it underestimates how much time it takes to properly prioritize good software practices against the business nee

I agree with a lot of this article, but I think it underestimates how much time it takes to properly prioritize good software practices against the business needs. There's the trivial case (the DB is down, nobody can log in) where they're aligned, but there's a lot of other work where it's not obvious what's the most important thing to the business. This is why PMs have jobs. For every deep, hard-to-understand drag on feature velocity based on technical debt, there's a deal that's going to make the renewals team miss the quarter because of a missing feature deadline. Balancing those against each other is apples to oranges, so it's impossible to make everybody feel great about that. A friend recently suggested that the way to do this is pre-arrange a schedule for "quality". Dedicate 30% of dev time to maintenance / debt / refactoring / whatever you want to call it, then stick to that. I think this is a more pragmatic way to approach it, because otherwise you're asking every engineer to understand the whole of the business at every Scrum meeting. Not only is that intractable, I know plenty of engineers who don't want to think about the plight of sales / marketing / renewals. Let the PM do their job prioritizing features for them, and let the engineering team prioritize and work on quality.