11 ms·

How to fail as a new engineering manager

425 points by andygcook 8y ago

kixpanganiban 8y ago
So much solid advice in here. As a new engineering manager myself, thank you for posting this.
- vvanders 8y ago
  If you're looking to expand on this I can highly recommend rands[1] as a great source of a wide range of engineering topics. Good stuff not just for managers but anyone involved in the well-running of a team(which is everyone!). [1] http://randsinrepose.com/ http://randsinrepose.com/
  - mdekkers 8y ago
    Rands is awesome
  - JimDabell 8y ago
    There's also the Rands Leadership Slack: http://randsinrepose.com/welcome-to-rands-leadership-slack/ http://randsinrepose.com/welcome-to-rands-leadership-slack/
Eduardo3rd 8y ago
I’m a big fan of “Mistaking directing for leading” here. So often I see new leaders mistake their new responsibility for results with a need to be in charge of every decision. There’s a big difference between leading and simply being in charge. Don’t base your own habits on the poor management styles you’ve seen in the past.
jetako 8y ago
> 1. Keep Coding Hardest pill to swallow, but it's mostly true. The old adage, "If you want something done right, do it yourself" is a subversive kind of fallacy, because it's half correct. Yes, you could probably get it done better and sooner, but every minute you spend doing it yourself could have been invested in empowering your team.
- rb808 8y ago
  Yes it is mostly true if you are going up the career ladder all the way to executive level. However I've seen a bunch of people hit middle-management then stop and its a really vulnerable place if you're looking for a new job. I think its really important to be able to keep some coding in new technologies as they become popular. Perhaps the best is to work with your developers code - write integration tests, evaluate checkins, research new tools.
  - klenwell 8y ago
    > Perhaps the best is to work with your developers code - write integration tests, evaluate checkins, research new tools. Without really planning it, that's where I ended up. Also: establishing best practices and ceaselessly promoting them.
  - bonniemuffin 8y ago
    +1, I think it's critical to stay technically sharp, but that doesn't have to mean pushing user-facing code to production. I can only recall one time I've actually checked in production code since I transitioned to manager (and I definitely felt like I was shirking my manager duties by sinking a day into it), but I stay close to the code in 2 ways: (1) I review the majority of the code that the team writes, and I also read other people's reviews to evaluate our code review practices. (2) I hack around with new tools & technologies to evaluate them. This has resulted in some code bits in wikis documenting "here's how to get started with this thing", but not touching any prod systems. I usually save this kind of thing for our "personal projects"/hackday days at work.
- Waterluvian 8y ago
  I knew a manager who committed personal hours to some really neat coding projects but always avoided coding in his job. I think it's valuable for managers to at least understand what the engineers are talking about, even if they couldn't do the work themselves. I also remember the headaches caused when the company went into a sort of panic mode and he ended up doing actual coding on critical path projects in some attempt to dig up out of the hole. I saw that sign as, "the General has his sidearm drawn" and promptly got out of there.
