I hear this a lot, but one of the ways I gained this skill was by being a generalist in a room full of specialists. A systems engineer. The dumbest person in a room of specialists.
I previously ran the engineering and finances of an aircraft simulation facility. I had a lead computer scientist, a lead IT manager, a lead mechanical engineer, a lead electronic engineer (which was initially my area), a lead aeronautics engineer, a lead graphics engineer, and various juniors, and together we had to1) build and maintain a set of aircraft simulators and 2) repeatedly customize those aircraft simulators for individual clients and then I 3) had to oversee the finances of this. And we'd have upper-management requirements (fiscal goals and limits, broader strategic priorities, etc).
I started as a junior electrical engineer, became the senior electrical engineer, and then moved into that more broad-based tech leader role.
In that role, I had to balance all of those things. I would run meetings, but talk the least. It would be 70% initial questions or letting others speak freely, 20% follow-up questions or purposeful counter-points to sort out the differences between competent people, and then 10% declarations or decisions from me. And even when I made those, I would go to each senior party privately and gather their opinions to look for critical flaws to see if an error correction was needed somewhere along the way after that.
Several of my senior engineers who reported to me were older and more experienced than me, so rather than acting the hot-shot, I would talk to each humbly and view my role as like, "someone has to do this whole organization thing, so please help me maximize your input to that."
Someone had to be the person who was the second best at each of the disciplines, and read people and technicals enough to know who should be promoted to lead each of those disciplines and when they were speaking out of competence vs out of pride or other human details. That was my job. I had to make all the separate engineering disciplines clear enough, and agree enough, to chart a single path forward, and then agreed to by upper management who had way less technical details.
And that came down to what is known by systems engineers as the "critical path". In other words, the critical path is the hardest or most expensive or most contested thing of a given project, so you can focus on solving that as the core, so that the periphery would follow.
That role sounds cool, but there's another side of the coin. I realized early I'd never be focused enough to dominate a specialty as some of the hyper-focused specialists I knew could. I could nail an individual project at like a B+ or A- level, but not an A+ level. I was more drawn to the broader picture from the start. I could be a B or B+ at everything, and an A- in my speciality, but I couldn't care enough even about my specialty to bring it to an A+ level. I wanted to be someone who helped all the A+ specialists come together.
I've since applied this systems engineering mindset to analyzing global macro flows, but also to analyze things like bitcoin or major tech themes like energy or AI. Some of it is instinctual or experienced, but other parts are easily teachable.
And the most easily teachable concept is to always think of the critical path. Picture multiple parallel things that all have to go right to get to the goal, and then imagine the hardest of those paths. That's the path to then focus on in terms of realizing how time consuming or expensive it'll be to solve, and how it might be accelerated.
Lots of other things are easily solvable with some resources, but the critical path is the real project-maker or project-killer. Across discliplines, formally or informally, try to be able to identify it, or identity the right people and ask/watch them enough to help you identify it.
