19 ms·

Common Mistakes of New Engineering Managers

328 points by ochronus 6y ago

willmunn 6y ago
This sounds like the kind of role a lot of good engineers get promoted to unwillingly/unknowingly, how do you avoid being assigned this role and remain a valued engineer once you have experience?
- ochronus 6y ago
  Yup, that's a common career path mistake companies do - making the only possible 'next step' for senior engineers to become managers. If your company doesn't have a strong career path for senior ICs, you should push for one
  - boring_twenties 6y ago
    Honest question -- why does there need to be a "next step?" 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.
    - elcomet 6y ago
      That's the "next step". In some companies the only way to earn top money is becoming a manager.
    - galkk 6y ago
      Because of title inflation, for example.
    - vasco 6y ago
      Because some places have titles and so all places need to have titles, lest they be branded as not "helping you grow".
    - ochronus 6y ago
      The need comes from the folks feeling stuck - it doesn't "have" to be that way. I've also had engineers making more money than me and looking at their impact it was well justified - the question is not only money but the sense of growth and acknowledgement of growth from the company's side - and there's a clear need for that. A bigger salary is just one (pretty volatile) form of it.
    - goatinaboat 6y ago
      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 interacting with the wider organisation in order to determine the best way for the programmer to spend his time, in effect it's a research job, then he presents the programmer with the results of his research and they both agree that the most value can be added to the organisation by working on bug X today instead of feature Y. But what actually happens is the manager says "do this, because I said so, and if you don't I'll block your next raise". Or so-called engineering managers cherry-pick the most rewarding work for themselves and assign the unfulfilling work to subordinates as punishment. That's deeply dysfunctional but it's what happens when you have a group who wants to do real work, and another group who has plenty of time on their hands for full-time politicking.
      - ochronus 6y ago
        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.
        goatinaboat 6y ago
        here are companies where managers are truly in a supporting function. I'm not here to advertise but my last two jobs were like that Unless programmers have equal knowledge of and input into their managers salary as their manager does in their's, there's still that fundamental top-down structure.
        mtberatwork 6y ago
        I am doubtful. If the managers are writing the performance reviews, they are not in a supporting function at all. They are the arbiters of the subordinate's success in the company and that is a vertical relationship.
        Pasorrijer 6y ago
  - taurath 6y ago
    The problem is when it comes time to choose a direction, its gonna be you vs the person with N direct reports who can make it happen. I've seen companies give up on this and turn principles into directors - that hasn't worked out well either. It seems to be a pretty bad problem with the standard hierarchical way businesses are set up. I've heard Goog does a bit better with a bit more autonomy so people can gravitate towards good ideas, but have also heard plenty of downsides. Maybe a new way to structure employees could come about?
- MrBuddyCasino 6y ago
  Become a freelancer.
- Cthulhu_ 6y ago
  Negotiate, I guess; on the one side as a good engineer you want the recognition (and pay) that goes with it, so for yourself you should ask for a raise or promotion to a title like idk, "senior principal engineer". But for the leadership skills, you should push to hire a dedicated manager type, who works alongside you and does the people management part.
- SomeHacker44 6y ago
  My company bifurcates people managers and ICs in engineering roles. Each level has both starting at tech lead/manager. Next is principal/director. Even VP has two tracks, though I have met only one IC VP. SVP and up are always people managers. AFAIK comp is the same. I help my senior engineers and leads understand their preferences and hit the path they want.
- loloquwowndueo 6y ago
  Say “no” when offered the role, if you don’t want it :) Keep the Peter principle in mind always and recognize when a promotion would actually “diminish your value to the organization” - that’s a great way to sell it so you’re not seen as just passing on the offer. https://en.m.wikipedia.org/wiki/Peter_principle https://en.m.wikipedia.org/wiki/Peter_principle
- buro9 6y ago
  > how do you avoid being assigned this role and remain a valued engineer once you have experience? Change company. If the only progression for an engineer is to become a manager, change company to one that allows an engineer to continue growing, continue learning, and continue to earn more. Some signs a company will force you to become a manager to progress: 1. Artificial ceilings: "We have Principal and Staff Engineers, but those are defined as having had impact outside the company so you cannot become one as your work only has impact internally" - effectively these titles are only offered to strategic hires and it's not attainable from inside the company 2. Managers paid more than the top engineers. 3. Title inflation as this stifles actual growth and learning and tends to limit overall earnings forcing you to look to change your career to find new challenges and earnings even though you want to be an IC and continue to do engineering. Unless a company truly has a clear progression for ICs with learning, growth and earnings all factored in, and that the IC progression goes all the way to near the top of the company, and it's achievable within the company... then you're going to reach the point that you'll look at the manager career and think it's the only way forward. It isn't, and it's not even forward it's to the side and backwards a bit (you reset your career and start at the lowest level of a new track). If you can't progress as an engineer and wish to... change company.
  - nojito 6y ago
    Managers should get paid more than engineers.
    - buro9 6y ago
      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.
      - nojito 6y ago
        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.
redis_mlc 6y ago
My favorite things old engineering managers say when they're insecure: - "I'm an architect, too." - "You know, I have a M. Eng." You know you're on their shit list when you hear that. lol.
29athrowaway 6y ago
I 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 most importantly, how to classify technical problems, how to analyze requirements, how to plan, estimate, communicate on deliverables and releases, etc. If you have the hard skills, it's fine to spend most of your effort growing your soft skills. But if you don't have the hard skills, you'll have to focus on that as well. You can delegate things to different team members, but at the end of the day, the responsibility is still yours. Team members can "own" things, but you're still responsible if they don't execute. And in order to do that efficiently, you have to be prepared to ask the right questions to the right people, and that requires hard skills.
- ochronus 6y ago
  Both points you raise are very valid! 1. Growing in the 'soft skills' areas doesn't mean you should stop growing in engineering excellence - that's the problem with one-sided articles like this (I am the author ) 2. Super important point about that you don't delegate accountability! Thanks for sharing!
