I understand the function of creating, launching, and orbiting a satellite geosynchronously to do GPS so it's easy, right? Yea, not so much.
I'm a firm believer that you need to understand everything at least one layer deeper than high level functional descriptions so you can start to reason about the difficulty or amount of skill needed to accomplish something. You understand the real problems (even if only at the surface) and know where opportunity lies. With a pure functional perspective many current managers have, you simply can't reasonably manage and plan and are instead a glorified resource scheduler with whims.
Having said that, I am possibly a bit like your boss. I am a major bottleneck to my employees, and they struggle to overcome technical skill gaps between their knowledge and what they need to work on. Frequently I find they are blocked for days or weeks and when I finally get to sit down or spend time with them, their problem is sometimes solved within minutes. Sometimes I resent it because it's clear to me with some basic effort in learning new skills, they could get over these humps but they seem to take an attitude that if they hit something they don't already know, it's perfectly reasonable to stop progressing it and just declare they need help. It's really alien to me because as a young developer I would never have done that, I would just keep acquiring knowledge until I solve it (possibly taking a lot of time). While I'd never outright deny a direct request for help, I will often redirect where I think they can figure out the problem themselves with some investment in their own learning - "you need to learn about X, do some reading and tutorials, I think that will help", etc.
I am curious if you would have advice? Assume you can't solve the problem of actually getting your bosses' help (they simply have too many responsibilities to be helping at a micro level), how could one develop a culture of self-learning and proactive responsibility to progress things?
Optionally, you could put an interim step where someone else on the team is given the chance to advance it; might keep it from your doorstep. But I don't know if that'd help in your situation!
I've assumed that the problem is with them, not you, as that's how you wrote it. But if you have (possibly) set a tone where their solutions work but not as well as yours and are switched because it's not done as well as you'd do it, then it's on you (possibly?)! :-)
That's a metaphor - of course you shouldn't treat your reports like children. But if they possess the following attitude, it's on you as the manager to let them know that it's not an acceptable practice on your team.
> they seem to take an attitude that if they hit something they don't already know, it's perfectly reasonable to stop progressing it and just declare they need help
This advice doesn't stand on its own; you'll need both more specific tactics and a broader strategy for dealing with the situation (providing tooling or scaffolding for improving their behavior). But the fact of the matter is that everything else you do for them won't matter if you condone this behavior - which you are, by allowing it to keep happening.
PS I am an engineer-turned-manager and this is easily the least favorite part of the job for me as I get used to it. But it is ultimately your responsibility to do so, and you are impeding your own ability to improve as a manager the longer you resist doing it.
Yes it is quite the learning exercise to get used to all of this and know where to be drawing lines, when to reinforce boundaries and when to let things go. What I am realising is that my threshold for giving direct feedback is way too high. I keep trying, instinctively to achieve outcomes indirectly - but way too often it doesn't work or even backfires and breeds more of the behavior I don't want.
I really appreciate having your thoughts!
What I like to do is to find the win-win for both me and my team members. If there's no reason for them to do better, why should they? Maybe you can get an understanding of what motivates them. Is it improving as an engineer? Better compensation? Getting promoted? I would imagine all of these are fairly easy to align with a goal of decreasing blocked time from weeks to hours. That's a huge difference in time!
My advice is that if you know what someone needs to work on, and they don't, just frikkin' say it. Don't wait until they are burned & trying to drag a merge request across the finish line. Also invest in tooling & processes that encourage people to figure things out & generally do better (which may be simply don't give them excuses to do worse).
This especially stings if it comes from a team lead because in my mind, the team lead exists to bounce ideas off of and to iron out issues.
But if you ever see a team lead or manager dinging you for just reaching out to them, switch teams or quit.
Sounds like the Team Pb XD