Hacker News new | past | comments | ask | show | jobs | submit login
How to fail as a new engineering manager (usejournal.com)
425 points by andygcook 10 months ago | hide | past | web | favorite | 106 comments



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”.


I'd be interested to see whether your subordinates agree with that assessment. One of the better programmers I've worked with was promoted to our manager and tried to "keep coding" and it made her one of the worse managers I've had: the team was constantly blocked because her tasks got delayed when she (as is the nature of management) was pulled away for meetings with higher-ups or other unexpected work. In turn that meant there was pressure not to interrupt her when she was at her desk so it was hard to bring problems to her, even though that's a manager's primary responsibility.


I realized early in my management career that I should keep coding, but I should a) never let it interfere with my management duties and b) should only be for non-critical path stuff. I focused on quality of life type improvements such as sprucing up a dashboard used by ops personal, refining the CI/CD process, simple utilities to extract/transform data, etc. Another key requirement and benefit is that by letting your team do the "real" work, you're showing your trust and letting them grow.

The place where I continued to actively participate was in architectural and system level planning discussions. In that capacity, it was to mostly ask questions, ensure focus on objectives, and very occasionally offer advice. It's mostly facilitation and mentorship.


When I managed developers, I didn't have a list of programming cases that had my name on it. It's more that I would pitch in on complicated or challenging pieces of the code, typically with pair programming. I found this develops a different kind of relationship with developers (I'm a valuable resource, not a micro manager) and allows you to establish your technical skills without becoming a blocker for deliverables when you have to spend your time managing up. It allowed me to stay involved and very familiar with what was happening "in the trenches" without taking on a bunch of programming tasks which are better handled by dedicated developers.


The solution to that is simple: the manager should act like they're assigning tasks to a junior developer or intern: optimizing for "learning about the environment" (which is a goal shared by new team members and managers) and "keeping out of the way" (which is good if you are unsteady due to being new or if you are unsteady due to unpredictable external tasks.)


What if the manager only takes care of minor things that are not on the critical path? That being said, given how busy managers can get (it's a totally different world that many subordinates would not appreciate, don't blame them), I can see how difficult it can be for even non-critical stuff. And besides that, I suppose that if not involved in critical things, the alleged benefit of "being on the ground" is mostly lost. Curious to hear people's opinions on this question.


There are folks who would get in to competing with their own direct reports or would be very harsh for what the conceive as mistakes leaving little room for alternative thinking and options. I think these type of folks are not the best cut out for management without further coaching and reflection. However solution is never shutdown the coding for managers or make them as technically as dumb as possible.


A "engineering manager" should have at least one task, it shouldn't be blocking or critical. The manager should at least build the code, push it, and see the unit tests actually run. With enough experience you should be able to spot things, eg, "HEY! There are no unit tests for this part!".

Not doing this makes you the restaurant owner on Gordan Ramsey's Kitchen nightmares. These restaurant owners are always confused whey their food sucks, why food is rotten in the fridge and why everything is failing. If you want to know why you shouldn't leave the 'process of developing software' -- just watch one show of Kitchen nightmares. Also, if you 'are too high up to code' -- change your title to: "project manager".


As a point of fact, there are plenty of episodes of Kitchen Nightmares where the main reason for failure seems to be the owner meddling too much with the people who are actually doing the work.


> A "engineering manager" should have at least one task, it shouldn't be blocking or critical. The manager should at least build the code, push it, and see the unit tests actually run. With enough experience you should be able to spot things, eg, "HEY! There are no unit tests for this part!".

If you're saying we don't need managers anymore because that's what our CI/CD pipeline does, I agree!

I think a good manager has other responsibilities such as negotiating with other teams to enable their team's success. They don't need to understand the low-level details, but they should be able to comprehend complexity when explained, so even if I only produce '1' feature, they can be certain that my good job didn't produce '10' additional bugs to be discovered by the customers.


Did you even watch the show? In about half of the episodes Ramsay kicks the owner who can’t cook but thinks he can out of the kitchen and lets staff handle it


That's the difference between a manager and a lead in my org. A manager shouldn't be hands on (besides private or on the side research).


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.


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.


I agree, I'm troubled by the notion of not coding at all. However I think you need to separate "coding as part of the work effort to achieve tasks of the team" and "coding to keep you on top of the technical aspects of leadership". I actually think the latter is pretty essential, while it's a mistake if you are doing coding that is irreplaceable within the team. (I'm currently making that mistake, but that's another story).


...you need to separate "coding as part of the work effort to achieve tasks of the team" and "coding to keep you on top of the technical aspects of leadership"...

This. I've been in a management position for a few years now and was scrum master for a few before that. I try to grab a programming task every sprint, but I absolutely don't have the time to commit to large programming tasks that are critical to team goals.

I'll grab some easy tasks (stuff that takes <2 hours or so). Or, I'll pick up some analysis/prototyping work that isn't time sensitive. Or, I'll just help team members when they struggle with complex problems.

These days, I actually prefer mentoring or pair-programming with the junior developers. I have 4 of them on the team and making them more productive and independent is going to pay much larger dividends than trying to complete a complex task between meetings.


I think it's helpful if EMs to continue coding, even if it isn't at work. I've been an EM for 4 years now and keep working on side projects every now and then.

1. As an EM you do sometimes have to resolve conflicts about code between senior members of the team(if it involves the team's tech lead) and it helps to not to have strayed too far.

2. It's much easier to drive new engineering initiatives if you are fluent at code and can quickly read and understand code documentation about a new library/way of doing things.

3. Sometimes while chasing deadlines, it helps if an EM can just sit with an individual contributor and do pair programming. Reminding developers about deadline won't motivate them as much as an EM sitting beside them and helping them out with coding.

4. EM jobs can be a bit hard to find, so being fluent at coding helps you to secure a job much easily since individual contributor jobs are far more prevalent than EM jobs.

I usually try to pick up a side learning project every couple of months to just have some fun and learn something new. After moving to an EM role, I missed coding a lot and had thoughts about moving back to being an IC since EM at my company was a lateral move. Though I chose to stick on since the amount of stuff that I could pick up at a given point of time was no longer limited by my own personal bandwidth.

I completely agree with your point about team members not having to dumb down complex concepts. Sometimes team members can come up with really novel solutions to problems which cost more time to implement on the short term but pays off in the longer term. Unless one is comfortable with the technical chops of a project, it's easy to dismiss ideas which aren't conventional.


> 3. Sometimes while chasing deadlines, it helps if an EM can just sit with an individual contributor and do pair programming. Reminding developers about deadline won't motivate them as much as an EM sitting beside them and helping them out with coding.

I'm in a somewhat different field, but I had this experience a couple of times when I was younger-ish and didn't feel good about it. I don't think it raised my productivity

It may have been a good management move -- mitigating a high-stakes delivery risk by literally keeping an eye close, i.e. sitting next to me at my desk, but it felt more like panicky micromanagement (lasting for two or three days only, thankfully) than sharing the burden of an unplanned delivery.

(Unplanned delivery requests sometimes happen in my field. But what we do isn't as bottom-up as programming; it's more like a progressive GIF, iterative refinement from high level concept down to action plan, so unexpected intermediate deliveries can be good for the client.)


That's a nice insight, I'll be sure to check with the dev next time it happens to see if it's actually helping or not.

I personally do it in crunch situations for the following reasons: 1. Since there are more eyes on the code being written, mistakes made are an intersection of what either the driver or navigator would make. 2. It makes the developer less likely to procrastinate. I only use this as a last resort though and timebox it to an hour.


This works if there are small tasks that you can take care of pretty easy to stay reasonably current.

There’s a line where as a manager you’ll either do your engineering or management roles a disservice or not. Think of a napoleonic era army — You need to understand whether you are the sergeant who keeps the troops marching and fighting, the junior officer who passes orders on and keeps bullshit away from the sergeant, or the staff officer who makes sure the food and bullets show up, etc.


I completely agree (assuming not blocking task). No one is in a better position to represent, empathize, direct, and assist in employees' careers than a manager that "gets it". Additionally, studies show that employee satisfaction, trust, and respect for their manager is higher when they feel their boss is capable and can do their job.

Steve Jobs said it well: "The best managers, he says, are 'the great individual contributors' who don’t actually want to be managers but step up because they don’t see anyone else who can do the job better."

https://qz.com/work/1152331/watch-a-young-steve-jobs-give-ad...


>Steve Jobs said it well

Steve Jobs was a class-A asshole who people who are trained in leadership agree was a poor leader of humans, even if he had great success in business. I'm not sure I'd take his leadership musings without a few grains of salt.

edit: everyone -> people who are trained in leadership


>who everyone agrees was a poor leader of human

Everyone agrees?

Because I'm not sure I do. Jobs was probably an "asshole" for whatever your definition of that is. To suggest that he wasn't a capable leader of people is a rather different thing.

His leadership style was authoritative, petty, and probably even mean. It was also extremely effective. It's a style that was hardly unique to Jobs, and I can point to many other effective leaders (especially in the military) who used a similar style to achieve fantastic results. From Patton to Vince Lombardi the evidence is everywhere. Hell today we see much of the same behavior at SpaceX!

I would argue that an authoritative style of leadership, with small doses of intentional praise, can be really effective under certain circumstances. Particularly when the goal is very big, very audacious, and very hard.

There are lots of ways to lead people. Which one is most effective depends on many factors.


Effectiveness is not "good leadership". He may have been very effective, but he fucked people over, probably gave people PTSD, treated others with disdain, etc. I know some people see the Elon Musks and Steve Jobs' of the world and think they're awesome and effective, but it's a net negative for the organizations they are a part of due to the human cost.


Exactly! People repeat what he said like they are "words of wisdom", people committed suicide under his watch. Guy did not pay child-support for his daughter.


I never said Steve was a good leader or manager. What I agree with is that the best managers of engineers are DOERS/ENGINEERS themselves. Steve was not an engineer.


I don't like mixing the 2 but maybe because I don't do it often (I'm more on the technical side). When I do, I feel I am half-assing the technical part and short-changing the people expecting better management. A no-longer-codes, ex-coding manager has some of the advantages, in that they should still not need things dumbing down, but do need to delegate everything technical to the team because their hands are tied. If things are not dumbed down too much, and they are involved in technical discussions even if not the actual implementation, then they can stay on top of the technical side.

Not saying your way is bad, just difficult! Some mistakes I have been guilty of with your approach are:

If you do not delegate work well then you as a coding-manager can become a bottle neck. Sometimes work as a manager is unpredictable and breaks the flow of the coding part. Your coding work has to be passed to someone else (wasteful, as they need to get up to speed on it, context switch, etc) or others have to wait for you to finish the interruption manager-stuff and carry on with your technical work.

A manager like that can be tempted to make snap decisions (which may later turn out to be wrong or costly). Whereas a "dumb" manager can genuinely use the excuse that they have to consult with the team before making a technical decision. Of course you can always say you need to consult with the team, but it is really tempting to speed things up by short-circuiting the process and making decisions right away.


Ha! And oh, how I did try to be like you.

And oh, how I did get railroaded into endless eons of meetings, where no coding shall occur.

And oh, how I did get overruled by the scrum master, the moment I tried to deviate from the script of this iteration's sprint. Engineering manager, though I was.

And oh, how planning and retros taught us no lessons at all. How they were just working lunches at a hoteled desk via Skype. No desk. No one to look in the eye. No credible threat in hand.

No large, faceless corporation will ever get another hour of my time. Not even the time it would take to destroy them. For they do it to themselves by driving people like me away.


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.


> 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?


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.


It's everywhere


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.

I am honestly not sure why team members don't understand this. Of course, now and then you hear about that heavenly happy place where this is not true. But true more often than not.

I think this point needs to be expanded a bit as to why. Salaries are determined mostly by budget, history, market, and skill fit.

1. If the budget isn't there, nothing a manager can do. The manager is not in charge of raising financing for the company, and budgets are hard-fought things where managers often can't get everything they want. A manager can't wave a magic wand and make money appear out of thin air. If someone is leaving for a better offer, the manager gets more ammunition to ask for a better salary for that person or for the team, but that's it. They have very little ammunition of their own.

2. A manager has to consider the historical wages of what current team members make. If everyone is underpaid, well, SOL. There are reasons for that, whether budget (see above), culture, whatever. If you need to suddenly overpay one person, you need to figure out how to make everyone else happy. It may not be possible, and it may unfortunately just be easier to let the superstar go. Unfortunately, not everyone is Netflix.

edit 2.b. OK, we talked about this during your annual review last year. I'd love to give you a raise. We need more people who are at the skill level where the company is paying that money. Remember what we discussed? How are those personal growth goals going? Remember Fred who got his raise last year? Remember how we talked about his code quality, his people skills during meetings, his efficiency, his list of cool accomplishments? Remember how I want you to do those things? Talk with me when you've achieved the personal growth goals we discussed. I'd love to give you that raise. I need people at that level, and I'm authorized to give it to you if you are right there at Fred's level. But I can't give it to you if you haven't grown to that level yet. Help me help you.

3. The market may actually not agree with you regarding your market worth. Just because Netflix pays their 10x guys so much money, it doesn't mean you're worth a 10x guy. This one is just certain people being delusional. What is a manager supposed to do? He wants you because you're a great 1x guy, maybe even a 2x guy. But there's no way he's going to pay you the 10x rate, because he knows the market can give him another good 1x or 2x guy at a 1x or 2x price.

4. Your in-demand skills may just unfortunately not match what the company needs. You're overqualified. Go work for Netflix, why are you staying at this crap place where you will never get what you're worth? Go get paid, just not here. We can't afford you. Or stay here, but then please don't complain about the money. I'll try to do what I can to make it worth it for you, got any ideas for me?


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.


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


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


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

Much of that can and maybe should be done reactively. Set priorities when your employees need them. Negotiate deadlines and scope when they're needed for a decision. Communicate when it's needed. Etc.

You may not be literally twiddling your thumbs - I'm sure there's always something to be improved even in the quietest periods - but IMO the most important part of the manager role is to be available to resolve issues that do come up, and I'd take a manager who can do that well over one who's great at planning but can't react. As a technical analogy it's more like sysadmin/ops than development.


Ideally, deadlines and scope are negotiated continuously as the pressure on typical team is constant and as there is constant flow of incoming requirements. Being unprepared means higher chance of crunch or buggy releases (as team cant cope with what becomes expectation).

Same with priorities. Those are not just for employees, but also for people outside the team. When you are asked about priorities and future, it is best to have reasonable answer at that time - not two weeks later when you finally reactively done reading and thinking.

Employees often dont really ask about priorities. They assume priorities based on their previous experience/opinions, everyone different which leads to misunderstandings and waste of time. You have to sync them before they ask.

If the primary role of manager is to constantly react at suddenly appearing problems, then the company needs more planning and more organization. Those suddenly appearing problems are consequence of chaotic environment. Good manager reorganize so that they don't appear anymore or looks for them before they grow big and sudden.


> deadlines and scope are negotiated continuously as the pressure on typical team is constant and as there is constant flow of incoming requirements.

Incoming requirements aren't actually continuous; indeed in practice they tend to be quite bursty. When you get a new batch of requirements is the best time to evaluate their priorities and schedules.

> When you are asked about priorities and future, it is best to have reasonable answer at that time - not two weeks later when you finally reactively done reading and thinking.

Two weeks later the priorities will likely be different. Long-term planning is usually wasted effort.

> Employees often dont really ask about priorities. They assume priorities based on their previous experience/opinions, everyone different which leads to misunderstandings and waste of time. You have to sync them before they ask.

If employees don't know where to look for priority information that's a problem to be fixed.

> If the primary role of manager is to constantly react at suddenly appearing problems, then the company needs more planning and more organization. Those suddenly appearing problems are consequence of chaotic environment.

The world is chaotic. Reacting to change is often cheaper and more effective than planning and organisation.


1.) Requirements sometimes come in batch, but even then the following discussion and clarifications take weeks and months - depending on size of project.

2.) If your priorities are changing every two weeks, then you have no priorities. This is literally what management is supposed to avoid.

3.) The point was that employes are not aware they have priorities wrong. They are not asking, because they all assume they know what to do. Again, which is why you are supposed to clarify it proactively.