- watwut 6y ago
  I had multiple managers that had little or no technical background. They were among the worst managers I had, not a single one was efficient or good. People with good technical background could be both bad and good.
- Tycho 6y ago
  IC = Individual contributor? Never seen it abbreviated before.
daenney 6y ago
In 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’t suddenly create a head count to backfill the “loss” of an engineer so there is continued pressure on you to do both. Once career ladders start to get better defined this starts to change too, and as the size of the company increases manager and IC responsibilities end up being different people. But companies seem to only figure this out at the 500-1000+ employee threshold.
- mynegation 6y ago
  > 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.
  - daenney 6y ago
    It usually is. But the fact that it’s on the top of the list doesn’t mean there’s head count available. Most organisations do this through planning phases and depending on how often these happen it can be a while. Then add the time it actually takes to hire someone.
- alistairSH 6y ago
  Folks generally get bombarded to manager because there’s no career ladder That's a pretty serious organizational flaw. At my employer, we have a well-define architect path that ends with "Technical Fellow" which on the job matrix is parallel with director-level management. As a developer, I see 4 basic career tracks. Developer-track - caps out at principal developer, thought most people in this role are capable of architectural work within their product/tech-stack. Architect-track - high-level strategic technical decision making, caps out at Technical Fellow. Business-track - eventual move into a BA or Product Management role. Management-track - typically moves in scrum master or project management role, then into full-time personal management. I started down the architect track, then hopped over to management because I wanted to challenge myself (at the time, leading people was WAY WAY WAY outside my comfort zone), not because I was forced into it due to lack of career growth.
mdekkers 6y ago
Nice read. I can also strongly recommend Rands (Michael Lopp) who has a great blog https://randsinrepose.com/ https://randsinrepose.com/ and wrote "Managing Humans" - an amazing book on the subject
- ochronus 6y ago
  OP here - I love Rands' works! Thanks for the link
- JimDabell 6y ago
  He also runs Rands Leadership Slack, which is a useful Slack community for tech leaders: https://randsinrepose.com/welcome-to-rands-leadership-slack/ https://randsinrepose.com/welcome-to-rands-leadership-slack/
  - ochronus 6y ago
    +1 , I'm in there, it's a really nice community. Another I can recommend: https://engmanagers.github.io/ https://engmanagers.github.io/
varjag 6y ago
I was in that role nearly two decades ago and can confirm it's spot on. Would add that you also need enough self confidence to stand your ground in discussions with upper management: this affects the outcomes on some points made in the article. Also, one should pretty much ignore unsolicited input/help from non-stakeholders in the project.
- SteveNuts 6y ago
  Can you give an example of what you mean by input from non stakeholders?
  - varjag 6y ago
    Depends on the org structure. In the one I was, architects were siloed off from the projects in a parallel sub-unit in the department, making it a bit of an ivory tower. They would issue design and scope decrees without facing any schedule pressures themselves. It took me a while to realize that most of my managing peers were quietly* ignoring them, delegating the actual decisions to the team. (*) As in, amend them to a workable design through a few status updates rather than making a stand-off in the initial meeting.
    - mtberatwork 6y ago
      A situation like this can backfire quickly though. If the project fails or a setback occurs, the architects can quickly say that the engineers weren't following the original design and specifications.
      - varjag 6y ago
        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.
        6y ago
mouzogu 6y ago
Very good read. Thanks a lot for sharing.
ChrisMarshallNY 6y ago
I was an engineering manager for 25 years. I could say lots on the topic, but my dance card is pretty full, right now. It's a nice read. There's a ton of other pitfalls (both for newer and more experienced managers). I gave a quick shortlist in a comment on an earlier thread[0]. The author has a number of articles in a similar vein. I think they are pretty good[1]. [0] https://news.ycombinator.com/item?id=26231963 https://news.ycombinator.com/item?id=26231963 [1] https://ochronus.online https://ochronus.online
irmbrady 6y ago
I'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 intimidated by doing one-on-ones. I never felt satisfied with the one-on-ones/catch-ups I had with the managers throughout my career, and I wanted to make sure I was doing a good job with that aspect of my role. I initially did lots of research on how to do one-on-ones, but it was only after getting experience talking to people that I finally felt comfortable. I started getting some nice feedback from my lines, so I wrote some thoughts about how I like to do one-on-ones: https://www.markbrady.net/blog/how-to-do-one-on-ones-as-a-manager https://www.markbrady.net/blog/how-to-do-one-on-ones-as-a-ma... I think good one-on-ones are very important to keep people happy and productive. I'd recommend any new engineering managers to spend time learning how to do them.
- alexpetralia 6y ago
  Great writeup, thank you.
- cryptica 6y ago
  It's kind of ridiculous for a company to 'expect' 50% engineering and 50% people management. It should be fluid and vary depending on the skill level of the team and the complexity and criticality of various projects over time. It shouldn't be fixed at 50% like some magic number.
  - jessermeyer 6y ago
    My hope is that those illustrate the 'spirit of the law' of taking both responsibilities equally serious. An issue is when middle management, so often comprised of literally minded number crunchers, interferes.
  - fatnoah 6y ago
    Agree. For all but the smallest of teams, this just means being both a poor manager and a poor engineer. Trying to balance this was one of my first mistakes as a manager. I was a roadblock to shipping things because of my limited coding bandwidth, and I wasn't spending enough time focusing on growing people, having career conversations, ensuring my org was structured for success, etc. Finally putting down the keyboard was the key to me being a much better manager. Yes, I don't have the depth on every framework like I used to, but I still have over 15 years of hands-on-keyboard experience and the "engineering" part of "software engineering" is less about fluency in languages, but more about how to effectively set goals, mitigate impact of external dependencies, design for performance, etc. That knowledge is still very useful.
