I will also add though that I think there is another dimension as well. I think much perceived middle manager "incompetence" stems from middle management juggling direction/pressure/expectations from senior management, and the realities of the program and the engineers. The best managers are capable of managing expectations from above while keeping their team shielded from all that overhead and just keeping the team chugging along and being productive. Other managers seem to have the ability to weigh their team down by allowing too much of the "managment overhead tasks" to leak down to individual engineers. I've seen this vary across programs and managers, and can't say I know all the answers, but I do know I much prefer the role of the IC....
- reduce Peter Principle and pyramid org-chart building
- retain, train, and invest in good managers as a profession, not a will to power
- hire more administrative and secretarial people to navigate the minutia to unblock highly-paid employees from finding answers in the bureaucracy and doing unnecessarily-dumb paperwork
What happens though when the business puts these types of middle managers in the impossible position of not being able to say “no, this isn’t a priority right now” but still expected to maintain the same amounts of engineering productivity and feature throughput?
I didn’t write this article, but it sums up my headspace, currently: https://www.linkedin.com/pulse/stop-doing-more-less-2019-mat...
Staying in exactly the same place won’t affect revenue, customers or performance reviews at all. It’s when people work under the mistaken assumption that they have to increase at all costs that you have a problem.
That's just plain bad planning on a business side of the company. They should either fix that, or face gradual departure of their workforce, from best to mediocre.
This cuts directly against the narrative by the article, and the narrative of the article is the common one. The argument seems to be "you just don't have enough time to do both well!" but in general, there's no free lunch here, you are choosing between different trade-offs. Management is hard no matter what, but if you already have the skill to contribute to a team's efforts, you're not just leaving money on the table you're lighting it on fire by abandoning it by letting yourself atrophy into becoming a manager who's skill stack is shallowly scoped to people management and leadership skills. Whenever you see a commonly held narrative like this that has clear negative consequences to those acting on it, all other things being equal it pays to be contrarian as long as you don't fall into the obvious traps, since you're going to differentiate yourself.
I'm surely not the best manager and I'm sure I suck at a lot of it, but everyone does somehow. I'll go head to head anytime with an engineering manager who doesn't ship anything anymore any day of the week in terms of who engineers would rather have as their leader when building something difficult.
Edit: Just to clarify, the question in my post is kind of directed to my manager and not to parent commenter :)
It certainly makes the job of a manager harder when you are forced to reckon with the fact that you can't just throw out coding without it undermining your ability to be a good manager. In practice, I would try to ebb-and-flow with the teams' needs - it's a dynamic, challenging process.
Also, there's a tricky issue of, as a report, being able to identify what is intentional vs unintentional. Your manager is probably failing you, but there's also a chance they are forcing you to grow by disengaging a bit and letting you fall into a few ditches. Sometimes a good coach will just shut up and let you make mistakes. Until you see the net effect of their behavior on you over an extended period, you can't know if you have a good coach who is pushing you in a way that you can't see, or a bad coach who is just failing you. A lot of people with good coaches resent them in the early days for being too hard, too disengaged, or other things, which forces them to push themselves harder.
Also, this depends on the experience level of a manager's reports as well. If all of them are quite experienced and have clear goals regarding their career, the manager does not have to spend much time on career coaching. They can focus most of their time on coding. But if that is not the case, then they'll have to balance their time accordingly.
That's a good point you make regarding intentional vs unintentional. This point had not occurred to me earlier. After thinking about it though, I am confident that its not applicable for my scenario :0. I will have this in mind for future situations so that I don't come to wrong conclusions.
I hear this an awful lot, but either as a manager or IC, I have no idea what it means.
From my perspective, if you leave me alone to do my thing and don’t interrupt me with random shit all the time, I’ll grow naturally. But the manager doesn’t have to be involved in this beyond shielding me from the bullshit, so I guess people are talking about something different.
That's what _you_ want, but it's not what everyone wants. Some people want or need much more active participation in their growth, and it's a manager's job to find what's right for each person. A common failing new managers make (and one I made as well) was assuming everyone wants to be managed like I want to be managed. I was very much in that "leave me alone and let me do my thing" mindset, and that caused a lot of problems much later in life.
Even so, wouldn't a tech lead be focused only on technical aspects. Say if I want feedback on some customer interaction I had or maybe regarding a meeting I ran, it is not the role of the tech lead to do so I think.
An engineering manager who was technical, listens to their staff, and delegates can still be respectable and has the time and focus to help the team in a greater capacity with non-technical things proactively rather than reactively.
An engineering manager who can setup an HA database is as useful as a fireman who can play chess. It's all well-and-good, but it doesn't add value to the management of the team if someone else has that duty. Technical leads yes, but not managers.
Your opinion is the same on made in the article and is the consensus view. To me, the consensus view is there for a lot of reasons, one of which is that it's a common anti-pattern for formerly technical engineers to become managers and let themselves get drawn into the code at the cost of management. In all things, balance. The other, more general anti-pattern is to see a failure mode and then presume the diametrically opposed opposite is the global optimum. If engineers are prone to be bad at management because they get sucked into building stuff, then whatever benefits may come from that should to be ignored: they should abandon it altogether. (This is a common error in other domains, like the canards "ideas are nothing execution is everything", "you should never pick stocks, and only invest in index funds", etc.)
It also turns out it's much easier to believe that engineering managers who ship code are worse managers, because it means that you can feel good about deciding you're going to stop coding: you're doing it to do your job better. You already have so little time anyway. But what if it turns out being able to ship stuff actually helps you in being a manager? Now it's harder: you have to decide where to draw the line. And so, it's a much more difficult thing to come to terms with since it means there are no easy choices and you actually have to live with the fact you are always going to suck at this in one way or another.
I argue that, all other things being equal, having the ability to ship with the team makes you a better manager. The question is if that is true or not, and if so, at what point does the trade-off stop making sense to maintain that ability. Creating false hypothetical situations like "setting up an arbitrary HA database" doesn't prove much of anything about the actual, local, domain knowledge I'm referring to that you get by continuing to perform IC-like work alongside the team you manage.
Then you're a technical lead and a technical manager; don't conflate the two as the only possible configuration.
Also, if you think I'm writing this to defend my ego, you ought to become a psychologist since you are able to read minds over the internet.
If you’re going to accuse me of a lack of curiosity then you need to explain why anything you have written actually does more than repeats the claims in the article I was explicitly rejecting, or why my claim that you leaning on titles to form your argument is just debating over definitions is false.
I guess we could recast the term "technical manager" as "one who attempts to both do and manage."
„manager of technical people“ is great example. You would expect a technical person who the team respects with equally great management skills, farsight and vision.
I think this is spot-on. People, for whatever reason, view management as the next step of a career when it's actually a career change. Yes, it's in the same domain, but it's a totally different job.
I've done the transition from IC to Manager, back to IC, and then back to Manager again. Unless you like and want to do "manager" things, you're going to have a bad time.