The specifics are highly domain-dependent, but at a high level, you need to be able to identify every resource and process in your system, how those processes utilize (or should utilize) those resources, where the bottlenecks might be, and have a plan for how to resolve the bottlenecks given the capabilities of the resources and processes. That is, you need to be thinking at a level of system components, not code.
Unfortunately, most of the above knowledge isn't taught in schools and comes mostly from experience.
So if I'm someone who doesn't really have the patients or attention span to sit down and write lots of code, but I think I'm pretty good at figuring out what all needs to happen from a macro perspective.
An analogy would be I don't have the foggiest on how to play the violin, harp, or flute, but I know how they all need to play together to not sound like a train-wreck.
I don't know if I'm being extremely naive or if I'm actually going to turn out being better at system architecture than actual coding, or if that's even possible.
Is it possible to get good at software architecture without having a lot of personal experience with many subcomponents of said architecture? Sure.
Is it likely? Not at all. This area is even more experience-driven than other senior-orchestration-type roles in other fields, and most of those roles--even the literal example of an orchestra conductor/director you mentioned--very often start with someone with immense personal experience playing a lot of metaphorical "instruments". All the other people in this subthread saying "build things and see how they fail" are right--and you have to be intimately involved of the building of a lot of things to start to see the patterns and move closer to an architect role.
I wouldn't bet the farm on being able to conduct the orchestra without knowing how to play an instrument.
EDIT: I don't think parent should be downvoted. They're highlighting important distinctions and seeking advice early in their career. Just because y'all disagree with their approach doesn't mean their comments lack substance or are bad. And if you think the down arrow will teach some kind of "punishment" for having a disagreeable outlook . . . well, I hope you don't raise kids, 'cause that tends to backfire.
Thanks for the reply and the edit. And you're right, I'm just trying to figure things out before I get to place where the consequences are more real. I could have worded the original comment better, I think it came off as arrogant.
If I can find projects that are open source with public documentation of pain points would it be beneficial to read through their discussions etc, to get a sense of the issues these projects faced with scaling, with the goal being to glean some insight into what went wrong and maybe avoid common pitfalls and save myself time trying to reinvent the wheel.
Unfortunately, most of the above knowledge isn't taught in schools and comes mostly from experience.