[tail_exchange]

If rewriting your docs and solving these hardcore engineering problems have zero impact, then you shouldn't do them in the first place. If these changes are important, then they do have impact, but the engineers may not know how to communicate it.

Learning to communicate impact is difficult, but it's a really good skill to have. Do these doc changes/engineering problems help reduce KTLO? Does it reduce on-call toil? Is it going to bring security patches? Is it going to make the system more efficient and save money? Are these frequently asked features? Do you have other people (preferably seniors) who can vouch in favour of these changes? All these things are measurable and can be communicated as impact.

There are instances where a change has 0 impact and it's still nice to have, for example, fixing a typo in the internal docs. But these changes are usually very easy to do (take less than 5 minutes), and it won't affect your other tasks. On the other hand, spending several days fixing typos everywhere may seem like a great idea, but if nobody cares about them and it does not move any needles, then you are just wasting the company's time and money. The effort you put in these no-impact changes should be a defining factor for prioritization.