shortlived 6y ago
> there’s the concept of the ‘tech lead manager’ which is supposed to be 50% programming and 50% people management – in my experience it doesn’t work well in the long run I discovered this organically as I grew into an engineering manager role that lasted about 8 years. Software companies in the US though expect the opposite to the point where I found it better to return to an individual contributor role and am now wondering how my own truths about the role can be so different from the norm...
elevatortrim 6y ago
In my experience the "mistakes" mentioned in the article are mostly a motivation problem. The assumption is that a successful engineering manager is one that makes their team thrive whereas in reality the companies only reward individual success. Same goes for developers, best developers only get junior->senior promotions while the ones that join the most meetings and do strategical thinking goes towards engineering management and leadership. 1. Still doing much technical work If the technical work tackles an important bottleneck or solves an immediate internal problem for the company, this will be seen as incredibly valuable (even more so compared to the eng. manager were still a developer) as opposed to delegating it. 2. Not giving (enough) holistic feedback In my experience, managers never evaluated based on how helpful they are to their teams. They only need to avoid negative feedback, which is not necessarily aligned with being honest and direct to their reports. 3. Doing all the project management There's an urgent problem. Eng manager dives in, quickly fetches developers from teams and micro-project-manages them until the resolution and moves on. This is recognised as a success. 4. Not sharing enough information with the team Sharing is good for the team members, not necessarily relevant or hurtful for the managers' success. 5. Not doing one-on-one coaching Same as above, managers help their reports out of good will if they do but if they are evaluated on their help with delivery and not the health of their team, they do not have the motivation.
- ochronus 6y ago
  Thanks for bringing this up! This is all definitely true for way too many companies :/ One of the questions I ask when I think about switching companies as an engineering manager is: "How will you know if I'm doing a sh*tty job?" - you'd be surprised how few companies can give a proper answer to this.
tacticalDonut 6y ago
I've come to realize that the promise of a 50/50 split between technical work and management after getting promoted to a data science technical lead manager is not something that is feasible within my org. Unfortunately, I'm at an organization in which the only way up is for ICs to move to management. So I'm leaving to another company that has much more runway for IC career progression. I've got a great relationship with my current employer, so I've mentioned this career progression issue to them in my exit interview and it's something that middle management is tracking, but getting corporate leadership on board to change their thinking is difficult since our revenue is driven by billable work on a man hour basis. This creates an incentive for people to build teams of direct reports under them and grow a business line/contract to increase revenue in order to show value and accelerate career growth. Until the company can get more service contracts where they're selling software/licenses/support instead of butts in seats, I don't see this paradigm changing any time soon. Very interesting how business models drive things like this. Obvious in hindsight, but still interesting to think about in terms of incentives driving org structure.
- rathboma 6y ago
  Lack of IC progression is a real problem. I used to manage teams and missed engineering too much, so I quit to be a freelance engineering consultant. It felt like the best way to progress as an IC for me. Bigger tech companies do a better job of IC career paths than others, but it still feels like your influence is muted compared to managers.
ElectricMind 6y ago
I think those 2 words should not be in one title. Recipe for hot mess. Choose One and stick to it. I am not sure what kind of mentality to mix both. There are not compatible positions. Cost of context switching is not cheap.
cryptica 6y ago
I 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 between those components/projects. Then when it comes time to implement, I assign 'ownership' of each project to a developer (with consultation with them). Then with the exception of a few basic guidelines, they can implement it however they want. We just do regular peer reviews of each other's work. We tolerate code style variations between different projects but each project must be internally consistent. So far all our projects never needed more than 2 people to implement (each one having 1 developer as the project owner). At the end, we integrate maybe 10 different projects into the final working product (which gets its own repo). This approach to development is extremely fast and robust (very few bugs which are easily caught and fixed). We don't even need special tools or programming languages. We just use plain JavaScript; never had the need to use TypeScript, the code is very easy to follow so it's not a problem. All you need is to have small projects with clear separation of concerns. The trick is to not invent new abstractions; all technical abstractions should come from the specification and be understood by non-technical people. Also all components/projects should have simple interfaces between each other (only basic types that can easily be serialized into a JSON string). Different projects/components should never pass 'live instances' to each other; that would indicate poor separation of concerns.
- BlargMcLarg 6y ago
  Thanks for this. I always held the opinion the "perfect" leader would be a hybrid of leading + devving, flexible enough to switch to 100% leading if need be, yet perfectly capable of picking up any technical work required, therefore never landing in the above situation out of inability. I've never seen the problem "we don't have enough management capacity". On the other hand, I've seen plenty of non-/low-technical people become engineer managers, flailing their arms when there is too much work and not enough time. Only making the situation worse by stressing everyone out and taking up additional time in communication.
cryptica 6y ago
Under "Still doing much technical work": > Focusing on your team’s health and growth will pay much higher dividends than still being half an engineer. This logic is completely flawed as it assumes that the manager has reached a point in their career when they have nothing else to teach and nothing else to learn about coding. I'm an excellent coder and manager but I'm still learning all the time, even after 15 years. My team greatly benefits from me still being in touch with the code. Also, it helps me to make stronger arguments about why we should avoid using certain tools or blindly following hype. The best engineering managers I've ever had were coding alongside the developers. The worst ones were not. This point about "Still doing much technical work" being a problem could not be further from the truth.
- P_I_Staker 6y ago
  Counter point: There's a lot of delusional engineering managers that say they want to be "hands-on", but that's not in the best interest of the team. They are either not top notch coders, or they can't juggle all the work. What they're doing is being selfish, because they don't want to be a manager, they want power and money. They need to grow up and do what they signed up for.
tenaciousDaniel 6y ago
As a new eng manager with about a year under my belt, #1 really hits the nail on the head. I couldn’t step away from the code because I was so used to IC. Now as a result, I’m having very difficult discussions about promotions (or lack thereof), because I didn’t give my team the chance to grow.
- ochronus 6y ago
  This sounds like it's not too late to turn the ship around. It's also tricky, for some folks it's enough to see space for growth and they do it automagically, for others you need lots of conversations and gentle nudging. Don't be too hard on yourself, just start fruitful career discussions with your team.