ilyanep 8y ago
I realize this isn't really the main point of the article, but it's something I've been thinking about a lot recently: Can someone explain to me why I should want to become good at management? I think most people on here (but sadly few company structures) would agree that engineering and engineering management are two nearly orthogonal skillsets, but for some reason we insist on "promoting" people who are good at the former into positions that require the latter. As someone with about five years of experience as a professional software engineer, I'm really still looking to level up my IC chops, along with a healthy dose of mentorship (mentoring interns or new hires on my team) and what I'd call "tech leadership" (advising on engineering reviews, making technical decisions about how to best build things). I would basically worry about stunting my development as an engineer if I switched to focusing on management, and I'm not even convinced my role models for career development are really in primarily "managerial" roles (I'm thinking of both famously very good backend devs both at my company and at the big SV companies). Separately, I have relatively little interest in being in a role where my output is judged as the output of a team of people who aren't me. I get that that's the best way to judge managers, and that managers do very valuable intangible things in unblocking their team, but I'm skeptical that I'd be able to feel satisfied by this. If anything, it kind of feels random: at an equivalent level of my unblocking the team and being a good manager, if I have an amazing 10x engineer on my team then the output is just going to be higher than if I have an average engineer. So in less clear-cut cases, how can I tell if I just did a good job at unblocking or if my engineers are really good? (This is not to say that I don't feel satisfied doing mentorship-style things or architectural advising-style things, but that feels separate to me. I think I prefer empowering other engineers by leveraging knowledge and writing good platforms/tools/APIs rather than doing the organizational empowering thing). I write all these things, because it really seems like a foregone conclusion of both this article and the industry as a whole that an engineer will eventually become a manager. Is that what I most likely have to look forward to in my career if I wind up working at the well-established/mature companies? EDIT: I'd also just appreciate being told if I'm thinking about everything entirely wrong or something here. EDIT2: This also isn't to knock people who _do_ enjoy doing these things, but it's not for me and I imagine it's not definitionally for every good engineer. ----- Unrelated to the above, point 8 feels a little bit in contradiction to point 1. How does one keep learning their craft without direct experience?
NPMaxwell 8y ago
One way to avoid 4. Expecting without expressing, is to make sure that you have confidence that anyone on your team can fill in for you in a meeting you can't make, and correctly report your objectives, plan, strategy, and reasoning. If they can, then they know your thinking, and you have expressed. A side benefit is that they may know a lot more about their areas than you do, and they can correct your mistaken ideas -- but only if they know what your ideas are.
klenwell 8y ago
Whenever this topic comes up, especially developers or engineers transitioning to management, I point to this Hacker News thread from years ago: https://news.ycombinator.com/item?id=3407643 https://news.ycombinator.com/item?id=3407643 There's a lot of overlap with this article but it covers a broader range of experience and also includes some good reading recommendations. It's been invaluable to my own career.
ggm 8y ago
7) Avoiding hard conversations This is the one I failed at hardest. Well.. my teams might say that accepting arbitrary deadlines was worse, but this is what I personally took as the signal I wasn't suited: I just couldn't give negative feedback during performance review
- rejschaap 8y ago
  You probably shouldn't give negative feedback during performance reviews anyway. Feedback should be given as soon as possible. Not giving feedback at all is a problem though, first get comfortable with giving positive feedback. Don't move to giving negative feedback too quickly as a new engineering manager.
  - jaegerpicker 8y ago
    I, excuse the language, called my technique "a shit sandwich" for getting comfortable giving negative feedback. I'd establish with both the employee and myself a pattern of giving both negative and positive feedback at the same time, instead of only negative. I'd give something good, something bad, and then something good hence the sandwich. I've found that if you are all negative it's too easy to lose an employee and there motivation. By using the sandwich you so that you notice the good and the bad and that you are pulling for them to fix the bad.
    - Joof 8y ago
      That's how you're supposed to do it. My manager had a nack for only giving the negative feedback 3 or 4 times.
      - saltyhiker 8y ago
        If you build a good rapport with everyone, this is unnecessary and you can simply provide constructive feedback without sugarcoating it. The best engineers will see right through this.
nxc18 8y ago
Every software engineer needs to read this. Managing people is it’s own skill all its own. Programming skills don’t translate. Business folks: please create parallel technical and managerial career paths. This can go all the way to the CEO (CTO) level - great devs can be great devs, great people/business folks can be great at managing. I see it daily:if your manager is programming, he’s not managing. Of course there are exceptions, but as a rule, if you’re a senior dev, you’ve probably been focusing your attention on tech and not people for a long time. There’s a crazy amount of nuance, self awareness, humility, patience (!!!), empathy, and conscientiousness needed to be great at managing. Underperforming manager -> underperforming devs HR management should be taken seriously as an engineering (as much as software is currently) discipline and not just an afterthought for devs to pick up.
- enraged_camel 8y ago
  >>I see it daily:if your manager is programming, he’s not managing. Management does not have to be an “active” job. Great managers find out what obstacles are standing in the way of their team members, then figure out how to remove those obstacles. How much time this takes greatly depends on the company. IMO a senior dev is different than a manager. Senior devs mentor junior devs; that is where their team productivity multiplier comes from.
  - watwut 8y ago
    > Management does not have to be an “active” job. > Great managers find out what obstacles are standing in the way of their team members, then figure out how to remove those obstacles. Finding out obstacles and removing them is an active job. But also, the saying about merely "removing obstacles" is not really correct. I am not even sure it is so in the happy flow where every employee is super great and full of initiative and is at exactly the right position. Managers are expected to coordinate, set priorities, negotiate about deadlines and scope of project, plan and re-plan, explain why we are going to be late, handle communication outside of team, clean up tracker, make sure testers are available, collect reports about who worked on what. If all manager is focusing on is "finding out obstacles and removing them", you all have high chance of ending up in long term crunch and chaos.
jamifsud 8y ago
I’m less than one year into my first management role. The job often feels like the early days of my software engineering career when I was pushing code as a junior dev with an extremely high internal bar and little experience (read: had no idea what I was doing). The experience has been fun and exciting but its a mental and emotional grind more often than not. Knew it would be difficult, but I've found the learning curve to be far steeper than I expected. Its really helpful to read some of the hard earned lessons I’ve been thinking about recently expressed so clearly (#3 and #4 especially). Thank you for posting.
- theshadowknows 8y ago
  I recently transitioned to architect from lead engineer and it’s been very jarring. My day to day went from leading a few meetings here and there and smashing hard bugs to near constant meetings with people higher and higher up the food chain (just yesterday I was presenting to the president of our parent company). Where as 3 months ago I would say “sure, I can do that” and then fire up vim and go to town. Now I’m fighting with sr. Directors and asking them “What is this in service of?” And I do very little coding outside of producing proof of concept work. I do like it but it’s just entirely different work from what I’ve been doing the past 8 or so years.