4.) If you have same sudden problem fifteenth time, then it is not change. If all of your projects end in crunch surprisingly and none of your plans work, you are doing it wrong.


> If your priorities are changing every two weeks, then you have no priorities.

Nonsense. Two weeks is - or should be - plenty of time to make a useful improvement to your product.

> The point was that employes are not aware they have priorities wrong. They are not asking, because they all assume they know what to do.

So fix that problem. Make sure they know when they should be asking about priorities. Don't just saturate them with priority information, that will annoy the ones who knew when to ask, and the ones who think they know won't pay attention anyway.

> If you have same sudden problem fifteenth time, then it is not change. If all of your projects end in crunch surprisingly and none of your plans work, you are doing it wrong.

If most of your plans succeed, you are not taking the risks that you need to make the big wins.


>>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

You are describing a Project Manager. It’s a different role than a department manager.


I (EM, coming on the end of my first year as such) have these negotiations with PMs and POs all the time. They'll ask for the world and need the technical guidance I provide to understand why they can't have it and to effectively communicate that to their leadership.


Here's a question. I've been performing tasks from "technical" and "business strategy" category for years now and feel really good about my (market|operations|product) strategy chops by now. But those management soft skills -- I'm so far behind I don't think I can meaningfully catch up to move to a business ladder if I need to do middle management first. (The best way to describe it is -- I've got a Linus' syndrome. You probably read his recent apology letter.)