alwaysanon 6y ago
This is my favourite article on this topic https://fractio.nl/2014/09/19/not-a-promotion-a-career-change/ https://fractio.nl/2014/09/19/not-a-promotion-a-career-chang...
iandanforth 6y ago
I 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 <=3 teams knows company product / strategic goals / customer needs. Sets high level goals, updates those in response to scope estimates, coordinates with product org. Eng manager: Highly technical, has institutional knowledge of codebase + understands the politics of the org. Has <=3 teams. Sets tone, handles dev career growth, mediates/prevents conflicts, 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.
- alistairSH 6y ago
  I just left a team that was structured similarly. It was a pleasure managing them. Team members were: - Manager (me), BA - managed backlog and some project management (actual title was principal dev, but she wanted a role change), 2x senior developers (both capable of architectural work), 2x developers, 2x test engineers, 0.5 Product manager (they report through their own branch of the org chart and cover several related products). Additionally, I had 2.5 developers working on a different project, run as a separate agile team. New team is 1 architect, 1 senior dev, 1 dev, 1 test engineer. BA and PM support comes from elsewhere, which is a big change fo me. Also in a new technical area (SRE vs 20 years of product/app dev). Fun, but stressful. I'll reserve judgement on the lack of BA/PM until I'm a few months into the role.
  - iAmAPencilYo 6y ago
laurentdc 6y ago
Just 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).
- josephmosby 6y ago
  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.
  - ochronus 6y ago
    +1 Author here: the other thing is (at least for me) that it becomes really hard to leave my team after a while because they just grow on me. I feel responsible for their wellbeing and want to make sure they are set up for success. When I was an IC it was much easier (in my head).