purplezooey 8y ago
Most of my engineering managers are usually just lieutenants for the next layer up. That person brought over his/her stooge collection from their previous company or collected over the course of their career. When you see a stooge collection forming, you know it's time to go. Not addressed in the article.
- marsrover 8y ago
  Could you talk a little more about this? I’ve never encountered a stooge collection but when I interviewed for a job right out of college the CTO of a company told me that “this lead dev had a few friends follow him here since he’s so good.” Is that likely a stooge collection?
  - mharroun 8y ago
    As someone who has seen others do this as well as being a manager who tends to rehire people, again and again, I would say "it depends". Leaders tend to build connections with people who have personalities, goals, and/or work ethics that are similar or compatible with that leader. So if you like that particular leader/manager it's more then likely those followers will be good. The opposite is also often true. As people move into more senior management roles there is an expectation that you have built some form of network.
- billysielu 8y ago
  What's the reason a stooge collection means it's time to go?
  - alistairSH 8y ago
    Two things could happen... You aren't part of that inner circle, so you're potential to advance is now limited (assuming you want to advance into the roles the "stooges" now hold). Or, the stooges are a group of self-serving near-sociopaths who jump company to company with the sole purpose of padding their wallets and padding their titles. But, this is certainly not a 100% true thing. As noted in a sibling response, it could just be the senior manager has a known "good" set of lieutenants and he's happy to bring them along.
allsunny 8y ago
I agree with the general idea that the most important skill is managing people, not technical, with engineering management. However, my advice is to never go full manager. If you can, jump in from time to time and help dig the ditches. I like the idea of playing a supporting role on the team. You're there to help the team get done what needs to get done. Most of the time that's going to broader organization meetings, planning, providing growth opportunities etc. However, when there is technical work that needs to be done, I'll gladly jump in and help out as much as my technical skills allow me to. By the same token, if I'm overbooked, out of the office, etc, I'll ask my team to help out with organization meetings, planning and similar activities. I want folks to know that we all play a role and have skills that allow us to participate in some activities more effectively than others, but at the end of the day our greater success comes with our ability to execute as a team, not as individuals.
sytelus 8y ago
I as a manager “kept coding” and it made me a better manager 100% of the time. It allowed me to understand low level issues team had been facing that I couldn’t have from 35,000ft. Team members didn’t felt need to dumb down complex concepts so I “get it”. People didn’t had to prep PowerPoints all the time because I could only grasp pretty pictures. I much better understood the complexity of workitems, costs, collaboration opportunities, scheduling and skills required which allowed me to do much better estimates and task assignments. I didn’t had to find “deputy” who I delegate everything while I am just busy in meetings and emails. Ancient Greeks like called this type of management as “leading from the front”. Chinese called it working shoulder to shoulder with your team mates instead of trying not to get your hands dirty because, you know, you are too “busy” and a level up high. Being able code (not in just imagination, but really code) puts “Engineering” in the “Engineering Manager”.
- jon-wood 8y ago
  My experience of moving into engineering management has very much been that I need to keep writing code to truly understand what people are facing, and ensure I'm not coming up with crazy ideas that will be a pain to implement. The only caveat I'd add to that is that I can't keep on working on things in the critical path, at least as the sole developer picking up those tasks, because I'm hugely more likely to have things come up that prevent me from doing those things in a timely manner. That then leads to other people being blocked on my work. The best balance I've found is for me to either pair with a developer who's able to remain focused on a task when I'm inevitably dragged away to do something else, or for me to pick up non-urgent tasks like refactoring, or developer tooling. The latter is probably my favourite as it means I'm applying my experience to tools and libraries that can then be used in widely applicable circumstances to make the rest of the team more productive.
  - kerng 8y ago
    Letting go is the most challenging part. If you build/hire the right team you trust them to tell you nifty technical things. Manager's job is to remove road blocks and protect the team from "outside interference" and distractions, like reorg discussions, new features/deadlines, scope creep and stuff... What you describe is more of a technical lead.
