> And no manager is able to justify spending the extra few days to automate something correctly or "get it right" because there's always pressing product work t

> And no manager is able to justify spending the extra few days to automate something correctly or "get it right" because there's always pressing product work to do. Product people aren't reviewing your code and infrastructure. The manager is responsible for the speed and quality of their team's delivery, so if they have the team devote some time to polishing their tools, they're just using their professional technical expertise to keep things running smoothly for the product folks. They do need to be good at it - not overseeing a bunch of feel-good but not-actually-that-useful rewriting and cleanup - but that's a question of competence more than responsibility. It's a very similar thing with rotating people. A manager is going to get into trouble sooner or later if they only ever have the same people work on the same systems. It's the short-term optimization, but not the long-term one. And that doesn't mean nobody can be an expert in an area, but it's bad if only one person is able to work in that area. A company that wouldn't let a technical manager make the call on that - who works on what, and how much to attention to pay to their tools - may as well have the devs report directly to the product manager. The manager has to stand up for that and not just be steamrolled.