gfodor 6y ago
1. 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 with chops and respect into a PHB, unless you happen to have been born with natural leadership skills (you probably haven’t) 6. Realize you are now just a mediocre manager who can no longer return to the engineering track since you cannot compete with other candidates 7. Drag yourself to retirement by slogging through life as a relatively poor middle manager
- ta988 6y ago
  Interstingly I found a similar career path in many scientists. Some of them are getting completely out of touch (you never see them in a lab, they don't learn new techniques, they rigidly defend things they learned before but that is obsolete) and just presenting their students/postdocs works and editing papers.
- dhanna 6y ago
  I’m dealing with this right now with my manager and it’s infuriating.
- halfmatthalfcat 6y ago
  That's exactly why I was adamant (on condition of taking my current manager role) that I was always going to be coding. But I agree with most of these steps and when I was solely an engineer, I resented managers in 4 - 7. It was my goal to never be like that.
- Koshkin 6y ago
  In the other universe: 1. Do not become an engineering manager. 2. If pushed (e.g. by not getting raises), move on.
  - dominotw 6y ago
    > move on. move on to where? managers get paid more than IC on average everywhere. Sure, if you are staff level stellar IC you might get paid on par with management but most ppl aren't.
bzzt 6y ago
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.
- cwxm 6y ago
  What about career growth? Great managers have helped me grow so much, and advocate for the steps I want in my career.
  - pracer 6y ago
    I would agree with that. But the problem (already mentioned) is: how could a manager help you grow in the technical field if the manager is out of touch with it and didn't do coding or dev work for years? In any case, if I have to choose (and more times than not I wished I could) I would choose the option of the first comment.
poorman 6y ago
Something I think that's often overlooked is your relationship with your peers after the transition from "peer" to "manager". It's tough because you want to continue to treat your direct reports as peers, but that only makes it extremely awkward for them since the relationship dynamic has changed.
- bzzt 6y ago
  I agree very much, I hate when managers try to pretend to be your peer when that's clearly not the nature of the relationship. It's actually a huge pet peeve of mine: managers who always want to put their own modern twist on being a manager. Like I'm your boss, but actually I don't like to make decisions and I'm also a cool guy who's just your friend. They try to avoid the negative stereotype of the manager, but just end up not doing their job and leaving people confused, and making for a very awkward environment.
airhead969 6y ago
Completely agree with these points. It's absolutely unreasonable and unrealistic to be an engineering manager and a technical lead. Management is a full-time job consumed mostly by minutia and bureaucracy (mandatory meetings and paperwork) so that the team doesn't have to deal with it. I'd add: 6. Defend the team, especially pushback unreasonable, untenable changes from on high. 7. Peter principle: title doesn't assure greater competency. Don't micromanage experts. Seek their knowledge, opinions, be curious, and ask questions. 8. Go-giver and mentor. Always help staff grow their careers, confidence, and capabilities, wherever that takes them. 9. Be helpful to the team and its individuals without being annoying. Replace that crap printer that wastes everyone's time. Fix that door that maintenance ignores. Whatever it takes. Go above and beyond, especially when it's crunch time.
scrooched_moose 6y ago
My #6): Not "letting go" to be a manager, which turns them into a micromanager. I got stuck under a brand new Engineering Manager in what is effectively his old role during the last reshuffle, and he still has to be intimately involved in every aspect of every project because it was his job. Every minor decision goes through him and I don't think I've attended a meeting in over a year where he wasn't part of it. Between other issues with #3 and #4 it's a nightmare. I've been bringing up these issues for most of that time (it's gone from diplomatic to brutally honest over the last few months) and nothing changes. Thankfully the job market is starting to rebound after tanking during early Covid.
coderdd 6y ago
I highly recommend "Managing Yourself and Others" from Gerald Weinberg - https://leanpub.com/managingyourselfandothers https://leanpub.com/managingyourselfandothers Or anything from him, really.
lmilcin 6y ago
The single biggest mistake I see new managers make consistently is not training your self awareness and being retrospective. Everybody makes mistakes. The trouble is if you are not on the lookout to identify, correct and learn from them. In my opinion, every other advice is secondary as it can only work if you are honest with yourself and wanting to apply it to improve your work. No advice will help if you think you are better than everybody else and you attribute all your failures to other people letting you down or working against you.

328 points by ochronus 6y ago

This sounds like the kind of role a lot of good engineers get promoted to unwillingly/unknowingly, how do you avoid being assigned this role and remain a valued engineer once you have experience?

ochronus 6y ago
Yup, that's a common career path mistake companies do - making the only possible 'next step' for senior engineers to become managers. If your company doesn't have a strong career path for senior ICs, you should push for one
- boring_twenties 6y ago
  Honest question -- why does there need to be a "next step?" 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.
  - elcomet 6y ago
    That's the "next step". In some companies the only way to earn top money is becoming a manager.
  - galkk 6y ago
    Because of title inflation, for example.
  - vasco 6y ago
    Because some places have titles and so all places need to have titles, lest they be branded as not "helping you grow".
  - ochronus 6y ago
    The need comes from the folks feeling stuck - it doesn't "have" to be that way. I've also had engineers making more money than me and looking at their impact it was well justified - the question is not only money but the sense of growth and acknowledgement of growth from the company's side - and there's a clear need for that. A bigger salary is just one (pretty volatile) form of it.
  - goatinaboat 6y ago
    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 interacting with the wider organisation in order to determine the best way for the programmer to spend his time, in effect it's a research job, then he presents the programmer with the results of his research and they both agree that the most value can be added to the organisation by working on bug X today instead of feature Y. But what actually happens is the manager says "do this, because I said so, and if you don't I'll block your next raise". Or so-called engineering managers cherry-pick the most rewarding work for themselves and assign the unfulfilling work to subordinates as punishment. That's deeply dysfunctional but it's what happens when you have a group who wants to do real work, and another group who has plenty of time on their hands for full-time politicking.
    - ochronus 6y ago
      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.
      - goatinaboat 6y ago
        here are companies where managers are truly in a supporting function. I'm not here to advertise but my last two jobs were like that Unless programmers have equal knowledge of and input into their managers salary as their manager does in their's, there's still that fundamental top-down structure.
      - mtberatwork 6y ago
        I am doubtful. If the managers are writing the performance reviews, they are not in a supporting function at all. They are the arbiters of the subordinate's success in the company and that is a vertical relationship.
      - Pasorrijer 6y ago
- taurath 6y ago
  The problem is when it comes time to choose a direction, its gonna be you vs the person with N direct reports who can make it happen. I've seen companies give up on this and turn principles into directors - that hasn't worked out well either. It seems to be a pretty bad problem with the standard hierarchical way businesses are set up. I've heard Goog does a bit better with a bit more autonomy so people can gravitate towards good ideas, but have also heard plenty of downsides. Maybe a new way to structure employees could come about?
MrBuddyCasino 6y ago
Become a freelancer.
Cthulhu_ 6y ago
Negotiate, I guess; on the one side as a good engineer you want the recognition (and pay) that goes with it, so for yourself you should ask for a raise or promotion to a title like idk, "senior principal engineer". But for the leadership skills, you should push to hire a dedicated manager type, who works alongside you and does the people management part.
SomeHacker44 6y ago
My company bifurcates people managers and ICs in engineering roles. Each level has both starting at tech lead/manager. Next is principal/director. Even VP has two tracks, though I have met only one IC VP. SVP and up are always people managers. AFAIK comp is the same. I help my senior engineers and leads understand their preferences and hit the path they want.
loloquwowndueo 6y ago
Say “no” when offered the role, if you don’t want it :) Keep the Peter principle in mind always and recognize when a promotion would actually “diminish your value to the organization” - that’s a great way to sell it so you’re not seen as just passing on the offer. https://en.m.wikipedia.org/wiki/Peter_principle https://en.m.wikipedia.org/wiki/Peter_principle
buro9 6y ago
> how do you avoid being assigned this role and remain a valued engineer once you have experience? Change company. If the only progression for an engineer is to become a manager, change company to one that allows an engineer to continue growing, continue learning, and continue to earn more. Some signs a company will force you to become a manager to progress: 1. Artificial ceilings: "We have Principal and Staff Engineers, but those are defined as having had impact outside the company so you cannot become one as your work only has impact internally" - effectively these titles are only offered to strategic hires and it's not attainable from inside the company 2. Managers paid more than the top engineers. 3. Title inflation as this stifles actual growth and learning and tends to limit overall earnings forcing you to look to change your career to find new challenges and earnings even though you want to be an IC and continue to do engineering. Unless a company truly has a clear progression for ICs with learning, growth and earnings all factored in, and that the IC progression goes all the way to near the top of the company, and it's achievable within the company... then you're going to reach the point that you'll look at the manager career and think it's the only way forward. It isn't, and it's not even forward it's to the side and backwards a bit (you reset your career and start at the lowest level of a new track). If you can't progress as an engineer and wish to... change company.
- nojito 6y ago
  Managers should get paid more than engineers.
  - buro9 6y ago
    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.
    - nojito 6y ago
      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.

redis_mlc 6y ago

My favorite things old engineering managers say when they're insecure: - "I'm an architect, too." - "You know, I have a M. Eng." You know you're on their shit list when you hear that. lol.

29athrowaway 6y ago

I 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 most importantly, how to classify technical problems, how to analyze requirements, how to plan, estimate, communicate on deliverables and releases, etc. If you have the hard skills, it's fine to spend most of your effort growing your soft skills. But if you don't have the hard skills, you'll have to focus on that as well. You can delegate things to different team members, but at the end of the day, the responsibility is still yours. Team members can "own" things, but you're still responsible if they don't execute. And in order to do that efficiently, you have to be prepared to ask the right questions to the right people, and that requires hard skills.