profalseidol 8y ago
For more of this, I recommend this podcast: https://softskills.audio/ https://softskills.audio/ Called Soft Skills Engineering Podcast. It's hosted by two seasoned developers whom experience becoming managers. It's hilarious. I listen to it when I commute with earpohones, then and suddenly laugh like a wirdo.
deleted 8y ago
[deleted]
lifeisstillgood 8y ago
I think a lot of the time we should learn from good/successful OSS projects - Have clear rules about code quality, how to get code in, enforce rigorously - Have open, written discussions about what is going to happen next (Agile can do this, most of us take the lazy option) - discuss ad nauseum - try out new things - lots of spikes. The spike to new code ratio for a mature product should be large - then and only then worry about the way you fit into politics and people
slivym 8y ago
One thing I think this misses that is REALLY worth knowing as a new engineering manager: you might not want to be an engineering manager. People often view it as a seniority step or a power step or a salary step, but there are three things that go on- especially at large organisations: 1. You have no power. You really don't have the freedom to change salaries, you don't have final say on promotions, you often don't have final say on work commitments, often a lot of work needs to be done that simply isn't exciting. It's a killer to have a development plan for someone that's totally un-acheivable because that's simply not what your team does. 2. You are the shit shield for your team. Especially working in a remote site decisions will be made that totally screw your team and you're responsible to deal with that. Whether it be other teams breaking fundamental dependencies, or senior management forgetting why your team exists and deciding it can be cut, re-assigned, re-prioritized. Often being the person who gets the brunt of that is incredibly difficult to deal with. 3. Your job is now 100% political. Whether it's the expectations your team puts on you to deliver them pay rises at the end of the year, or your product manager putting expectations on you to deliver releases at certain times a lot of what you're doing is politics. Especially in large organisations there'll be projects that are going to fail, and learning how to protect your team from the fallout is essential. It's a shit part of the job but in large organisations it's essential.
- mabbo 8y ago
  > You have no power > You are the shit shield > Your job is now 100% political By any chance do you work at Amazon? Or is that just common everywhere?
  - monocasa 8y ago
    It's everywhere
  - eikenberry 8y ago
    This is the standard at pretty much every large company. If you want to escape it you have to go to small/mid-sized companies. While they will still have politics but not near the soul crushing levels it is at large companies.
- 8y ago
karmakaze 8y ago
Excellent summary with one caveat: balance (1) and (8): 1. (don't) Keep coding 8. (don't) Stop learning your craft
patsplat 8y ago
Find that much of my IC work as a Tech Lead is spent protecting my team from requests that distract from their goals. That and keeping the build running smoothly.
breckenedge 8y ago
> Expecting without expressing. Absolutely this. You have to let people know what you expect and where they stand, and with honesty and compassion. I'm surprised this article doesn't mention setting boundaries. As a leader (and coder), the best thing I've learned to do is set aside regularly-scheduled time to meet with individual colleagues. People no longer walk into my office or ping me on Slack when they run into technical problems. They take the time to think through things before bugging me and often come up with solutions on their own. It works wonders. Don't be a jerk about it, but don't be as available. If someone interrupts you with a technical problem, tell them that both of you should set aside dedicated time to discuss and explore it.
Rowaway45 8y ago
I wonder where do you get those mentoring managers with one on ones. Coaching and all thut stuff. No one has time to do it. It is always: here is your job that are requirements. No meaningful one on ones. It is not only in work, I just all life have to figure out taxes, relationships, learning, work. What is even better when I was trying to pay for advice of accountant they did not take my money and no advice. I got advice from attorney but it was useless, I figured out later on my own. Oh I got some advice from relatives like uncle or grandma but that was like outdated and totally not true anymore. Almost got fined for trying to apply that. So my point is no one cares about one on ones and mentoring, and someones advice on life or carreer because probably they still have to figure all on their own, and they think they are smarter. so better keep track of tickets and that stuff is rolling, keep obstackles away from team and don't say yes to everything.
zoomablemind 8y ago
When offered to 'move up' into a Manager's role - the first thing is to understand what has changed in the Team or Company. If the position has been vacated by someone who just left, you may see what expectations on the role have stayed in the Company. These may be 'projected' on the new Manager (no matter what the job description says). This would impact the ability to meet your own vision of success in that role. If this is a new position, created just for you - again, there might be some unexpressed reasons based on what has led to that decision. If one knows the history and the decision makers, one could measure degree of freedom to have any impact in that role. As others here pointed out, it's a move from a Senior Dev to a Junior Mgr. As such you are Junior on someone's Team, with all the baggage that comes with this. Politics does not begin at Manager's level, but failing to see how the politics works there is what effectively dooms a new Manager. Article lists many practical points that are team-facing. My personal favortite is #4 (express your expectations). Equally crucial should be the management-facing points. I find that for someone with a strong technical background one of the hardest management side to adopt may be a _negotiation ability_ and a capacity for compromise, especially with the very little leverage as a Junior Mgr usually has at her disposal.

