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 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'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.
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.
"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"
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.
In companies when expensive tech only people are allowed you see less techies among managers.
Then, when you graduate and can start making real money (probably), if you work at a hospital that does resident education, you're almost immediately expected to let the residents do as much as they can safely do, so they can learn. You go from working 80 hours a week performing surgery after surgery at a senior resident to working 30 hours a week watching the senior resident perform surgery.
Similarly (and admittedly it isn't a perfect analogy) as a junior and mid-level you're spending all this time learning how to write real software. Most of it's bad and especially at the junior level you're going to spend a couple years being more trouble than you're worth in terms of productivity. But by the time you're a senior, when you theoretically know what you're doing, you're going to have to spend most or a large portion of your time helping out the juniors in your org.
If you don't want to do that, you shouldn't be accepting senior positions. Or at least, go work somewhere where they don't hire juniors.
Training your replacement is how the cogs in the machine reproduce.
At a certain point, you probably know considerably more about the work than the people working around you. You might say you develop "seniority". At that point, the balance of value between your individual contributions and the knowledge you can share with others reaches a tipping point.
If you're limiting the value you're bringing to the company to only individual contributions, you're capping the value you can bring the company and by correlation the compensation you're due.
Honestly, it's a weird remark. Pretty much all jobs on this planet have aspects you wish you don't have to do. You work for your employer and your employer needs you to train the juniors. If you don't want to do that, change for an employer who only recruit senior engineers, if you can.
Beyond that, you could go into contracting. Do the work, point to your contract whenever someone asks something else of you, move on after 3-6 months, rinse and repeat.
When pairing with juniors, I avoid directly solving problems for them as much as possible–lessons tend to stick better when you ask leading questions and let them discover solutions for themselves. Perhaps this technique would also work to filter out "lazy" questions.
Working with a mix of super competent developers at all levels has really driven home for me that everyone is better at something, and worse at something, than you are. I've learned lots of new things from developers with less experience than me. I've also worked with many devs with senior titles who were worse off than most juniors.
Ultimately it's okay to find mentoring unenjoyable, but if this describes you, please stick to teams with most/all seniors and don't agree to mentor even if pressured. Attitudes like this can really exacerbate imposter syndrome for juniors, and I've seen it damage several careers.
When I was a junior, I would have been greatly satisfied by more time and attention from seniors, as I would be today grateful for more time and attention from people in differing specialities, where I am quite junior. We do however live in the real world, where these people's time is extremely valuable, and I wouldn't dare disrespect it by asking them trivial questions. I would value 10mins of their time and the context switch they pay to help me on the order of days of my own. And if I do resort to bothering them, I do so with an attitude of utmost humility, akin to digital dogeza.
I get frustrated when folks fail to do any of this. I regard is a breach of professional etiquette that unfortunately seems all too common. I've found myself responding "Try harder" or "LMGTFY" to these sorts of inquiries, which is about as polite as I can muster.
> everyone is better at something
It seems that this would be trivially easy to prove false, and very difficult to prove true. I've certainly met developers with nothing uniquely useful to contribute, in spite of best attempts at coaching them.
> imposter syndrome
I'd like to note that I'm actually extremely forgiving of mistakes, even very expensive ones, so long as they're honest. We all make them, and it's really on me to ensure that processes are in place and enforced to prevent the most critical sorts of them. But you don't know what you don't know. It's more the "I'm a baby, please hold my hand" attitude that I'm frankly somewhat disgusted by. If that describes (hypothetical) you, then perhaps some imposter syndrome is in good order.
I wouldn’t want to work on a team with someone who has such an attitude. I’m very grateful to work in an environment where we all want to help one another. This really reminds me how good I’ve got it.
With that said, I don't see anything wrong with stagnating at your peak IC efficiency if that's what makes you happy.
I agree with sibling which says that mentoring is not leadership. Helping out others is not the same as giving them instructions or evaluating performances for example. However I can understand that someone would like none of that.
You've 'lost' 80h effectively of productivity for the company (remember, mythical 10x), but you've gained 104h (32h+32h+81h/day5days) from your team, for a net 24h gain.
Of course, numbers are exaggerated, but the point remains the same: if you are a tech lead helping your team succeed is your primary job, not coding/design. You are the person who connects the lines of communication, removes obstacles, mentors the team on coding and design, and gets the team moving in one direction that aligns with the customer needs.
You probably will code, to fill in gaps and help out, but personally I find it's split around 5/2/2/1 - 5 parts are working with your team to guide them and help them overcome obstacles, 2 parts communicating with management and customers, 2 parts coding/design, and 1 part administrivia/training.
10x engineers can be a good match for startups where shipping now is essential and for big businesses who need something done quickly (for a change, the bigger the company, the slower everything else).
The only cons of 10x engineers is that they will burn out and that they're incredibly rare. Advising 10x engineers to help out other and collaborate is also nice to give them a bit of down time so they don't burn out and leave for the next startup with a 50% raise.
That said, it's not like HR managers are able to distinguish between senior low productivity engineers and 10x engineers, so it doesn't matter. No company will have a strategy around employees productivity.
I disagree the 10x engineer is a myth, as an hiring manager, I can easily tell you who is a 10x engineer after working with them for a year or so.