ochronus 6y ago
Both points you raise are very valid! 1. Growing in the 'soft skills' areas doesn't mean you should stop growing in engineering excellence - that's the problem with one-sided articles like this (I am the author ) 2. Super important point about that you don't delegate accountability! Thanks for sharing!
watwut 6y ago
I had multiple managers that had little or no technical background. They were among the worst managers I had, not a single one was efficient or good. People with good technical background could be both bad and good.
Tycho 6y ago
IC = Individual contributor? Never seen it abbreviated before.

daenney 6y ago

In 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’t suddenly create a head count to backfill the “loss” of an engineer so there is continued pressure on you to do both. Once career ladders start to get better defined this starts to change too, and as the size of the company increases manager and IC responsibilities end up being different people. But companies seem to only figure this out at the 500-1000+ employee threshold.

mynegation 6y ago
> 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.
- daenney 6y ago
  It usually is. But the fact that it’s on the top of the list doesn’t mean there’s head count available. Most organisations do this through planning phases and depending on how often these happen it can be a while. Then add the time it actually takes to hire someone.
alistairSH 6y ago
Folks generally get bombarded to manager because there’s no career ladder That's a pretty serious organizational flaw. At my employer, we have a well-define architect path that ends with "Technical Fellow" which on the job matrix is parallel with director-level management. As a developer, I see 4 basic career tracks. Developer-track - caps out at principal developer, thought most people in this role are capable of architectural work within their product/tech-stack. Architect-track - high-level strategic technical decision making, caps out at Technical Fellow. Business-track - eventual move into a BA or Product Management role. Management-track - typically moves in scrum master or project management role, then into full-time personal management. I started down the architect track, then hopped over to management because I wanted to challenge myself (at the time, leading people was WAY WAY WAY outside my comfort zone), not because I was forced into it due to lack of career growth.

mdekkers 6y ago

Nice read. I can also strongly recommend Rands (Michael Lopp) who has a great blog https://randsinrepose.com/ https://randsinrepose.com/ and wrote "Managing Humans" - an amazing book on the subject

ochronus 6y ago
OP here - I love Rands' works! Thanks for the link
JimDabell 6y ago
He also runs Rands Leadership Slack, which is a useful Slack community for tech leaders: https://randsinrepose.com/welcome-to-rands-leadership-slack/ https://randsinrepose.com/welcome-to-rands-leadership-slack/
- ochronus 6y ago
  +1 , I'm in there, it's a really nice community. Another I can recommend: https://engmanagers.github.io/ https://engmanagers.github.io/

varjag 6y ago

I was in that role nearly two decades ago and can confirm it's spot on. Would add that you also need enough self confidence to stand your ground in discussions with upper management: this affects the outcomes on some points made in the article. Also, one should pretty much ignore unsolicited input/help from non-stakeholders in the project.

SteveNuts 6y ago
Can you give an example of what you mean by input from non stakeholders?
- varjag 6y ago
  Depends on the org structure. In the one I was, architects were siloed off from the projects in a parallel sub-unit in the department, making it a bit of an ivory tower. They would issue design and scope decrees without facing any schedule pressures themselves. It took me a while to realize that most of my managing peers were quietly* ignoring them, delegating the actual decisions to the team. (*) As in, amend them to a workable design through a few status updates rather than making a stand-off in the initial meeting.
  - mtberatwork 6y ago
    A situation like this can backfire quickly though. If the project fails or a setback occurs, the architects can quickly say that the engineers weren't following the original design and specifications.
    - varjag 6y ago
      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.
      - 6y ago

mouzogu 6y ago

Very good read. Thanks a lot for sharing.

ChrisMarshallNY 6y ago

I was an engineering manager for 25 years. I could say lots on the topic, but my dance card is pretty full, right now. It's a nice read. There's a ton of other pitfalls (both for newer and more experienced managers). I gave a quick shortlist in a comment on an earlier thread[0]. The author has a number of articles in a similar vein. I think they are pretty good[1]. [0] https://news.ycombinator.com/item?id=26231963 https://news.ycombinator.com/item?id=26231963 [1] https://ochronus.online https://ochronus.online

irmbrady 6y ago

I'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 intimidated by doing one-on-ones. I never felt satisfied with the one-on-ones/catch-ups I had with the managers throughout my career, and I wanted to make sure I was doing a good job with that aspect of my role. I initially did lots of research on how to do one-on-ones, but it was only after getting experience talking to people that I finally felt comfortable. I started getting some nice feedback from my lines, so I wrote some thoughts about how I like to do one-on-ones: https://www.markbrady.net/blog/how-to-do-one-on-ones-as-a-manager https://www.markbrady.net/blog/how-to-do-one-on-ones-as-a-ma... I think good one-on-ones are very important to keep people happy and productive. I'd recommend any new engineering managers to spend time learning how to do them.

alexpetralia 6y ago
Great writeup, thank you.
cryptica 6y ago
It's kind of ridiculous for a company to 'expect' 50% engineering and 50% people management. It should be fluid and vary depending on the skill level of the team and the complexity and criticality of various projects over time. It shouldn't be fixed at 50% like some magic number.
- jessermeyer 6y ago
  My hope is that those illustrate the 'spirit of the law' of taking both responsibilities equally serious. An issue is when middle management, so often comprised of literally minded number crunchers, interferes.
- fatnoah 6y ago
  Agree. For all but the smallest of teams, this just means being both a poor manager and a poor engineer. Trying to balance this was one of my first mistakes as a manager. I was a roadblock to shipping things because of my limited coding bandwidth, and I wasn't spending enough time focusing on growing people, having career conversations, ensuring my org was structured for success, etc. Finally putting down the keyboard was the key to me being a much better manager. Yes, I don't have the depth on every framework like I used to, but I still have over 15 years of hands-on-keyboard experience and the "engineering" part of "software engineering" is less about fluency in languages, but more about how to effectively set goals, mitigate impact of external dependencies, design for performance, etc. That knowledge is still very useful.

shortlived 6y ago