425 points by andygcook 8y ago

kixpanganiban 8y ago

So much solid advice in here. As a new engineering manager myself, thank you for posting this.

vvanders 8y ago
If you're looking to expand on this I can highly recommend rands[1] as a great source of a wide range of engineering topics. Good stuff not just for managers but anyone involved in the well-running of a team(which is everyone!). [1] http://randsinrepose.com/ http://randsinrepose.com/
- mdekkers 8y ago
  Rands is awesome
- JimDabell 8y ago
  There's also the Rands Leadership Slack: http://randsinrepose.com/welcome-to-rands-leadership-slack/ http://randsinrepose.com/welcome-to-rands-leadership-slack/

Eduardo3rd 8y ago

I’m a big fan of “Mistaking directing for leading” here. So often I see new leaders mistake their new responsibility for results with a need to be in charge of every decision. There’s a big difference between leading and simply being in charge. Don’t base your own habits on the poor management styles you’ve seen in the past.

jetako 8y ago

> 1. Keep Coding Hardest pill to swallow, but it's mostly true. The old adage, "If you want something done right, do it yourself" is a subversive kind of fallacy, because it's half correct. Yes, you could probably get it done better and sooner, but every minute you spend doing it yourself could have been invested in empowering your team.

rb808 8y ago
Yes it is mostly true if you are going up the career ladder all the way to executive level. However I've seen a bunch of people hit middle-management then stop and its a really vulnerable place if you're looking for a new job. I think its really important to be able to keep some coding in new technologies as they become popular. Perhaps the best is to work with your developers code - write integration tests, evaluate checkins, research new tools.
- klenwell 8y ago
  > Perhaps the best is to work with your developers code - write integration tests, evaluate checkins, research new tools. Without really planning it, that's where I ended up. Also: establishing best practices and ceaselessly promoting them.
- bonniemuffin 8y ago
  +1, I think it's critical to stay technically sharp, but that doesn't have to mean pushing user-facing code to production. I can only recall one time I've actually checked in production code since I transitioned to manager (and I definitely felt like I was shirking my manager duties by sinking a day into it), but I stay close to the code in 2 ways: (1) I review the majority of the code that the team writes, and I also read other people's reviews to evaluate our code review practices. (2) I hack around with new tools & technologies to evaluate them. This has resulted in some code bits in wikis documenting "here's how to get started with this thing", but not touching any prod systems. I usually save this kind of thing for our "personal projects"/hackday days at work.
Waterluvian 8y ago
I knew a manager who committed personal hours to some really neat coding projects but always avoided coding in his job. I think it's valuable for managers to at least understand what the engineers are talking about, even if they couldn't do the work themselves. I also remember the headaches caused when the company went into a sort of panic mode and he ended up doing actual coding on critical path projects in some attempt to dig up out of the hole. I saw that sign as, "the General has his sidearm drawn" and promptly got out of there.

ilyanep 8y ago

I realize this isn't really the main point of the article, but it's something I've been thinking about a lot recently: Can someone explain to me why I should want to become good at management? I think most people on here (but sadly few company structures) would agree that engineering and engineering management are two nearly orthogonal skillsets, but for some reason we insist on "promoting" people who are good at the former into positions that require the latter. As someone with about five years of experience as a professional software engineer, I'm really still looking to level up my IC chops, along with a healthy dose of mentorship (mentoring interns or new hires on my team) and what I'd call "tech leadership" (advising on engineering reviews, making technical decisions about how to best build things). I would basically worry about stunting my development as an engineer if I switched to focusing on management, and I'm not even convinced my role models for career development are really in primarily "managerial" roles (I'm thinking of both famously very good backend devs both at my company and at the big SV companies). Separately, I have relatively little interest in being in a role where my output is judged as the output of a team of people who aren't me. I get that that's the best way to judge managers, and that managers do very valuable intangible things in unblocking their team, but I'm skeptical that I'd be able to feel satisfied by this. If anything, it kind of feels random: at an equivalent level of my unblocking the team and being a good manager, if I have an amazing 10x engineer on my team then the output is just going to be higher than if I have an average engineer. So in less clear-cut cases, how can I tell if I just did a good job at unblocking or if my engineers are really good? (This is not to say that I don't feel satisfied doing mentorship-style things or architectural advising-style things, but that feels separate to me. I think I prefer empowering other engineers by leveraging knowledge and writing good platforms/tools/APIs rather than doing the organizational empowering thing). I write all these things, because it really seems like a foregone conclusion of both this article and the industry as a whole that an engineer will eventually become a manager. Is that what I most likely have to look forward to in my career if I wind up working at the well-established/mature companies? EDIT: I'd also just appreciate being told if I'm thinking about everything entirely wrong or something here. EDIT2: This also isn't to knock people who _do_ enjoy doing these things, but it's not for me and I imagine it's not definitionally for every good engineer. ----- Unrelated to the above, point 8 feels a little bit in contradiction to point 1. How does one keep learning their craft without direct experience?