But I mean, I think I can manage managers, aggressive personalities who have a clearer, shallower career goal. It's easier than managing technical folks' squishier egos.

Am I doomed?


I think I can manage managers, aggressive personalities who have a clearer, shallower career goal. It's easier than managing technical folks' squishier egos.

You're probably wrong in thinking that. But, you aren't doomed either. The skills needed to manage can be learned and practiced, just like any others. Sure, some people are "born" managers and others will never be good at it, but most competent, well-rounded individuals can probably do at least team-level management.

Does your employer have any management training/mentoring programs? If so, take advantage of them. Some of them might feel pretty "squishy" to a technical person, but that's part of managing people.


The larger org I work for is kind of strange. It's a think tank with cellular teams; team leads are usually big politically connected names (often with hard Ivy PhDs) and they directly manage their small fiefdoms.

I'm changing my original question. I think I have a lot to contribute in a strategic advisor role and I would gladly switch away from a technical career track if I could do it. Analogy: it's the business equivalent of if I had plenty of experience consulting in software architecture but couldn't program because I can't type/match keys to onscreen letters. I think I'd be a great "business architect" and enjoy that work more than my technical work.

But despite having quite some experience in an "architecture" role (something my team lead even encourages), for all visible purposes I'm a "rockstar technical person" type who's awesome at solving problems. My role in pointing out higher-order (market|operations|product) architectural/strategic stuff is much more understated, it comes as a corollary. I'm glad to have the "architectural" influence I have with my team lead, but would love to make it a main career, be able to change orgs and retain this role, etc.


