This is my favourite article on this topic https://fractio.nl/2014/09/19/not-a-promotion-a-career-chang...
Common Mistakes of New Engineering Managers
51–60 of 224 posts
Re: Common Mistakes of New Engineering Managers
#52I've been an engineering manager for a couple of years. I'm still expected to do 50% engineering and 50% people management. As the article describes, it is a struggle to do both well. I don't see this responsibility split changing in my current role. I do often wonder what it would be like to be 100% people focused, and whether or not I would miss engineering too much. When my role first changed, I was very intimidat…
I’m in the same boat.
In the span of two years, my ability to even review code and spot simple mistakes has rotted (I’ve coded for many years; I was pretty good at it).
Meanwhile my team size has doubled, and I’m left feeling I’ve bitten off more than I can chew.
These days I feel I’ve made a mistake. Even one-on-ones feel rote.
Re: Common Mistakes of New Engineering Managers
#53I 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 have ever worked on looks like this:
Product manager: Has Eng manager: Highly technical, has institutional knowledge of codebase + understands the politics of the org. Has recruits, shields devs from institutional nonsense.
Senior Dev / Tech lead: Trusted by eng manager to independently make arch level decisions. Can mentor / peer with / support other devs.
Dev1: Specialist in one relevant aspect of stack, but with general knowledge (can pick up any ticket if needed)
Dev2: Same as above, different specialty
QA: Half-time dedicated QA resource
UI/UX Designer: 33-50% time for team.
Project Manager: Half-time dedicated resource. Owns Jira, scrum master etc as noted above.
This group is flexible, resilient, and plays to people's strengths. If you don't have a project manager then yes it can be left to the eng manager or tech lead, but it's not ideal.
Re: Common Mistakes of New Engineering Managers
#54Earlier quoted context omitted.
It's been over a decade since I've worked at a company with managers. However, it was common for the top programmers to make more money than their managers there. Programming and managing are completely different jobs that accomplish different things for the organisation, but they are typically arranged in a top-down fashion, the manager has power over the programmer. A manager's job is to do the function of interact…
There are companies where managers are truly in a supporting function. I'm not here to advertise but my last two jobs were like that.
I agree. I work in a matrixed consulting organization. I have a "People Lead" who guides my career development, and I'm handed off onto projects to "Project Leads" who guide the day to day. And I use the word guide intentionally. When I'm staffed to a project, my role as a project member is to look for the project lead for finance and schedule and PM direction, and maybe to a principal consultant if there is one to guide technical direction, but I'm an IC and expected to do my work. My People lead solicits feedback from those I work with, the project leads etc. But is disconnected from my day to day, so there's no feeling of power, just a willingness to help me with my goals.
Re: Common Mistakes of New Engineering Managers
#55Just wondering, is job hopping as engineering manager as easy as coder/individual contributor?
It seems like the market for people with focus on soft skills is way more saturated (we get many more applications for project management roles than for software developers for example).
Re: Common Mistakes of New Engineering Managers
#56In about 90% of companies I’ve seen they expect you to do all the manager things and be an engineer too. It’s not so much a mistake individuals make as that it’s an explicit expectation that you’ll be wearing multiple hats. Folks generally get bombarded to manager because there’s no career ladder and this is what people think they have to do next to be able to continue to grow. And once you become a manager it doesn’…
> And once you become a manager it doesn’t suddenly create a head count to backfill the “loss” of an engineer so there is continued pressure on you to do both.
That must be on the top of your “new engineering manager” TODO list.
Re: Common Mistakes of New Engineering Managers
#57I disagree about 'Still doing much technical work' being a problem. The author incorrectly infers that a manager writing code is going to take away developers' freedom. It's the opposite. The way I manage developers is I design the system into small projects with separate concerns and which can be easily integrated together. With the participation of the team, we discuss and iterate over the design of interfaces betw…
I wouldn’t want to work for you, since it sounds like I would be put into a small box where I would have limited value and potential for growth. The only way to produce more value is to finish my projects faster. No thanks.
Re: Common Mistakes of New Engineering Managers
#58Earlier quoted context omitted.
Managers should get paid more than engineers.
I am a manager, and I disagree. The ranges overlap: an early career engineer will definitely be paid less than an early career manager... but a top engineer should be able to earn more than the vast majority (if not all) of the managers.
Not true. The idea that an IC is going to out contribute a top manager who oversees dozens of lower tier ICs doesn't make a whole lot of sense.
A good manager is a productivity multiplier which is why the top companies spend an arm and leg training up their managers.
The real issue is that is much easier to manage a group of top engineers than it is to manage a group of engineers who think that they are top engineers.
Re: Common Mistakes of New Engineering Managers
#59Earlier quoted context omitted.
Sure, but here lies the importance of my point: you get to be responsible either way, but at least you get to make your own call. If you turn that around and fail to deliver "because architects overdesigned it" everyone is going to give 0 f*cks - it's still your fault.
Yup, a tough call to make for sure and certainly grey areas with no clear path. When things fail, folks are quick to pass the buck and it's best to have as much recourse in your back pocket as possible. Don't give yourself a bigger mountain to climb so to speak.
Yes, this is situational. As mentioned it was a recurring pattern so a dysfunction peculiar to that particular org.
What happens is that many non-coding architects (sorry folks, not all of you but plenty enough) are essentially junior developers with little experience who negotiated themselves into these positions. Which is not that a big deal if they feel themselves part of the team and are grounded in the situation and open minded about debate. But unrestrained they build Daedalus wings and in the end it's you who get to do the falling.
You as a manager with engineering background have better comprehension of your team, with its strengths and weaknesses. You navigate the project leveraging the former and avoiding the latter, and if third party (neither the customer requirements nor your team) starts meddling it's not going to end well.
Re: Common Mistakes of New Engineering Managers
#60Just wondering, is job hopping as engineering manager as easy as coder/individual contributor? It seems like the market for people with focus on soft skills is way more saturated (we get many more applications for project management roles than for software developers for example).
Project managers != engineering managers.
Project management is a pretty saturated field, you are correct. Engineering team management is considerably less saturated and EMs are just as in-demand as ICs.
However, much of the value of a good EM is derived as someone who builds and grows a team over a long period of time, so you don't see nearly as much short-term job hopping as you do with ICs.