NPMaxwell 8y ago

One way to avoid 4. Expecting without expressing, is to make sure that you have confidence that anyone on your team can fill in for you in a meeting you can't make, and correctly report your objectives, plan, strategy, and reasoning. If they can, then they know your thinking, and you have expressed. A side benefit is that they may know a lot more about their areas than you do, and they can correct your mistaken ideas -- but only if they know what your ideas are.

klenwell 8y ago

Whenever this topic comes up, especially developers or engineers transitioning to management, I point to this Hacker News thread from years ago: https://news.ycombinator.com/item?id=3407643 https://news.ycombinator.com/item?id=3407643 There's a lot of overlap with this article but it covers a broader range of experience and also includes some good reading recommendations. It's been invaluable to my own career.

ggm 8y ago

7) Avoiding hard conversations This is the one I failed at hardest. Well.. my teams might say that accepting arbitrary deadlines was worse, but this is what I personally took as the signal I wasn't suited: I just couldn't give negative feedback during performance review

rejschaap 8y ago
You probably shouldn't give negative feedback during performance reviews anyway. Feedback should be given as soon as possible. Not giving feedback at all is a problem though, first get comfortable with giving positive feedback. Don't move to giving negative feedback too quickly as a new engineering manager.
- jaegerpicker 8y ago
  I, excuse the language, called my technique "a shit sandwich" for getting comfortable giving negative feedback. I'd establish with both the employee and myself a pattern of giving both negative and positive feedback at the same time, instead of only negative. I'd give something good, something bad, and then something good hence the sandwich. I've found that if you are all negative it's too easy to lose an employee and there motivation. By using the sandwich you so that you notice the good and the bad and that you are pulling for them to fix the bad.
  - Joof 8y ago
    That's how you're supposed to do it. My manager had a nack for only giving the negative feedback 3 or 4 times.
    - saltyhiker 8y ago
      If you build a good rapport with everyone, this is unnecessary and you can simply provide constructive feedback without sugarcoating it. The best engineers will see right through this.

nxc18 8y ago

Every software engineer needs to read this. Managing people is it’s own skill all its own. Programming skills don’t translate. Business folks: please create parallel technical and managerial career paths. This can go all the way to the CEO (CTO) level - great devs can be great devs, great people/business folks can be great at managing. I see it daily:if your manager is programming, he’s not managing. Of course there are exceptions, but as a rule, if you’re a senior dev, you’ve probably been focusing your attention on tech and not people for a long time. There’s a crazy amount of nuance, self awareness, humility, patience (!!!), empathy, and conscientiousness needed to be great at managing. Underperforming manager -> underperforming devs HR management should be taken seriously as an engineering (as much as software is currently) discipline and not just an afterthought for devs to pick up.

enraged_camel 8y ago
>>I see it daily:if your manager is programming, he’s not managing. Management does not have to be an “active” job. Great managers find out what obstacles are standing in the way of their team members, then figure out how to remove those obstacles. How much time this takes greatly depends on the company. IMO a senior dev is different than a manager. Senior devs mentor junior devs; that is where their team productivity multiplier comes from.
- watwut 8y ago
  > Management does not have to be an “active” job. > Great managers find out what obstacles are standing in the way of their team members, then figure out how to remove those obstacles. Finding out obstacles and removing them is an active job. But also, the saying about merely "removing obstacles" is not really correct. I am not even sure it is so in the happy flow where every employee is super great and full of initiative and is at exactly the right position. Managers are expected to coordinate, set priorities, negotiate about deadlines and scope of project, plan and re-plan, explain why we are going to be late, handle communication outside of team, clean up tracker, make sure testers are available, collect reports about who worked on what. If all manager is focusing on is "finding out obstacles and removing them", you all have high chance of ending up in long term crunch and chaos.

jamifsud 8y ago

I’m less than one year into my first management role. The job often feels like the early days of my software engineering career when I was pushing code as a junior dev with an extremely high internal bar and little experience (read: had no idea what I was doing). The experience has been fun and exciting but its a mental and emotional grind more often than not. Knew it would be difficult, but I've found the learning curve to be far steeper than I expected. Its really helpful to read some of the hard earned lessons I’ve been thinking about recently expressed so clearly (#3 and #4 especially). Thank you for posting.

