I don't care about any of these points, and I especially dislike one-on-ones. I just want my manager to do one thing: make decisions. To resolve conflicts, and make sure discussions wrap up and reach conclusions.
Common Mistakes of New Engineering Managers
71–80 of 224 posts
Re: Common Mistakes of New Engineering Managers
#721. Become an engineering manager 2. Stop coding 3. Do well for a few years until you become out of touch 4. Watch your team stop respecting you on technical subjects because you’re behind the times and too rusty but don’t know it so look foolish and are ignored when you give suggestions, which radically undermines your relationships with them as well as your ability to lead 5. Watch as your role morphs from a manager…
In the other universe:
1. Do not become an engineering manager.
2. If pushed (e.g. by not getting raises), move on.
Re: Common Mistakes of New Engineering Managers
#731. Become an engineering manager 2. Stop coding 3. Do well for a few years until you become out of touch 4. Watch your team stop respecting you on technical subjects because you’re behind the times and too rusty but don’t know it so look foolish and are ignored when you give suggestions, which radically undermines your relationships with them as well as your ability to lead 5. Watch as your role morphs from a manager…
I always feel bad when I see someone who was pulled to the management track early in their career. They often never acquired the technical skills or even knowledge of the technical skills of their more senior engineering counterparts.
It really does a disservice to pull someone into management 3-5 years into their career. People will often take the role as it looks like a promotion, but ultimately it's a lateral move with slightly better pay in most environments.
Re: Common Mistakes of New Engineering Managers
#74I will disagree with one point. Neither eng managers nor tech leads should be doing project management. It is a unique skill and worth having someone explicitly in charge. They should own the structure of requirements docs, story breaktown, ticketing, jira processes, etc. While they may be somewhat technical they are more ensuring consistency and quality of process without burdening devs. The best team composition I…
Can I just throw in a wrinkle, I'm what could be described (from this list) as an Engineering Manager and Tech Lead. I architect and implement solutions while also doing all the traditional managerial duties. I feel like I've been eaten alive lately on HN that this arrangement isn't possible and you cannot do both well, but I beg to differ.
What I would say is that it's possible but very rare to do this well, and furthermore that people often don't have an accurate sense of how well they're doing at it. The individuals on the team might know but might not want to say, but an even bigger problem is the individuals on the team not being aware there is a better way. I was about a decade into my career before I had an experienced dedicated engineering manager. I had already spent time as a tech lead / manager myself by then, and thought I had done ok, but experiencing a dedicated engineering manager made me see that I had actually done the job quite poorly.
You may be doing it extremely well! It does happen. But I can understand why you're getting skepticism.
Re: Common Mistakes of New Engineering Managers
#75I will disagree with one point. Neither eng managers nor tech leads should be doing project management. It is a unique skill and worth having someone explicitly in charge. They should own the structure of requirements docs, story breaktown, ticketing, jira processes, etc. While they may be somewhat technical they are more ensuring consistency and quality of process without burdening devs. The best team composition I…
The challenge with this is that you have ~7 defined boxes that you are trying to put a team of 7 individuals into ( or 7 roles and 13 people ). At any given point in time there won't be work commiserate with all 7 job functions, people will grow to a different role, someone will be the bottleneck, and someone will be MIA or in a backfill.
It's often best to keep the number of roles low on the team to increase flexibility/provide freedom for individuals to tailor the roles to their own strengths.
Re: Common Mistakes of New Engineering Managers
#761. Become an engineering manager 2. Stop coding 3. Do well for a few years until you become out of touch 4. Watch your team stop respecting you on technical subjects because you’re behind the times and too rusty but don’t know it so look foolish and are ignored when you give suggestions, which radically undermines your relationships with them as well as your ability to lead 5. Watch as your role morphs from a manager…
> unless you happen to have been born with natural leadership skills (you probably haven’t)
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.
Re: Common Mistakes of New Engineering Managers
#77I don't care about any of these points, and I especially dislike one-on-ones. I just want my manager to do one thing: make decisions. To resolve conflicts, and make sure discussions wrap up and reach conclusions.
What about career growth? Great managers have helped me grow so much, and advocate for the steps I want in my career.
Re: Common Mistakes of New Engineering Managers
#78I disagree with this article. If you, like the author of this article, spent 13 years as an IC, perhaps it is OK for you to focus on acquiring the soft skills required to be an efficient engineering manager. After 13 years as an IC, you have a pretty good perspective on what it means to be an IC, how to identify valuable team members, how to assess their skills, how to identify blockers and facilitate solutions, and…
IC = Individual contributor?
Never seen it abbreviated before.
Re: Common Mistakes of New Engineering Managers
#79I will disagree with one point. Neither eng managers nor tech leads should be doing project management. It is a unique skill and worth having someone explicitly in charge. They should own the structure of requirements docs, story breaktown, ticketing, jira processes, etc. While they may be somewhat technical they are more ensuring consistency and quality of process without burdening devs. The best team composition I…
Do you really enjoy having 3 different managers to report to? All of whom have 3 different projects they’re dealing with? IMO, it’s better to have a 1:1 ratio of managers to teams. A 3:3 ratio is a recipe for endless meetings and communication overhead. 1:1 and 3:3 have the same number of employees, but 1:1 eliminates all of the communication overhead because there’s only 1 manager per team instead of 3.
In my experience, splitting managers, designers, and QA people across 3 simultaneous projects results in 1 project dominating their time and the other 2 projects being starved for attention. Repeat this across the product manager, engineering manager, QA person, UI designer, and project manager and you virtually guarantee that every project is going to be starved of resources.
Instead of having 3 separate product, project, and engineering managers split their time across 3 different projects and wasting time synchronizing with each other and the teams, it’s better to have 1 person handle the role of product, project, and engineering manager with 100% focus on the project and team.
I’ve worked in teams like you’ve described. It quickly turns into a mess of meeting scheduling conflicts, repeating every discussion 3 times because you have to communicate it to 3 different managers, and constantly working around blockers because your UI or QA person has been pulled into a higher priority project.
Put small teams together. Let them focus 100% on getting things done. Don’t cross everyone over to 3 teams. Don’t give everyone 3 different managers.
Re: Common Mistakes of New Engineering Managers
#801. Become an engineering manager 2. Stop coding 3. Do well for a few years until you become out of touch 4. Watch your team stop respecting you on technical subjects because you’re behind the times and too rusty but don’t know it so look foolish and are ignored when you give suggestions, which radically undermines your relationships with them as well as your ability to lead 5. Watch as your role morphs from a manager…
> unless you happen to have been born with natural leadership skills (you probably haven’t) 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 the…
I would argue pretty strongly that if you are not a natural leader, the road to development of leadership is paved by domain knowledge which lets you get respect “for free” to leverage to ratchet up those skills. So I’ll adjust what I said to mean you are racing against your engineering skill atrophy to develop those leadership skills. Once you can’t code anymore, it gets a lot harder to do so.