If I'm reading this correctly, what you just described is what I'd call a product manager (and a fairly senior one at that). Generally a completely different role and position/title than personnel and/or project management.

Within my current org, I know a few people who have transitioned from technical roles into product management roles, usually mid- or late-career. But, we have a dedicated PM group, so it's just a matter of chatting with them and waiting for a position to open that's a match.


There's a another twist in here when you have organizations that use "matrix" management, where you not only do you have line managers (like the role described in the medium article), but you _also_ have project managers (PMP's) and program managers.

A good line manager will shield his folks from project-management bullshit mind-games. Giving PMP's direct access to your people is a recipe for stressing out everyone involved. Unfortunately, that is becoming more and more normal these days as the manager-to-contributor ratio converges to or exceeds one.


Business folks: please create parallel technical and managerial career paths.

Technical people are pretty much second class as it is, the last thing needed is to cement the status quo.


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

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.


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.


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?


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.


What's the reason a stooge collection means it's time to go?


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.


the first one is the big one. The inner circle. You'll never be in it, with a manager that just hires his/her entourage over and over again. You'll always be the muggle no matter how hard you work or are patient.


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

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


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.


+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.


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


> Yes, you could probably get it done better and sooner ...

It's a fine example of the potentially counter-intuitive 'Law of Comparative Advantage' [1]