theshadowknows 8y ago
I recently transitioned to architect from lead engineer and it’s been very jarring. My day to day went from leading a few meetings here and there and smashing hard bugs to near constant meetings with people higher and higher up the food chain (just yesterday I was presenting to the president of our parent company). Where as 3 months ago I would say “sure, I can do that” and then fire up vim and go to town. Now I’m fighting with sr. Directors and asking them “What is this in service of?” And I do very little coding outside of producing proof of concept work. I do like it but it’s just entirely different work from what I’ve been doing the past 8 or so years.

purplezooey 8y ago

Most of my engineering managers are usually just lieutenants for the next layer up. That person brought over his/her stooge collection from their previous company or collected over the course of their career. When you see a stooge collection forming, you know it's time to go. Not addressed in the article.

marsrover 8y ago
Could you talk a little more about this? I’ve never encountered a stooge collection but when I interviewed for a job right out of college the CTO of a company told me that “this lead dev had a few friends follow him here since he’s so good.” Is that likely a stooge collection?
- mharroun 8y ago
  As someone who has seen others do this as well as being a manager who tends to rehire people, again and again, I would say "it depends". Leaders tend to build connections with people who have personalities, goals, and/or work ethics that are similar or compatible with that leader. So if you like that particular leader/manager it's more then likely those followers will be good. The opposite is also often true. As people move into more senior management roles there is an expectation that you have built some form of network.
billysielu 8y ago
What's the reason a stooge collection means it's time to go?
- alistairSH 8y ago
  Two things could happen... You aren't part of that inner circle, so you're potential to advance is now limited (assuming you want to advance into the roles the "stooges" now hold). Or, the stooges are a group of self-serving near-sociopaths who jump company to company with the sole purpose of padding their wallets and padding their titles. But, this is certainly not a 100% true thing. As noted in a sibling response, it could just be the senior manager has a known "good" set of lieutenants and he's happy to bring them along.

allsunny 8y ago

I agree with the general idea that the most important skill is managing people, not technical, with engineering management. However, my advice is to never go full manager. If you can, jump in from time to time and help dig the ditches. I like the idea of playing a supporting role on the team. You're there to help the team get done what needs to get done. Most of the time that's going to broader organization meetings, planning, providing growth opportunities etc. However, when there is technical work that needs to be done, I'll gladly jump in and help out as much as my technical skills allow me to. By the same token, if I'm overbooked, out of the office, etc, I'll ask my team to help out with organization meetings, planning and similar activities. I want folks to know that we all play a role and have skills that allow us to participate in some activities more effectively than others, but at the end of the day our greater success comes with our ability to execute as a team, not as individuals.

sytelus 8y ago

I as a manager “kept coding” and it made me a better manager 100% of the time. It allowed me to understand low level issues team had been facing that I couldn’t have from 35,000ft. Team members didn’t felt need to dumb down complex concepts so I “get it”. People didn’t had to prep PowerPoints all the time because I could only grasp pretty pictures. I much better understood the complexity of workitems, costs, collaboration opportunities, scheduling and skills required which allowed me to do much better estimates and task assignments. I didn’t had to find “deputy” who I delegate everything while I am just busy in meetings and emails. Ancient Greeks like called this type of management as “leading from the front”. Chinese called it working shoulder to shoulder with your team mates instead of trying not to get your hands dirty because, you know, you are too “busy” and a level up high. Being able code (not in just imagination, but really code) puts “Engineering” in the “Engineering Manager”.

jon-wood 8y ago
My experience of moving into engineering management has very much been that I need to keep writing code to truly understand what people are facing, and ensure I'm not coming up with crazy ideas that will be a pain to implement. The only caveat I'd add to that is that I can't keep on working on things in the critical path, at least as the sole developer picking up those tasks, because I'm hugely more likely to have things come up that prevent me from doing those things in a timely manner. That then leads to other people being blocked on my work. The best balance I've found is for me to either pair with a developer who's able to remain focused on a task when I'm inevitably dragged away to do something else, or for me to pick up non-urgent tasks like refactoring, or developer tooling. The latter is probably my favourite as it means I'm applying my experience to tools and libraries that can then be used in widely applicable circumstances to make the rest of the team more productive.
- kerng 8y ago
  Letting go is the most challenging part. If you build/hire the right team you trust them to tell you nifty technical things. Manager's job is to remove road blocks and protect the team from "outside interference" and distractions, like reorg discussions, new features/deadlines, scope creep and stuff... What you describe is more of a technical lead.

profalseidol 8y ago

For more of this, I recommend this podcast: https://softskills.audio/ https://softskills.audio/ Called Soft Skills Engineering Podcast. It's hosted by two seasoned developers whom experience becoming managers. It's hilarious. I listen to it when I commute with earpohones, then and suddenly laugh like a wirdo.

