Those are indeed the two possibilities. But L6->L7 is not done within a single org but instead is a set of company-wide committees, so if it was just our org being supportive of this sort of work then we'd see people hit a wall at L6. But they don't. This is what makes me convinced that committees actually do care about this stuff.
I find that there are two problems that contribute to this belief system.
1. People believe that doing the same work for more time should get them promoted. "Doing maintenance" can mean a variety of things and simply clearing minor issues until the end of time is not necessarily actually changing the landscape of technical debt. Something about the state of the world needs to change or the work is just large scale bikeshedding.
2. People are often truly terrible at measuring the results of their work. This introduces a bias towards launches and new products because their impact is often very easy to measure (there have been processes put in place to resist this force with various degrees of success). But I have seen cases where somebody's work on debt and maintenance is measured by "total number of changes" with zero evidence that the changes are actually useful or valuable. Even just getting some leaders to write down "trust me, this is important" would go a long way and people still fail to do this. Then people complain that their work isn't being valued when that was never the problem.
I do think this is one space where my org has an advantage. Because we do this sort of work so frequently, managers are good at helping their reports measure the actual quality changes in the codebase and build an argument that the work was meaningful.
I also agree that UncleMeat is definitely not one of Zappa's best but I didn't think too carefully about the nic when I created it.
#2 does indeed sound like a huge potential source of problems. "Total number of changes" is a terrible metric.
It blows my mind that there are some major issues with Gmail that haven't been fixed - for instance, if I find a message in my Spam folder that isn't spam and mark it as such from inside the message, it instantly disappears from my spam box and the view returns to the spam folder view instead of staying on the message. The message is now marked as Read so I can't find it by going to my inbox and viewing unread messages, and I can't use the browser's back button to navigate back to it because when it's out of spam it gets a different URL. So I have to remember exactly what I was looking at if I want to go back and find it. It's a hugely inconvenient UX made even worse by the fact that Gmail flat-out IGNORES my whitelisting certain email addresses from people I work with, so I'm always digging around my Spam folder looking for stuff they say they sent me that didn't land in my inbox.
Uncle Meat may not be Zappa's best albums, but it's definitely one of his best and most catchy album names.
I find that there are two problems that contribute to this belief system.
1. People believe that doing the same work for more time should get them promoted. "Doing maintenance" can mean a variety of things and simply clearing minor issues until the end of time is not necessarily actually changing the landscape of technical debt. Something about the state of the world needs to change or the work is just large scale bikeshedding.
2. People are often truly terrible at measuring the results of their work. This introduces a bias towards launches and new products because their impact is often very easy to measure (there have been processes put in place to resist this force with various degrees of success). But I have seen cases where somebody's work on debt and maintenance is measured by "total number of changes" with zero evidence that the changes are actually useful or valuable. Even just getting some leaders to write down "trust me, this is important" would go a long way and people still fail to do this. Then people complain that their work isn't being valued when that was never the problem.
I do think this is one space where my org has an advantage. Because we do this sort of work so frequently, managers are good at helping their reports measure the actual quality changes in the codebase and build an argument that the work was meaningful.
I also agree that UncleMeat is definitely not one of Zappa's best but I didn't think too carefully about the nic when I created it.