[1] https://en.wikipedia.org/wiki/Comparative_advantage


> Yes, you could probably get it done better and sooner

This is a really hard one for me when under pressure: knowing that I can do it myself correctly in about an hour, but giving to to someone else who will probably take several iterations before it's right, resulting in a week or so turnaround and probably 8 hours of work. Or worse, half a week and it never being "right" because we just don't have time.


I've struggled with this a bit as a new manager, and eventually came to the realization that I was so afraid of micromanaging that I was letting people struggle and fail more than I needed to, by not giving them detailed enough instructions.

If you could do the task yourself in an hour, then you could also probably give very detailed instructions in 45 minutes (which ends up with a written plan in a google doc or similar spelling out every detail of how it's going to be done), or even pair on it to get them started.

Maybe you haven't saved any time over doing it yourself (maybe it's even taken MORE of your time!), but you've ensured the thing got done right, and you've also helped level up the skills of the person who did it, so that next time they'll be more capable of taking on a similar task alone.


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.


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.


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.


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.


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


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.


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.


That's how you're supposed to do it. My manager had a nack for only giving the negative feedback 3 or 4 times.


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.


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?


What I've seen a lot is lots of companies do not have a meaningful Individual Contributor technical career track. You join as a junior developer, then 5 years later you are a "Senior Software Engineer" and that's it. Your salary flatlines, your project responsibility/impact is capped, with no further opportunities to grow career-wise. Join another company? Fine you get a 5-10% pay bump but you're still at the highest level: The dreaded "Senior Software Engineer". OK, so some places have a "Staff Software Engineer" or "Principal Software Engineer" or whatever they call it. It's still basically the end of the road for a non-manager. So few places offer anywhere to grow after reaching this level, besides management.

