I would say you need to keep in mind that delivery of the team against product commitments should be a priority, and being able to do that in a long term sustainable way is very important. So in my view you should absolutely put out of your mind what you'd like to do and instead view it as what is the best way to complete the task at hand ( and making sure that can happen in a consistent reliable way). I'm a EM myself and there's no way that my day-to-day is consistent enough to code in a reliable manner especially when put up against other priorities that I have to deal with. What's more important?, you finishing a business critical feature you signed up for or helping a team member with crisis they are having dealing with another team member? (Or if you are more tech lead than people lead then compare it against more long term strategy planning and architect-ing you could be doing.)

If it's a particularly challenging feature or problem you might consider pair-programming as a solution. It allows you to apply your expertise (and scratch the itch of wanting to do things) while also letting another engineer contribute, learn, and/or demonstrate a different view.

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.

I think that other engineer would be much happier if he got another task with little bit of autonomy and trust, instead of being forced to look how you scratch your itch while he nods along.

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 believe that nowhere in my response did I suggest that you be incompetent in your management or be a lousy teacher.

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.

Give them hard task that you are not itching to do by yourself or don't have strong subjective opinions about. In any case, if your safety net is trully just safety net with enough autonomy for them, then supervising them won't satisfy your problem solving itch. Because it is not supposed to, good teaching is about allowing them as much independence as possible whole you limit yourself to keeping it safe. If you are intervening more then that, then you are not making them more confident about hard tasks (which is exactly what it sounds like you want to do as they tend to pick only easy tasks).

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.

You do not give them hard tasks that are critical because of the risk involved, until they prove they can be trusted with those tasks.

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.

Thankfully, critical and hard is not the same, so I can give them hard tasks that are low risk. And I can code review them and check on them while they are working.

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.

I think our experiences aren't that different but our view of what juniors need probably does diverge.

"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.

Personally I think it goes better in this scenario when the manager/tech lead is not the one at the keyboard. That way the person who's learning can make a lot of the decisions while bouncing ideas off the other person. If it just becomes watch my manager do some work it's very hard to focus and learn.

But the whole original problem was that the manager really wish to do that task to scratch the itch. You can't simultaneously do the task the way you want it and simultaneously have someone else having do that. You will end up either annoyed that he does it differently or he will end up having to guess until he reaches solution you had in mind all along. It is profoundly demotivating.

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.

"Do the task the way you want it." That's a far more mechanistic view of "interesting work" and "features I would like to do myself" than the parent seemed to express.

I am going to quote him:

> 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.

Indeed. Pair-programming isn't "programmer with an audience."

Personally as a manager, I find doing the tedious work to be one of the best uses of my time. It helps keep my engineers happy and focused, which is the most important part of my job.

I would also hog all the tedious work as an engineering manager. I tried to make most of it go away but in order to allow people to grow in their careers, they have to be assigned "stretch" work.

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.

this is kind of unproductive. The job of the manager should be to push the envelope of the team as a whole. As such if he already has a high performing team, he should be as hands off as possible, focusing on other crucial areas. If not, his job is to create small proof-of-concepts of ideas and let the team take them forward.

This is a gross oversimplification, but why not just dole out the good projects round-robin, where you're just one of the members of the cycle? There's no reason why a manager should never be able to contribute work, just that they probably shouldn't always take the 'good stuff'.

Because as a lead, they may know a lot more about something, or have experience with it, or have thought about the specific problem space a lot more.

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.