deleted 8y ago

[deleted]

lifeisstillgood 8y ago

I think a lot of the time we should learn from good/successful OSS projects - Have clear rules about code quality, how to get code in, enforce rigorously - Have open, written discussions about what is going to happen next (Agile can do this, most of us take the lazy option) - discuss ad nauseum - try out new things - lots of spikes. The spike to new code ratio for a mature product should be large - then and only then worry about the way you fit into politics and people

slivym 8y ago

One thing I think this misses that is REALLY worth knowing as a new engineering manager: you might not want to be an engineering manager. People often view it as a seniority step or a power step or a salary step, but there are three things that go on- especially at large organisations: 1. You have no power. You really don't have the freedom to change salaries, you don't have final say on promotions, you often don't have final say on work commitments, often a lot of work needs to be done that simply isn't exciting. It's a killer to have a development plan for someone that's totally un-acheivable because that's simply not what your team does. 2. You are the shit shield for your team. Especially working in a remote site decisions will be made that totally screw your team and you're responsible to deal with that. Whether it be other teams breaking fundamental dependencies, or senior management forgetting why your team exists and deciding it can be cut, re-assigned, re-prioritized. Often being the person who gets the brunt of that is incredibly difficult to deal with. 3. Your job is now 100% political. Whether it's the expectations your team puts on you to deliver them pay rises at the end of the year, or your product manager putting expectations on you to deliver releases at certain times a lot of what you're doing is politics. Especially in large organisations there'll be projects that are going to fail, and learning how to protect your team from the fallout is essential. It's a shit part of the job but in large organisations it's essential.

mabbo 8y ago
> You have no power > You are the shit shield > Your job is now 100% political By any chance do you work at Amazon? Or is that just common everywhere?
- monocasa 8y ago
  It's everywhere
- eikenberry 8y ago
  This is the standard at pretty much every large company. If you want to escape it you have to go to small/mid-sized companies. While they will still have politics but not near the soul crushing levels it is at large companies.
8y ago

karmakaze 8y ago

Excellent summary with one caveat: balance (1) and (8): 1. (don't) Keep coding 8. (don't) Stop learning your craft

patsplat 8y ago

Find that much of my IC work as a Tech Lead is spent protecting my team from requests that distract from their goals. That and keeping the build running smoothly.

breckenedge 8y ago

> Expecting without expressing. Absolutely this. You have to let people know what you expect and where they stand, and with honesty and compassion. I'm surprised this article doesn't mention setting boundaries. As a leader (and coder), the best thing I've learned to do is set aside regularly-scheduled time to meet with individual colleagues. People no longer walk into my office or ping me on Slack when they run into technical problems. They take the time to think through things before bugging me and often come up with solutions on their own. It works wonders. Don't be a jerk about it, but don't be as available. If someone interrupts you with a technical problem, tell them that both of you should set aside dedicated time to discuss and explore it.

Rowaway45 8y ago

I wonder where do you get those mentoring managers with one on ones. Coaching and all thut stuff. No one has time to do it. It is always: here is your job that are requirements. No meaningful one on ones. It is not only in work, I just all life have to figure out taxes, relationships, learning, work. What is even better when I was trying to pay for advice of accountant they did not take my money and no advice. I got advice from attorney but it was useless, I figured out later on my own. Oh I got some advice from relatives like uncle or grandma but that was like outdated and totally not true anymore. Almost got fined for trying to apply that. So my point is no one cares about one on ones and mentoring, and someones advice on life or carreer because probably they still have to figure all on their own, and they think they are smarter. so better keep track of tickets and that stuff is rolling, keep obstackles away from team and don't say yes to everything.

zoomablemind 8y ago

When offered to 'move up' into a Manager's role - the first thing is to understand what has changed in the Team or Company. If the position has been vacated by someone who just left, you may see what expectations on the role have stayed in the Company. These may be 'projected' on the new Manager (no matter what the job description says). This would impact the ability to meet your own vision of success in that role. If this is a new position, created just for you - again, there might be some unexpressed reasons based on what has led to that decision. If one knows the history and the decision makers, one could measure degree of freedom to have any impact in that role. As others here pointed out, it's a move from a Senior Dev to a Junior Mgr. As such you are Junior on someone's Team, with all the baggage that comes with this. Politics does not begin at Manager's level, but failing to see how the politics works there is what effectively dooms a new Manager. Article lists many practical points that are team-facing. My personal favortite is #4 (express your expectations). Equally crucial should be the management-facing points. I find that for someone with a strong technical background one of the hardest management side to adopt may be a _negotiation ability_ and a capacity for compromise, especially with the very little leverage as a Junior Mgr usually has at her disposal.