> there’s the concept of the ‘tech lead manager’ which is supposed to be 50% programming and 50% people management – in my experience it doesn’t work well in the long run I discovered this organically as I grew into an engineering manager role that lasted about 8 years. Software companies in the US though expect the opposite to the point where I found it better to return to an individual contributor role and am now wondering how my own truths about the role can be so different from the norm...

elevatortrim 6y ago

In my experience the "mistakes" mentioned in the article are mostly a motivation problem. The assumption is that a successful engineering manager is one that makes their team thrive whereas in reality the companies only reward individual success. Same goes for developers, best developers only get junior->senior promotions while the ones that join the most meetings and do strategical thinking goes towards engineering management and leadership. 1. Still doing much technical work If the technical work tackles an important bottleneck or solves an immediate internal problem for the company, this will be seen as incredibly valuable (even more so compared to the eng. manager were still a developer) as opposed to delegating it. 2. Not giving (enough) holistic feedback In my experience, managers never evaluated based on how helpful they are to their teams. They only need to avoid negative feedback, which is not necessarily aligned with being honest and direct to their reports. 3. Doing all the project management There's an urgent problem. Eng manager dives in, quickly fetches developers from teams and micro-project-manages them until the resolution and moves on. This is recognised as a success. 4. Not sharing enough information with the team Sharing is good for the team members, not necessarily relevant or hurtful for the managers' success. 5. Not doing one-on-one coaching Same as above, managers help their reports out of good will if they do but if they are evaluated on their help with delivery and not the health of their team, they do not have the motivation.

ochronus 6y ago
Thanks for bringing this up! This is all definitely true for way too many companies :/ One of the questions I ask when I think about switching companies as an engineering manager is: "How will you know if I'm doing a sh*tty job?" - you'd be surprised how few companies can give a proper answer to this.

tacticalDonut 6y ago

I've come to realize that the promise of a 50/50 split between technical work and management after getting promoted to a data science technical lead manager is not something that is feasible within my org. Unfortunately, I'm at an organization in which the only way up is for ICs to move to management. So I'm leaving to another company that has much more runway for IC career progression. I've got a great relationship with my current employer, so I've mentioned this career progression issue to them in my exit interview and it's something that middle management is tracking, but getting corporate leadership on board to change their thinking is difficult since our revenue is driven by billable work on a man hour basis. This creates an incentive for people to build teams of direct reports under them and grow a business line/contract to increase revenue in order to show value and accelerate career growth. Until the company can get more service contracts where they're selling software/licenses/support instead of butts in seats, I don't see this paradigm changing any time soon. Very interesting how business models drive things like this. Obvious in hindsight, but still interesting to think about in terms of incentives driving org structure.

rathboma 6y ago
Lack of IC progression is a real problem. I used to manage teams and missed engineering too much, so I quit to be a freelance engineering consultant. It felt like the best way to progress as an IC for me. Bigger tech companies do a better job of IC career paths than others, but it still feels like your influence is muted compared to managers.

ElectricMind 6y ago

I think those 2 words should not be in one title. Recipe for hot mess. Choose One and stick to it. I am not sure what kind of mentality to mix both. There are not compatible positions. Cost of context switching is not cheap.

cryptica 6y ago

I 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 between those components/projects. Then when it comes time to implement, I assign 'ownership' of each project to a developer (with consultation with them). Then with the exception of a few basic guidelines, they can implement it however they want. We just do regular peer reviews of each other's work. We tolerate code style variations between different projects but each project must be internally consistent. So far all our projects never needed more than 2 people to implement (each one having 1 developer as the project owner). At the end, we integrate maybe 10 different projects into the final working product (which gets its own repo). This approach to development is extremely fast and robust (very few bugs which are easily caught and fixed). We don't even need special tools or programming languages. We just use plain JavaScript; never had the need to use TypeScript, the code is very easy to follow so it's not a problem. All you need is to have small projects with clear separation of concerns. The trick is to not invent new abstractions; all technical abstractions should come from the specification and be understood by non-technical people. Also all components/projects should have simple interfaces between each other (only basic types that can easily be serialized into a JSON string). Different projects/components should never pass 'live instances' to each other; that would indicate poor separation of concerns.

BlargMcLarg 6y ago
Thanks for this. I always held the opinion the "perfect" leader would be a hybrid of leading + devving, flexible enough to switch to 100% leading if need be, yet perfectly capable of picking up any technical work required, therefore never landing in the above situation out of inability. I've never seen the problem "we don't have enough management capacity". On the other hand, I've seen plenty of non-/low-technical people become engineer managers, flailing their arms when there is too much work and not enough time. Only making the situation worse by stressing everyone out and taking up additional time in communication.

cryptica 6y ago

Under "Still doing much technical work": > Focusing on your team’s health and growth will pay much higher dividends than still being half an engineer. This logic is completely flawed as it assumes that the manager has reached a point in their career when they have nothing else to teach and nothing else to learn about coding. I'm an excellent coder and manager but I'm still learning all the time, even after 15 years. My team greatly benefits from me still being in touch with the code. Also, it helps me to make stronger arguments about why we should avoid using certain tools or blindly following hype. The best engineering managers I've ever had were coding alongside the developers. The worst ones were not. This point about "Still doing much technical work" being a problem could not be further from the truth.

P_I_Staker 6y ago
Counter point: There's a lot of delusional engineering managers that say they want to be "hands-on", but that's not in the best interest of the team. They are either not top notch coders, or they can't juggle all the work. What they're doing is being selfish, because they don't want to be a manager, they want power and money. They need to grow up and do what they signed up for.

tenaciousDaniel 6y ago

As a new eng manager with about a year under my belt, #1 really hits the nail on the head. I couldn’t step away from the code because I was so used to IC. Now as a result, I’m having very difficult discussions about promotions (or lack thereof), because I didn’t give my team the chance to grow.

ochronus 6y ago
This sounds like it's not too late to turn the ship around. It's also tricky, for some folks it's enough to see space for growth and they do it automagically, for others you need lots of conversations and gentle nudging. Don't be too hard on yourself, just start fruitful career discussions with your team.

