The two things that a good engineering manager does well is handle the internal bureaucratic and process needs of the business and to improve the people those you manage. Often the best way to improve people is to teach them how to think about problems, and in the case of pair-programming they will be exposed to that teaching either intentionally or by osmosis.
Teaching people because they need to learn something and acting like they need to be taught while in fact you just want to do something by yourself is not the same - and your underlings can tell the difference.
I specifically mention that you look for particularly hard or challenging problems in which to do the pair programming precisely because it's an opportunity to both "scratch the itch" as well as teach. In every group I've ever worked in, worked with, or managed there were inexperienced people and those people tend to get less-interesting tasks simply because they lack the experience or knowledge required for hard, challenging, or critical problems. The best way to speed up their learning curve is to give them tasks that exceed their current capabilities, and the best way to minimize the risk is to provide the safety net of a more experienced and/or capable partner to help them learn to think through the problem and catch errors. As an added bonus it is entirely possible that the more experienced partner actually learns something from the pairing as well.
It is not true that all juniors avoid harder tasks, my experience was that they seek them. They are eager to prove themselves. Also, what is hard for them is not hard enough to challenge me.
Supervising and teaching a junior dev working through a hard problem most assuredly satisfies problem-solving itches because in addition to having to think of solutions yourself (often internally) you also have to think about what they're doing and when they struggle you have to figure out a way to lead them to a better path and insure they understand both why they were struggling as well as why a particular path is better. Simply telling someone to do X isn't teaching.
I did not say that juniors avoid harder tasks, they almost always underestimate their limits and try and take on more than they are capable of. I said they tend to get the less interesting tasks, because no sane manager working in an actual business hands out the "re-architect our entire infrastructure" job to the most inexperienced member of a team.
There are interesting tasks for juniors, even easier to find that interesting tasks for seniors, they just don't tend to be large like "re-architecture everything" which should not be task for single person at all. And which is also largely political task (meaning it is as much if not more about negotiating and convincing people).
My experience with younger people is different than yours, clearly, but that might be influenced by how your and my company chooses people and how management behaves. My experience is really that they are very likely to underestimate difficulty and size of task.
The advice that most of them needed to hear were usually brainless easy to me - mostly concerning organization of work and code, when to ask customer, how to refactor safely, that sort of thing. Algorithmic or read-up-on-it technical or math or anything else requiring deeper thinking were things they were good at.
"Algorithmic or read-up-on-it technical or math" aren't the things I consider to be deeper thinking for programmers but instead are skills and methods that we'll always be continually having to add or hone. Deep thinking, which through my experience with others qualifies as hard due to the relative rarity in which I've seen them capable or willing to do, are much closer to the things you feel are brainlessly easy. That's not unusual since we often under-value the things that come easily to us by assuming that it comes easily to everyone. Learning how to _think_ about a problem, how to understand it at a fundamental abstract level and then build a mental and theoretical model needed to bring that vision to the point where implementation can occur is far harder than writing the code for the vast majority of people.
I also used to think "this is obvious and easy for me so it must be for others as well" but time and again that's proven not to be the case. I learned to focus on making sure my people can think the right way so that at worst they can respond to surprise difficulties or crises on their own but the best hope is that they become better than I am. With the right people in the right environment, if I'm doing my job well I will make myself redundant or superfluous.
Such task is just about worst possible choice for teaching task. Imo, if you want to do that task and have time for it, do it and don't apologize for that. As long as you don't cherry pick all cool tasks it should be fine.
And you if you think you need teach them something, pick up task best suited for whatever you want to teach. Not one you wish to do yourself, but the one that is best for learning.
Don't have personal hidden agendas around things like teaching and pair programming. Pair if you think pairing is helpful, not when you actually want to do it personally, but feel ashamed because your title is manager.
> giving to other engineers features that I would like to do myself" [...] I want to give my team members the interesting work and not hog all the cool stuff myself ...
It even implies that they are fully capable and that he trusts them to do those tasks. It also implies that he indeed would like do that task, because he finds doing that task "cool".
Both are marks of good leader and so is being self-aware. None of them implies him team members need to be taught or that teaching instead of doing task them would satisfy his wish to do the cool thing.
Being a manager is an entirely different role than being an employee. Kind of like how someone could be a really awesome director of movies but may not be a good actor.
Sometimes it's that classic, "I can do it in 4 hours, but you will take 2 days. You do it, and learn something, and next time we'll be equals" kind of thing.