This makes a lot of sense - but how? By definition, management does a different job from individual contributors. How do you make a manager feel the pain of a messy code base, for example?
- bugs that customers complain about.
When asked for why you can explain how the messy codebase is causing problems and how there no bypassing it.
I've seen this in a big medical equipment company where the CEO made a whole speech about how he now understands how legacy codebase is making our work very difficult, it caught me by surprise to see a C level bring up the topic.
Like some IT version of ‘the whippings will continue until morale improves’.
More realistically it was caused by those messages, but with a 4 year lag time, back in the days when the CTO decided to start the project from day 1 with a team of "senior" consultants that were all "full stack" and "excited to learn AWS".
However that doesn’t mean it will be invested in. Clean Vs messy are binary descriptors that devs love to throw around. A lot of time messy code is not worth fixing. Managers have to make judgement calls. But what they should always let you do is marginally improve the code each time you’re in it, and especially let you invest in test coverage.