I have a theory about why it is so difficult for great IC's to make the jump to being a great manager. As an individual contributor, you need two things most of all: 1. quiet uninterrupted time to focus your mind and get into flow, and 2. quick responses to any blockers or questions that you have so that you can get back into the work. As a manager, a key part of your job now requires you to be infinitely interruptable, so that you can get those answers back to your juniors quickly, and also, you must protect your juniors from as many interruptions as you can. AND THIS IS IMPORTANT: Make sure you are not that interruption. If you want to ask your junior a question, HOLD IT and batch your questions, if at all possible, so that you are not a source of interruptions.
Beyond that, have clear goals, and communicate them clearly. Most people want to do the right thing. The better they understand the goals, the better able they will be to make decisions on their own that don't need adjustment later.
You need to encourage your juniors to ask questions as soon as they need to get clarification or unblocked. To do that, you need to embrace the interruptions, that is your job now. Both the interruptions from your juniors so that they get unblocked, and the interruptions from pesky people that will distract your crew must be short-circuited by you before they get to your team.
> I have a theory about why it is so difficult for great IC's to make the jump to being a great manager
I find it very odd that most ICs take the path of management. This seems like an unnatural transition, like going from being a minister to playing in a death metal band.
There really isn't a pipeline for for entry-level managers in tech: I've never heard of anyone interning for, or graduating from college and managing ICs as an entry-level job. However, those managers are needed, and have got to come from somewhere, so here we are, looking to start a death metal band at a seminary.
As someone who's done both (dev and dev management), it's more that it's very hard to manage dev teams unless you've been a dev. We have all experienced the clueless non-technical manager who doesn't understand why any of this has to be this way and keeps pushing for "common sense" things like accurate estimates for project development.
There's also nothing stopping a good dev from being a great manager, or vice versa. A good dev learns to listen well, which is also a key skill as a manager. A dev creates working systems out of conceptual components, a manager creates working teams out of actual people. The biggest difference is that there's no Stack Overflow for management - every situation has to be treated as unique and you can't just copy-paste the solution.
> We have all experienced the clueless non-technical manager who doesn't understand why any of this has to be this way and keeps pushing for "common sense" things like accurate estimates for project development.
This is in my opinion actually quite easy to explain to managers: asking for time estimates in software development is like asking for time estimates in proving a deep conjecture in mathematics.
Since every economics major has to take some courses in mathematics (which at least in Germany are often there to weed out bad students), this should not be difficult to understand for managers.
The problem rather is that these clueless non-technical managers insist that this perspective is simply wrong and theirs is right.
Having never had a manager with any clue about maths, I found the golf analogy works better:
"Why can't you hit a hole in one with every golf shot? You know exactly where the hole is, you know how much the ball weighs, you know the length of the club, you know how hard you need to hit it and in what direction. So why isn't every golf shot a hole in one? Because, obviously, you may have miscalculated how hard and at what angle you should hit the ball, you may not have the skill to hit the ball exactly right, and any amount of random factors can affect the ball between you hitting it and it arriving at the green. Same for software development"
> Having never had a manager with any clue about maths,
This is exactly my point: at least in Germany, the compulsory "mathematics for economists" courses are there to weed out student and are thus feared among the respective students.
Indeed, I got promoted to a managerial position, which seemed a nice career opportunity for me, but my productivity and happiness tanked so much that when I had the opportunity two years later to go back to just being an engineer with no one waiting for my input, I just took it. This is how I learned that while I think I can be a decent manager, the skillset of managing people are totally different than being an engineer and it's very hard, at least for me, to context switch effectively between the two. And in that case I'd rather be an engineer.
Beyond that, have clear goals, and communicate them clearly. Most people want to do the right thing. The better they understand the goals, the better able they will be to make decisions on their own that don't need adjustment later.
You need to encourage your juniors to ask questions as soon as they need to get clarification or unblocked. To do that, you need to embrace the interruptions, that is your job now. Both the interruptions from your juniors so that they get unblocked, and the interruptions from pesky people that will distract your crew must be short-circuited by you before they get to your team.