alwaysanon 6y ago

This is my favourite article on this topic https://fractio.nl/2014/09/19/not-a-promotion-a-career-change/ https://fractio.nl/2014/09/19/not-a-promotion-a-career-chang...

iandanforth 6y ago

I 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 <=3 teams knows company product / strategic goals / customer needs. Sets high level goals, updates those in response to scope estimates, coordinates with product org. Eng manager: Highly technical, has institutional knowledge of codebase + understands the politics of the org. Has <=3 teams. Sets tone, handles dev career growth, mediates/prevents conflicts, 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.

alistairSH 6y ago
I just left a team that was structured similarly. It was a pleasure managing them. Team members were: - Manager (me), BA - managed backlog and some project management (actual title was principal dev, but she wanted a role change), 2x senior developers (both capable of architectural work), 2x developers, 2x test engineers, 0.5 Product manager (they report through their own branch of the org chart and cover several related products). Additionally, I had 2.5 developers working on a different project, run as a separate agile team. New team is 1 architect, 1 senior dev, 1 dev, 1 test engineer. BA and PM support comes from elsewhere, which is a big change fo me. Also in a new technical area (SRE vs 20 years of product/app dev). Fun, but stressful. I'll reserve judgement on the lack of BA/PM until I'm a few months into the role.
- iAmAPencilYo 6y ago

laurentdc 6y ago

Just 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).

josephmosby 6y ago
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.
- ochronus 6y ago
  +1 Author here: the other thing is (at least for me) that it becomes really hard to leave my team after a while because they just grow on me. I feel responsible for their wellbeing and want to make sure they are set up for success. When I was an IC it was much easier (in my head).

gfodor 6y ago

1. 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 with chops and respect into a PHB, unless you happen to have been born with natural leadership skills (you probably haven’t) 6. Realize you are now just a mediocre manager who can no longer return to the engineering track since you cannot compete with other candidates 7. Drag yourself to retirement by slogging through life as a relatively poor middle manager

ta988 6y ago
Interstingly I found a similar career path in many scientists. Some of them are getting completely out of touch (you never see them in a lab, they don't learn new techniques, they rigidly defend things they learned before but that is obsolete) and just presenting their students/postdocs works and editing papers.
dhanna 6y ago
I’m dealing with this right now with my manager and it’s infuriating.
halfmatthalfcat 6y ago
That's exactly why I was adamant (on condition of taking my current manager role) that I was always going to be coding. But I agree with most of these steps and when I was solely an engineer, I resented managers in 4 - 7. It was my goal to never be like that.
Koshkin 6y ago
In the other universe: 1. Do not become an engineering manager. 2. If pushed (e.g. by not getting raises), move on.
- dominotw 6y ago
  > move on. move on to where? managers get paid more than IC on average everywhere. Sure, if you are staff level stellar IC you might get paid on par with management but most ppl aren't.

bzzt 6y ago

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.

cwxm 6y ago
What about career growth? Great managers have helped me grow so much, and advocate for the steps I want in my career.
- pracer 6y ago
  I would agree with that. But the problem (already mentioned) is: how could a manager help you grow in the technical field if the manager is out of touch with it and didn't do coding or dev work for years? In any case, if I have to choose (and more times than not I wished I could) I would choose the option of the first comment.

poorman 6y ago

Something I think that's often overlooked is your relationship with your peers after the transition from "peer" to "manager". It's tough because you want to continue to treat your direct reports as peers, but that only makes it extremely awkward for them since the relationship dynamic has changed.

bzzt 6y ago
I agree very much, I hate when managers try to pretend to be your peer when that's clearly not the nature of the relationship. It's actually a huge pet peeve of mine: managers who always want to put their own modern twist on being a manager. Like I'm your boss, but actually I don't like to make decisions and I'm also a cool guy who's just your friend. They try to avoid the negative stereotype of the manager, but just end up not doing their job and leaving people confused, and making for a very awkward environment.

airhead969 6y ago

Completely agree with these points. It's absolutely unreasonable and unrealistic to be an engineering manager and a technical lead. Management is a full-time job consumed mostly by minutia and bureaucracy (mandatory meetings and paperwork) so that the team doesn't have to deal with it. I'd add: 6. Defend the team, especially pushback unreasonable, untenable changes from on high. 7. Peter principle: title doesn't assure greater competency. Don't micromanage experts. Seek their knowledge, opinions, be curious, and ask questions. 8. Go-giver and mentor. Always help staff grow their careers, confidence, and capabilities, wherever that takes them. 9. Be helpful to the team and its individuals without being annoying. Replace that crap printer that wastes everyone's time. Fix that door that maintenance ignores. Whatever it takes. Go above and beyond, especially when it's crunch time.

scrooched_moose 6y ago

My #6): Not "letting go" to be a manager, which turns them into a micromanager. I got stuck under a brand new Engineering Manager in what is effectively his old role during the last reshuffle, and he still has to be intimately involved in every aspect of every project because it was his job. Every minor decision goes through him and I don't think I've attended a meeting in over a year where he wasn't part of it. Between other issues with #3 and #4 it's a nightmare. I've been bringing up these issues for most of that time (it's gone from diplomatic to brutally honest over the last few months) and nothing changes. Thankfully the job market is starting to rebound after tanking during early Covid.

coderdd 6y ago

I highly recommend "Managing Yourself and Others" from Gerald Weinberg - https://leanpub.com/managingyourselfandothers https://leanpub.com/managingyourselfandothers Or anything from him, really.

lmilcin 6y ago

The single biggest mistake I see new managers make consistently is not training your self awareness and being retrospective. Everybody makes mistakes. The trouble is if you are not on the lookout to identify, correct and learn from them. In my opinion, every other advice is secondary as it can only work if you are honest with yourself and wanting to apply it to improve your work. No advice will help if you think you are better than everybody else and you attribute all your failures to other people letting you down or working against you.