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.
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.
If you’re in sanitation, you have a more nuanced relationship with trash than those who aren’t, even though everyone dislikes trash.
I entirely agree with you here - I disagree with the notion that "managers" (should) like those meetings any more than other folks. Most large block meetings are ineffective, the more effective ones have a strict agenda and someone moderating them with that agenda in mind. They can be useful for announcements or large-scale alignment, but most of them should be struck from the calendar with no replacement - and good managers recognize this and strive to do so.
> Effective meetings don't come from an individual transforming normally ineffective ones into effective ones by some form of wizardry over everyone else in the room, they come from a culture where everyone makes them effective together through shared values.
The person leading a meeting can make a substantial impact - being prepared, making an agenda and a plan, setting a clear goal for the meeting, deliberately limiting the number of people attending, requiring others to come prepared and enforcing that (possible adjourning the meeting if it turns out to be ineffective), time boxing. There's no magic place where all meetings are effective or feel effective for everyone, but there are places that try to improve and there are techniques that make improvement possible.
To cut it in the other direction, your average testing engineer will have a much harder time agreeing with the idea that most of your test suite is useless and should be thrown out, even if it is useless, because to do so would be to admit that their entire job is less credible as a concept if it is true.
There are plenty of meetings I honestly dont mind at all. Some I do mind, but it is more about how those meetings are moderated then hating on meetings in general.
So Plato's Republic describes how this comes about since ancient times, I wrote something a bit more detailed[1] about it.
But here's the TL;DR - the punishment is that he who refuses to rule is liable to be ruled by one who is worse than himself. And the fear of this, induces the good to take office, not because they would, but because they cannot help ... because they are not able to commit the task of ruling to any one who is better than themselves, or indeed as good.
Some are pulled into management because of the existing mastery and a looming management vacuum.
This isn't something new in tech - it has always been that competent people leave their mastery work to do management (rather politics of ensuring funding), because they see no other choice.
Until I found a manager who was better than I was (and once I understood how they did it and what they did all day), I did think in very similar lines, a little bit aided by the "I'm a smart guy" ego clouding my judgement.
I've been moving into a more manager-like role and your list makes me a bit worried, though I was already considering this to be somewhat temporary. So far it's been a valuable experience though (harder than I thought).
About 2 - I actually really enjoy relationship building. However, if you have issues like nepotism or problems around equity in the organization, I think it can be really hard to have to work with people who make decisions that you find distasteful. That's the main thing that makes me miss the solitude of coding.
One of the biggest hurdles is most people don't want to be responsible for thinking for themselves, their judgment, and their decisions.
And then poo-pooing things outside of their current role that they either don't understand or don't appreciate.
In large orgs, I think one day a month staff should have to intern in a random department to appreciate what others have to go through to build morale and empathy.
A good leader is a humble, messianic therapist, salesperson, and accountant.
Leadership skills are important, but I disagree that leadership is something you’re either born with or not. Leadership can be taught, learned, and practiced.
The real issue is that a lot of people who are pushed or drawn into management roles don’t actually like managing or leading. Some are pushed into management because they’re the most competent IC on the team. Others are drawn to management for the perceived prestige or possible career advancement.
Some common failure modes for engineers turned managers:
1. A person who enjoys quietly coding alone for hours at a time is not going to like being removed from the code to do management work
2. Anyone who dismisses relationship building and diplomacy as “office politics” or “brown nosing” is going to struggle to build the required relationships to get things done as a manager.
3. People who get exhausted from context switching or juggling multiple topics will hate the manager’s schedule.
4. People who loathe meetings are going to be miserable as managers.
5. Anyone who struggles to have difficult conversations, broach uncomfortable topics, or confront people who are causing problems is going to struggle to lead.
6. People who assume they’ll naturally be good at leadership or management won’t learn the necessary skills fast enough, unless their company forces it on them. There are many good resources for learning management and leadership skills, but it’s not uncommon for first time managers to assume they’ll learn it on the fly.