These companies then say, "Hey, engineer XYZ, you seem to be smarter than the average bear. We would like to reward you with career growth, but we are not imaginative enough to come up with something beyond Senior Software Engineer. How about instead we make you a manager? Go, here is a team of people, go off and learn this entirely different skill set and manage people! What could go wrong?" That's pretty much how most places make engineering managers, and it's tragic. Here we have some of the smartest, technically competent people. I mean they rock as individual contributors and should be thriving. But they're not because they don't want to be managers, they just want a software development career!

To me the solution is to simply let coders code and hire managers to manage, and provide equal career and salary growth to each group!


I wish more companies did this. We have such a hard time with this in our culture. Even at a company that has a good IC track, it's usually fake. The person eventually gets perceived as expensive and is laid off.


How can a lone engineer scale their impact after senior? I literally think the career ladder flatlines there because business value flatlines there too. It be nice if companies had work above it but I think it's hard.


Here is a hint for you - don’t only show your boss what you can do - show the world what you can do.

Then 10% pay raise may suddenly evolve into 100% at way cooler place


My point is not about pay. It's that I can only do so much, and the only way I can acheive more is by having a pyramid of engineers underneath me doing the coding.


Then you need to be a manager. Organizations where there is a tech lead who does people management, or where it's "flat" (i.e. no managers) tend to develop informal, unspoken, or hidden political structures that fill the role.


