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.