How I find problems to solve as a staff engineer

I'm often thinking about 1-2 immediate term problems (what am I coding on now), 5+ medium term problems (what am I planning to work on next or moving such that someone else can work on it), and then a handful of long-term problems ("this is currently intractable, how do I convince leadership/this other team/etc. to make it possible for someone to actually address the technical problem I care about").

Absolutely applies to product focus and customers too. Giving the customer exactly what they ask for with no analysis will result in crappy software.

Except that sometimes a company giving the customers exactly what they want does optimize for sales in the market (especially in "enterprise sales", government contracts, and anything involving RFPs etc)... it just always also results in crappy software. This is how we get crappy software that sells well.

But sometimes it's a chicken-and-egg problem.

Teams most often don't have the patience to wait for your proper solution. If you don't have a ready solution to easily address their problem, they just build their own work-arounds, or give up the task if it's too hard. And those teams all have their own priorities to tackle on their plate for the quarter, so even if you eventually build a proper solution later, it's unlikely they'd migrate to your solution or restart their task.

So even if you have accumulated a lot of old use cases, when you build a proper solution you'd need new use cases to justify your effort, the ones where the owner teams are willing to build along with the iterations of your solution. That kind of new use cases may or may not come up when you have the bandwidth and resource to actually do this. And if you miss one opportunity, the constant shifts of organization priorities would likely mean there would not be another chance for you to do it. The end result is, every team either builds their workarounds, or just give up if it's too hard, without a proper solution.

I asked my manager if I should be creating tickets for the work I'm coming up with, and he answered a question I didn't ask, saying he doesn't count sprint points. So I clarified, shouldn't I at least be creating tickets so that we're accounting for it in our sprint planning? And he didn't seem to care.

IMO, it's a 180 degree shift to go from trying to accomplish assigned work to creating new work and accomplishing (or delegating) it / adding it to roadmaps / etc. To me, it wasn't at all obvious that this was what I should be doing, so it was strange to sort of stumble upon it when asking an adjacent question.

It would have been very useful to get an explicit instruction such as "hey, only spend 1/4 of your time on planned work" or similar.

I'm sure there are plenty of people out there who spent their entire career trying to avoid doing assigned work so it's an easier transition, but for rule followers it's a weird change.