A friend of mine quit his job when they essentially forced him into management. To your point it would have been a slight increase in salary. But much more work that he didn’t enjoy and considerably less flexible work environment. You’re right these things should be obvious to companies. The things most good programmers enjoy and value are rarely the same things that managers, even good ones, are looking for.


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

I don't think they're orthogonal skillsets. A major part of management (arguably the most important part) is helping your team improve their skills, which works much better if you're a skilled engineer yourself.

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

Yes, becoming a manager will stunt your growth as a developer.

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

You probably wouldn't enjoy managing then.

> 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?

Definitely not. Most big companies have separate technical and management tracks, and most developers shouldn't go into management.

> Can someone explain to me why I should want to become good at management?

The major reasons to become a manager are: (1) you can have a much greater impact on the business as an Xth percentile manager than an Xth percentile engineer, or even an (X-20)th percentile manager; (2) you enjoy teaching and watching people grow; (3) you're more interested in causing good software to happen than you are in building it personally.


Great summary.

Only reason I’m in a half technical role instead of still in SW dev track is my company and the industry in my location does not generally have good career paths while staying an IC, so for sake of my family I’m doing this for the doubled pay check to put us into financial independence.

But I’d much rather be coding.


Why would you want to move to management? The answer is scale and impact.

As an individual contributor, there is just so much you can add to the product. If you find a product that you deeply care about, and want to build great, large features for it, at some point it's easier to lead a team than to code by yourself.

In your case, with only 5 years of experience, I'd say it's typical to work as an individual contributor for at least another 5 years (10 in total). No rush to move into management yet.


It depends on the size of what you want to accomplish. If you're happy only accomplishing what one (even superhuman) individual can do, then you're all set. Necessarily, if you want to accomplish things that only a team can do (larger or more complex projects), you're going to have be able to manage people other than yourself.


On the other hand, there are many projects where an average team of engineers will fail, regardless of how good their manager is, but that one talented individual contributor (or a handful of them) can successfully deliver. Managing more people doesn't necessarily mean having a larger impact (even indirectly).


> On the other hand, there are many projects where an average team of engineers will fail, regardless of how good their manager is

I'd love to see some examples of this because IME it's not true. Great managers/leaders take normal teams and make them successful. Rarely can a single great team member or a great team succeed over a poor manager (unless they essentially start managing themselves).

It reminds of the old adage about great football coaches. The great coach will take his team and beat yours, and then take your team and beat his. Leadership and management is all too often underestimated by engineers and that is to their detriment.


Successes as an individual contributor are a great feeling, but not to the level of the amazing feeling you get when you successfully execute a strategy that requires coordination of a large number of people to perform a complex task.

I'm all about the feels.


But...am I accomplishing those things, or am I going to a lot of meetings about how to make the customer feel good about the things we accomplished?


I'm in the same boat as you. I'm a senior developer - it's what I love doing, and it's what I'm best at. I have absolutely no desire to move into a purely managerial role, but am happy to act as a tech lead where necessary. You're not alone.


You, personally, sound like you should probably not move into management; you should find a company that has big technical projects that need technical project leadership (e.g. architect, principal, tech lead IC roles).

For me, my goal is to optimize my career for impact, and I noticed what a huge impact good vs bad managers made on my life & on the whole team, so I decided management was a niche where I could really make a big contribution. I'm not sure if I can be a 10X IC, but I think I can be a 2X manager for a team of 5.


> Can someone explain to me why I should want to become good at management?

You said half of it yourself: because transitioning from engineering to management entails a promotion.

(The other half: because at most companies, a promotion in turn entails a raise.)


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

