Yes, the people who set the priorities have to feel the pain in some way. If you as an employee want your boss to do something, you have to communicate it in a way that makes clear how the problem will affect what the boss cares about, not what you care about. Usually that means translating it into dollars or one of the boss's KPIs, like deployment frequency or support ticket volume.
Sometimes management doesn't prioritize problems because they're short-sighted or overwhelmed. But sometimes it's because they just don't understand how big a problem it really is, and the team fails to communicate it to them effectively.
For example, I've heard devs complain about how "the tests take too long." On one team I was on, a couple junior devs were complaining about this, but it turned out that "too long" meant five minutes. Could they be more efficient? Maybe, but getting that down to one minute would take a lot of work with no impact on our ability to develop and deploy multiple times per day. Once I showed them how to run their tests locally on just the files that changed, the problem was solved. But before that, they thought the problem was "technical debt," when really it was just a training issue. (Or, you know, a lack-of-ability-to-Google issue, but I'm trying to be generous.)
On another team, when I heard this complaint, the team explained that the full test suite took almost an hour, and flaky tests meant that they often had to rerun the tests or merge with failing tests. Needless to say, this had a clear impact on our ability to deliver rapidly with high quality, so this was something I prioritized.
Managers don't do the same work as you, so they don't feel the pain firsthand. And they're often not incentivized to care about the same things as you, at least on the same scale. As an IC, you tend to be focused on the next task at hand. The manager is thinking about their quarterly OKRs or whether the team is on track to meet their sprint commitment. If you want something to change, you have to connect the problems you have on the micro scale to the problems the manager cares about on the macro scale.
And if you can't do that, or your manager won't listen, then yeah: let the problems bubble up until the manager feels the pain, as long as it won't come back to bite you.
Sometimes management doesn't prioritize problems because they're short-sighted or overwhelmed. But sometimes it's because they just don't understand how big a problem it really is, and the team fails to communicate it to them effectively.
For example, I've heard devs complain about how "the tests take too long." On one team I was on, a couple junior devs were complaining about this, but it turned out that "too long" meant five minutes. Could they be more efficient? Maybe, but getting that down to one minute would take a lot of work with no impact on our ability to develop and deploy multiple times per day. Once I showed them how to run their tests locally on just the files that changed, the problem was solved. But before that, they thought the problem was "technical debt," when really it was just a training issue. (Or, you know, a lack-of-ability-to-Google issue, but I'm trying to be generous.)
On another team, when I heard this complaint, the team explained that the full test suite took almost an hour, and flaky tests meant that they often had to rerun the tests or merge with failing tests. Needless to say, this had a clear impact on our ability to deliver rapidly with high quality, so this was something I prioritized.
Managers don't do the same work as you, so they don't feel the pain firsthand. And they're often not incentivized to care about the same things as you, at least on the same scale. As an IC, you tend to be focused on the next task at hand. The manager is thinking about their quarterly OKRs or whether the team is on track to meet their sprint commitment. If you want something to change, you have to connect the problems you have on the micro scale to the problems the manager cares about on the macro scale.
And if you can't do that, or your manager won't listen, then yeah: let the problems bubble up until the manager feels the pain, as long as it won't come back to bite you.