There are two kinds of work in software engineering: praise-able and hidden.
Praise-able work is typically the type of work that gets people promoted and recognized. In a nutshell, it's something visible and straightforward: implementing well-defined feature requests or fixing user-facing bugs and issues, especially after normal office hours. Praise-able work goes hand-in-hand with word combinations like "to deliver an impact" or "to bring value to the customer". Sometimes even "to push the product or the company forward".
There is nothing wrong with the praise-able work. Businesses exist to make a profit and the way it's done in the software engineering industry is by delivering amazing products. So, people who contribute to that directly do deserve to be rewarded.
The only problem is that praise-able work is not all that it takes to get stuff done. A big amount of work is the hidden work. The best example of that is operations. Run an internal job, clean up some data (potentially, customer input), fix some bug in some tooling, tweak infrastructure or the setup of something here or there.
Hidden work can also be directly related to the product, but deeply technical: unit, integration, end-to-end tests, migrations, or refactorings. It can also be organizational: attending necessary and unnecessary meetings (and it's hard to say in advance which ones are which), answering some questions in the chat or at the desk in the office, mentoring junior developers, conducting code reviews or feature refinements.
All of that is essential for the healthy software development process. It requires a lot of time and effort, often considerably more than the praise-able part of the work. But here's the catch: developers rarely get recognized for doing it, let alone praised. It's usually not the focus of the performance reviews nor does it look attractive in the CV. Neither is it cool to mention it to colleagues from other departments when they ask you what you do. Okay, maybe, only as a complaint: "ugh we had to spend hours doing X instead of developing the next big thing".
The relationship between the praise-able work and the hidden work almost conforms to the Pareto principle. The only difference is that this principle implies that one can sort the tasks by the rewards in descending order and pick the first n of them. It's not doable in software engineering without cutting corners; the industry knows why it's a bad idea.
There are different ways to deal with it. The toxic way is to cherry-pick the praise-able work and let the others deal with the rest. The constructive way is to make the hidden work visible. For example, by creating postmortem tickets about it. An incident happened? A ticket in the "done". An old project has some outdated dependencies that need to be updated? A ticket in the "develop". Not everything can be put into a ticket, so an alternative is to have an Excel sheet for it (rows of tasks and respective efforts). There is also special software that lets one track time on different tasks (widespread among freelancers).
While it might look like overkill, it brings a few advantages. First, if one looks forward to being promoted, but usually does the hidden work, such a list can help build the case for them at the next performance review session. This list can also help spread awareness of the "productivity blockers", measured by the amount of time "lost" not implementing and shipping new features. And it can also show the potential places for optimization: maybe unnecessary processes take place, or something can be automated. As an extreme, it can make it possible to estimate the Return Of Investment of each type of task of the hidden work. Or what kind of ROI the automation would bring.
In any case, without visibility (essentially: without data), any statement about hidden work is speculative. Speculative means: the "loudest" in the room wins the argument. However, as far as business is concerned, time that isn't used to bring the product further is wasted time. And the only comprehensive and constructive way to make a point that it's not is to make the hidden work visible.