An idea I've found helpful recently is what I'm going to call alpha and beta thinking.
When approaching a problem, situation or conversation:

• Beta thinking is the involvement in the specifics of the issue at hand.
• Alpha thinking is considering the issue's relation to your strategic goals.

A basic analogy is learning to drive a car.
The initial learning takes place at a very primitive level: operating the pedals, gears and steering. As you get better these details become so natural that you don't need to think about them. When this happens you start to focus on higher-level goals: choosing an optimal route and navigating traffic.

In practice this idea has been very apparent during my own transition from an IC to a manager. As an IC, I was extremely focused on shipping features, fixing bugs and various kinds of optimisations. As a manager, I am responsible for platform stability, feature delivery and the team. I have found myself most effective as a manager when I am very concious of both the details and how they relate to the higher order goals. It sounds stupidly obvious to state it this way but, in the moment, I found it extremely easy to forget them. And I suspect other engineers turned managers have faced a similar experience.

An interesting observation from both these examples is that getting really good at the beta thinking unlocks the alpha thinking. I suspect this is another reason why managing a technical team as a non-technical person is so fraught. On the otherhand, I suspect being extremely good at this is why founder mode is effective.

A natural extension to this idea is that there is not just two discrete levels of thinking but a spectrum across various levels of abstraction. This seems closer to the truth. But I've found that focusing on the details and one level of abstraction higher to be the most useful.