Good management isn't just people skills, it's the ability to judge the output of your team so that you can keep quality high. Non-technical managers can't judge quality, only measure the team's self-reported progress against external requests for which they serve as gatekeeper. Non-technical managers lack a sense of how long requests will take to fulfill, which results in either a) agile-style workflows where ICs need to have daily meetings to explain to non-technical management why tasks take as long as they do, instead of technically-competent managers being able to reason estimated for themselves, b) unrealistic deadlines where non-technical management presses ICs to do the impossible, which inevitably results in sacrifices to quality, or c) continually slipping deadlines and an inability to ship. Companies promote ICs to management because you can teach people skills to engineers, but you can't teach the love of engineering (continually honing your skillsets) to professional management.

> "tech leadership" (advising on engineering reviews, making technical decisions about how to best build things).

Otherwise known as a software architect, who spends his time diagramming up larger designs and communicating them to engineers, not writing code. Because of the inordinate amount of time needed to get people in your organization to align with your technical vision, as a software architect you will need many of those same "orthogonal" soft skills which management needs. If you want to spend your career being left alone to write code, then you don't want to be a software architect.

> I would basically worry about stunting my development as an engineer if I switched to focusing on management

Try to imagine the job of a head chef in a Michelin-starred restaurant. Would you say that his job is more managerial, or more culinary? Most people would say culinary, and few would assume that you could take somebody with a high school diploma, take a course in "Agile Kitchen Operations", and be qualified. Yet the job of a chef is very much more managerial. The chef spends little if any time chopping vegetables or stirring pots, instead the chef's job is to make sure that orders are moving smoothly through the kitchen and being made to the highest quality. That is a culinary profession, and engineering management is just the same, it is an engineering profession.

> 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 the fear of somebody who has served on a team with teammates who were incompetent (as have we all...), and not wishing to be in the position of their manager, who needs to live with the output of incompetent engineers. The reality is this: if you are a manager, and you think the people on your team are incompetent, and that no amount of mentorship or training will lead to the professional growth of said poor excuse for an engineer, then you should have the ability to fire them and replace them. The way that you can feel good about your output being determined by the people on your team, is either by handpicking them when you hire them, or putting enough of yourself and your experience into the individual members of your team that you start to see yourself in their output.

> I think I prefer empowering other engineers by leveraging knowledge and writing good platforms/tools/APIs rather than doing the organizational empowering thing)

Platforms, tools, and APIs don't do nearly as much as "organizational empowering" or "unblocking" does. For whatever engineering output metric you choose, giving engineers good management will do a much better job of improving those metrics than giving them Yet Another Tool. Good management is hard, Yet Another Tool is just another magic pill sold to executives as a way of shortcutting their way to engineering greatness. When have you ever seen that happen?

> 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?

Just like there are different types of engineers, there are different types of managers. You don't have to be the kind of manager who's in back-to-back meetings and sees her team only for morning stand-ups and weekly planning meetings; you can instead decide to be the type of manager who's much more hands on. You can choose which type of manager you want to be.

> How does one keep learning their craft without direct experience?

Eventually you get to a point in your career where you understand that there's rarely anything truly new under the sun. If you understand the discipline well enough - you understand how things fit together, how much time things are supposed to take, what good code and design looks like, how to react when production blows up, how to keep it all secure, etc. - then you understand that you don't need to have deep experiential knowledge of whatever newest tool your team is using to solve business problems. You understand further, that if that lack of knowledge really does bother you, you can decide to be the kind of manager who dedicates some time to reading documentation and code instead of going to back-to-back meetings every day of the work week.


Thank you for taking the time to write up this long response. That's definitely a lot to think about!


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.


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.


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


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


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/


There's also the Rands Leadership Slack: http://randsinrepose.com/welcome-to-rands-leadership-slack/


Rands is awesome


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


For more of this, I recommend this podcast:

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.


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.


Excellent summary with one caveat: balance (1) and (8):

  1. (don't) Keep coding
  8. (don't) Stop learning your craft




Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: