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 <i>really</i> code) puts “Engineering” in the “Engineering Manager”.
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:<p>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.<p>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.<p>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.
Every software engineer needs to read this. Managing people is it’s own skill all its own. Programming skills don’t translate.<p>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.<p>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.<p>Underperforming manager -> underperforming devs<p>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.
Whenever this topic comes up, especially developers or engineers transitioning to management, I point to this Hacker News thread from years ago:<p><a href="https://news.ycombinator.com/item?id=3407643" rel="nofollow">https://news.ycombinator.com/item?id=3407643</a><p>There's a lot of overlap with this article but it covers a broader range of experience and also includes some good reading recommendations.<p>It's been invaluable to my own career.
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.
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.
> 1. Keep Coding<p>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.
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).<p>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).<p>Thank you for posting.
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.<p>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.
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.
<i>7) Avoiding hard conversations</i> 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:<p><i>I just couldn't give negative feedback during performance review</i>
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 <i>want</i> 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.<p>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).<p>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).<p>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?<p>EDIT: I'd also just appreciate being told if I'm thinking about everything entirely wrong or something here.<p>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.<p>-----<p>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?
When offered to 'move up' into a Manager's role - the first thing is to understand what has changed in the Team or Company.<p>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.<p>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.<p>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.<p>Politics does not begin at Manager's level, but failing to see how the politics works there is what effectively dooms a new Manager.<p>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.<p>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.
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.<p>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.<p>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.<p>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.
> Expecting without expressing.<p>Absolutely this. You have to let people know what you expect and where they stand, and with honesty and compassion.<p>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.
I think a lot of the time we should learn from good/successful OSS projects<p>- Have clear rules about code quality, how to get code in, enforce rigorously<p>- Have open, written discussions about what is going to happen next (Agile can do this, most of us take the lazy option)<p>- discuss ad nauseum<p>- try out new things - lots of spikes. The spike to new code ratio for a mature product should be large<p>- then and only then worry about the way you fit into politics and people
For more of this, I recommend this podcast:<p><a href="https://softskills.audio/" rel="nofollow">https://softskills.audio/</a><p>Called Soft Skills Engineering Podcast. It's hosted by two seasoned developers whom experience becoming managers. It's hilarious.<p>I listen to it when I commute with earpohones, then and suddenly laugh like a wirdo.
Find that much of my IC work as a Tech Lead is spent protecting my team from requests that distract from their goals.<p>That and keeping the build running smoothly.
Excellent summary with one caveat: balance (1) and (8):<p><pre><code> 1. (don't) Keep coding
8. (don't) Stop learning your craft</code></pre>