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&#x27;s the trivial case (the DB is down, nobody can log in) where they&#x27;re aligned, but there&#x27;s a lot of other work where it&#x27;s not obvious what&#x27;s the most important thing to the business.<p>This is why PMs have jobs. For every deep, hard-to-understand drag on feature velocity based on technical debt, there&#x27;s a deal that&#x27;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&#x27;s impossible to make everybody feel great about that.<p>A friend recently suggested that the way to do this is pre-arrange a schedule for &quot;quality&quot;. Dedicate 30% of dev time to maintenance &#x2F; debt &#x2F; refactoring &#x2F; whatever you want to call it, then stick to that. I think this is a more pragmatic way to approach it, because otherwise you&#x27;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&#x27;t want to think about the plight of sales &#x2F; marketing &#x2F; renewals. Let the PM do their job prioritizing features for them, and let the engineering team prioritize and work on quality.