I would wager that very few engineering managers have significant formal training in management. While software engineers can hold a wide variety of degrees, the most common is a CS degree, and few of those include significant coursework specifically about engineering management.
Thus, unlike with IC-track positions, it is likely that an engineer promoted into a management role is coming in cold. And while there are a variety of helpful books and training materials about engineering management, in general new EMs are expected to mostly learn by doing.
“Learn by doing” can be tricky, however, because many of the issues a seasoned engineering manager is expected to be able to capably handle do not happen every day. They happen relatively infrequently, and sometimes only when you change teams, but you need to know how to handle them when they do occur.
Because engineering management is largely a “learn by doing” craft, and because it can take years in the role to experience even the half of what a seasoned EM is typically expected to be able to capably handle, I would argue that the best EMs are those who have had abundant opportunities to learn from their mistakes. But you can certainly speed that up at least a little bit by learning from other people's mistakes instead :)
Having experienced managers work closely with first-time managers is very helpful. Throwing first time managers into the position and hoping they figure it out is dreadful.
The actual training material available for EMs is not great. There are a couple decent books that will run someone through the basics of doing 1:1s, communicating with the team and upper management, and doing other basic manager stuff. Unfortunately the more expensive and longer form trainings are just versions of this same basic material stretched out into a slog of slides and quizzes you have to click through.
This void has also created a weird class of managers who have read every businesses book and trending LinkedIn post. This gives a false confidence that their book knowledge solves everything and makes them superior to “untrained” managers who haven’t read all the trendy business books. When someone can barely make it through a meeting without a “Have you read ____? It has something to say about this” flex then I start to suspect that they’ve let their book-based confidence take precedence over experience.
The trend is bad enough that I’ve had several peers or managers in recent years who almost couldn’t parse a situation without mapping it back to a book they had read. I lost a lot of time trying to explain to people that I have also read “The Phoenix Project” or “Turn the Ship Around” or other trendy books but the problem I’m describing is something else that can’t be solved by re-reading your book recommendations.
I was that manager for a bit. I think it’s a phase some of us go through because we are excited about what we learn just like an early mid-level would get excited about a new framework.
It takes a while until we get to “okay, I’ve read enough that this all rhymes.” I still pull out a “have you read” occasionally, though, because it is the easiest way to communicate a thought and I can’t assume a basic curriculum that all EMs share. It’s as if you couldn’t assume your peers had ever heard about microservices. It doesn’t mean that everyone needs to use one or that it’s always the right pattern, but it facilitates conversation and conveys an idea.
I don't think formal management training, e.g. an MBA, helps much. I think it's even harmful, as this type of training tends to be very generic and focused on high level matters.
In my career, these kind of "professional managers" have tended to be blunt instruments who don't respect or understand important information coming from their technical staff, and have caused a lot of damage as a result.
I genuinely think it's more than enough for a new engineering manager just to read a few books on how to do it well, and read articles like this one. So long as they take it seriously, meaning prioritising the management over any coding work they have, they'll do fine.
But surprising, most don't even do that. They get promoted, and then they just wing it. I've seen it happen repeatedly that they make no effort to study around their new role, and to hone their skill in it. It's quite strange.
I became an EM fairly early in my career, and was very aware of how much I didn't know, so I completed an MBA.
It helped with:
- the formal stuff of management; legal obligations, how to fire someone properly, etc.
- leadership training. The difference between leadership and management. What leadership involves, and how to do it well (although a lot of that is down to innate charisma, there are some things we can learn).
- basic management stuff: how to interview someone, how to organise a meeting, how to negotiate.
It was useful. I'm not sure I'd recommend it for everyone; I think I could have got the same benefit from a smaller, more focussed management course. But having an MBA as an engineer definitely leads to interesting places.
A bad manager can blight quite a few people's lives. I fantasise about there being an internship/registrar/apprenticeship system for managers.
An accreditation system with professional on-the-job evaluation on a regular basis would be ideal, but too hard to do in reality, I guess. I sure would like to work for a properly accredited professional manager, though.
I think one thing that makes it even more challenging is that most of us in Tech become managers after having been great ICs with good communication skills, and the transition is not always managed (pun intended) amazingly, both in terms of personal and company expectation changes.
Most ICs I know used to know their system amazingly well, being "tech leads" and became team leads. Most of them struggle to have to "share their time with those annoying tasks that take their time" and "not having enough time to code any more" not realizing that it's simply not their job any more.
Your job is to grow your team to succeed today and be ready for tomorrow, create the business value that is expected from you as a team, and grow your people. That typically means letting go of what you were doing yesterday.
I've seen people complain that because they have to manage a team they don't get to "have enough time to take all decisions in the best way" any more.
I don't think it's a failure of those managers as much as the managers above them. Most folks I know have the right social skills, it's expectation management and coaching about those expectations that they need the most.
This is so true. Being a freshly-minted EM is a full time job. Learning how to be an effective EM is another full time job, through reading, reflection, and instruction.
Shameless plug: I help EMs on this journey as a coach, advisor, and partner.
As someone with newly minted managing responsibilities, and some training in management as well, learn by doing is hella tricky and hard. I think people that start off as managers also go through this, and there is so much that you have to learn by fucking it up, running into problems, and pissing people off, when you want to help them.
I really hope this isn't universally true. While management training varies across industry and activity, and while there are lots of jokes about managers, the actual percentage of large disasters that occur under newly minted managers must be somewhat low otherwise the world would grind to a halt regularly.
Yes, software development / engineering may hold a special place due to frequency of "doing things we've never done before". Everything cannot rest on the manager's shoulders otherwise they are bottleneck and their previously-skilled peers are suddenly incompetent without them at their level.
It's not so much large disasters, as it is small bumps along the way, that most of the time the teams recover from. The thing is the things you learn about are often more subtle and happen on different time scales when you encounter them in the real world. And a lot of the time the work happens despite managers.
Though I would add that looking back to when I was an IC, my Computer Science degree hadn't given me much if any formal training in Software Engineering (especially in a large team and code base) and I mostly learnt by doing that also.
The industrial/corporate training provided at the university level is generally very very low. Doctors/Dentists/medical professionals are often thrust into systems where they are expected to handle billing and patients and paperwork and legal responsibilities. Experience during a residency is not sufficient if you are essentially starting your own business, even if you are joining an existing office.
Becoming an employer with responsibility for employee supervision, benefits, payroll, rent, etc is ignored in medical school.
Of my first two hires, one was clearly over-employed and had to be let go, and one had to leave due to long COVID, which was heartbreaking. Thats a sort of “being thrown in the deep end” :).
Imho EM has become a lot more difficult because it has been split into Manager, PM, TPM, scrum master, and all kinds of other shit. It’s weird watching teams struggle so much because you have 3 or 4 people trying to do similar jobs and stepping all over one another and ownership goes out the window.
I chuckled because literally zero number of people among the set of EM, PM, TPM, Scrum master actually take responsibility of the actual work. They are all just ordering someone more skilled than them.
I agree with this generally for TPM and project managers. Even then it’s not that they truly do no work, but that the core coordination work they do (which requires very few, but no 0, man hours) could be done with higher fidelity and context by an EM without it really adding much more work to an EM’s job.
Engineering managers are responsible for their team’s output; they are often held responsible when their team fails to deliver. Product Managers are responsible for setting and prioritizing the product roadmap across a lot of stakeholders, often with specific business goals to achieve, and spending a lot of time doing stuff like talking to customers and helping with marketing/sales/planning/etc; they are also often held responsible when they don’t deliver on these tasks.
It is a very junior engineer perspective to consider it not actual work or for them to have no real responsibilities just because they are not coding. In my experience it has also been common for EMs to be at least staff level ICs skill-wise and PMs to have enough software skills (often having previously been SWEs) that they could be SWEs if they preferred that.
> Engineering managers are responsible for their team’s output; they are often held responsible when their team fails to deliver. Product Managers are responsible for setting and prioritizing the product roadmap across a lot of stakeholders, often with specific business goals to achieve, and spending a lot of time doing stuff like talking to customers and helping with marketing/sales/planning/etc; they are also often held responsible when they don’t deliver on these tasks.
While this is not wrong, ask yourself as a thought experiment, what happens to the engineers if an EM over promises due to incorrect scoping or a PM leads engineers down a rabbit hole that the company doesn't care about? Hint: The engineers still toiled for that wild goose chase.
In my experience, there are far too many stakeholders (EM, PM etc.) who want work to be done by engineers but none of the stakeholders want to listen when engineering points out some fallacy, or incorrect scoping, or unknown unknowns.
Engineers don't get heard even though they are the ones doing the work. Instead, they often get blamed for speaking the truth. As simple as that.
In the past 10 years I only worked with one manager who had staff level IC skills. It’s much more common to have a mediocre EM that doesn’t even look at the code. If you’re “managing” a 4 person team and not at least looking at PRs, seeing the actual work product, you are out of touch.
A four person team would typically have a "team lead" who is rarely responsible for providing feedback to their engineering manager with performance reviews, goal setting, and so on.
I however wouldn't expect the EM to do more than glance at PRs and see if they are moving along and the comments are constructive. But it is very rare that someone who is not working regularly with the code would be able to maintain a useful mental model of the code. Thus the glance might just be at a dashboard to determine if PRs are "too big" or are having unexpected amounts of time being ignored.
I'm mostly talking about smaller companies where the EM is the team lead.
A lot of these companies have bloated managerial structures, even in smaller orgs... You didn't see this 10 to 15 years ago. It disgusts me when I go to a meeting, and there's literally 10 people on the call, only 3 of which actually do any direct work on the project.
> I'm mostly talking about smaller companies where the EM is the team lead. A lot of these companies have bloated managerial structures, even in smaller orgs... You didn't see this 10 to 15 years ago.
This has been my experience as well. What are all these non-technical EMs doing in an engineering org? Why are they spending so much time on HR work or org structure work?
The problem with EMs spending so much time on non-technical stuff is that they lose sight of what they are managing - the services and the team building the services. They start focusing only on org structure, perf reviews, promos etc. all of which have nothing to do with the job of managing services.
Then they start imposing non-technical workload on their reports because that non-technical stuff will improve their own ratings e.g. boosting PR counts, JIRA story points etc. - once again, these have nothing to do with the actual services they are responsible for.
The whole org turns upside down with far too many managers on the management track asking for work that has got nothing to do with actual services - and yet the burden is imposed only on engineers.
This leads to disgruntled engineers because engineers don't want to follow a HR leader. They want to follow technical leaders.
The EM solution for this is to hire a staff engineer. But once again - they are imposing the same non-tech burden of PR counts, JIRA points on this staff engineer and all other engineers.
The problem is management itself. But they will never recognize that.
Sounds like you've just worked at shitty companies.
The managers at my company are some of the most technically skilled. Several of the directors have committed code recently on stuff I wouldn't touch with a ten foot pole.
This attitude is an immediate red flag to me. Insert the xkcd of everyone on the subway with the same thought bubble over their heads. The lingering “rockstar developer talent” stereotype, especially in SV, only serves to add fuel to this fire. Developers aren’t special.
No they aren't. But, in that image, they are the only ones without whom the work will not be done.
In other words, everyone else in that image is even less special than developers. Anyone unable to acknowledge the mediocrity of other job roles is a massive red flag imo.
I'd argue you need this split - managing people is different skill set to managing a project, which is different to managing the technology, which is different to managing a product.
They do overlap, but to me there is a clear line between their responsibilities and authority. Things get blurry in smaller orgs, but in larger ones with multiple product streams, budgets and stakeholders - they're usually pretty clearly defined roles.
Like many things, it sounds good in theory which is why many try it... but in reality it often turns to shit because you end up with 4 quazi-managers all stepping over everyone else and constantly asking the team to do extra work (like generating data/reports or attend meetings) that's really their own damn jobs because surprise-surprise being technically capable of more than making spreadsheets wasn't part of the original job requirements.
I bang on regularly about "software literacy" - that software is another form of literacy and will impact how companies orgise as much as actual literacy did.
And one important slightly snarky point I make is that often you will hear people say "I used to code before I got into management but now ...". Yet no one says "I used to read and write before I got into management..."
The editor of the new york times will be able to read every part of todays print. He will have sun editors who in total have read every part of the paper going out today. And checked it.
Do we think that every engineering manager has read every changeset going out the door today?
This checklist is good for people management - but has sod all to do with software management
I'm the author of this list. Your point about reading code in particular is spot on, and I'll address if I do another revision of this. I originally wrote this for an internal audience of peers, so it's great to have feedback from the general public. Thanks for reading!
Well thanks for replying. :-). I will try to be a little less acerbic next time (am actually putting most of these "software literacy" thoughts into a book so grateful that i'm to sparking a thought in you too)
It’s not wrong, but also checklist is not a practical way to approach this job, in my experience.
All the listed activities (and we could list 50 more) are situational and should build to the needs of your job goals. It’s not a hard job and trying to list every detail can be misleadingly overwhelming.
Aim to help people you manage grow, the team be a team, peers be better off than they would be without you, and your company make money or whatever it makes - and you’ll be doing well at the job.
If you're coming into engineering management from engineering (the most common path) you're moving from managing computers, which always do exactly what you tell them to do, to managing people - a very, very different kind of thing!
I have enormous respect for the skill of people who do this job really well.
You’re right - it is not the job for everybody. Perhaps the perverse incentives pushing folks into management for career growth have contributed to lot of human-job misalignment and to this narrative of almost superhuman effort. In what I’ve seen, EM culture tends to keep building that myth up.
Any job is sometimes frustrating, taxing, etc, no argument there either. Big plus one to computers
winning on predictability, but humans get the point on autonomy (EM just needs to let go of the idea of telling anyone what they must do). But fundamentally, assuming the personality traits match (a lot is learnable), it is no rocket science, just people.
PS i reread earlier comment and see how it can come off. Not speaking as a engineer who doesn’t understand their manager’s job, but as someone who has been doing it for a decade and managed/mentored/coached number of newer EMs on the way :)
The difficulty an EM job depends a lot on the situation. If you have a strong and healthy team with sufficient skill and technical chops then it's mostly about staying out the way. On the other hand, if you have a weak team surrounded by various kinds of organizational dysfunction it can be an incredibly difficult and taxing job.
It’s certainly an unpredictable one, never know what new fires the next week brings, or when they set off a chain reaction pushing the whole team to the brink of despair. Being able to have mental boundaries and (this sounds cold) emotional distance helps a lot!
That's a flippant dismissal of my point. I'm not talking about chaos. I'm talking about truly difficult situations, like the team not having the skills to meet management expectations, or a dysfunctional dynamics where product or finance are making engineering decisions, or Peter-principle cases being promoted into middle management without the maturity and judgement to make good decisions. If you think the biggest challenge to engineering management is compartmentalization, then you haven't faced truly hard problems in an environment with high expectations. These things come on a continuum from easy to impossible, and it's never quite clear where that line is.
No dismissal intended! Was agreeing with you on the premise of a barrage of difficult situations (=‘fires’) in the job. The kinds of challenges you list are to be expected and normal business as usual, but imho doesn’t have to make the role more taxing or difficult than any people-facing corporate job with some accountability. It’s luckily not a boring job either (ymmv, boring = unchallenging). Most situations line or middle manager faces have been solved countless times before, and either have reusable playbooks / mental models to start with, or can benefit from applied common sense and creativity. It’s mostly fun.
The point I badly tried to make was around EMs mental state & health - managing emotional coupling creates space, necessary for the EM to find pragmatic solutions, or workarounds for things far beyond control. (Not that occasionally the problems don’t keep me awake at night, but that was also true for technical challenges as an engineer.)
A checklist is helpful. It helps you to think of all the things that you would not normally think of. It’s not something that can be checked off 100%. It is a tool to bring your attention to things that would not otherwise occur to you.
This a nice checklist indeed! This point stood out to me as interestingly debatable:
> conflicts are resolved in a fair and respectful way
Over time, I think I've become less enamoured with the concept of 'fair' for specific engineering disputes, whereas 'respectful' seems like it would actually benefit from the decision being less fair. Here's how:
- In the context of an engineering decision, the informed opinion of just one engineer is usually preferable to a attempt at compromising within a group that doesn't have consensus. Of course, unanimous consensus would be even better, but that rarely happens in groups larger than about ten people (in my experience). With architectural decisions, you need a clear and cohesive vision, and with smaller decisions like style guides it's often down to personal preference.
- When a specific engineer is explicitly given authority for a certain topic (eg. "Bob gets the final say on anything related to user authentication"), the manager can follow that without being disrespectful to those who hold contrary views. Attempting to form a compromise usually ends up devaluing both opinions, as neither is completely satisfied.
- If there are serious concerns about the nominated individual's motives or qualification to make a certain decision (in my earlier example, for instance, maybe someone realises that Bob doesn't really understand important concepts in the field), that concern can be elevated privately to the manager, who can reshuffle the team without having to confront the issue in front of the team, which would be embarrassing and disrespectful for all involved.
In conclusion, I'd say that if you have a semi-hierarchical structure within an engineering team that is itself fair (not merely based on traditional seniority, that is, perhaps more like a meritocratic government cabinet rather than a strictly promotion-based military), you can omit fairness in detailed discussions for a more productive and respectful decision-making process.
I'm the author of this list, thank you for reading and sharing your feedback.
I deliberately left this type of guideline open for interpretation. I don't think anything you said is incompatible with fairness or respect. Fair can mean that the people with the greatest expertise get the deciding votes.
Perhaps it is telling about my preconceptions that with 'fair' I jumped to the conclusion that it meant 'equal say' within a team. As you and riwsky rightly point out, fairness can mean a system that consistently prioritises specific expertise in discussions.
I think most people simply would not describe what you propose as unfair, and that the property you are arguing against is not actually “fairness”, but more like “compromise”.
I'd add some encouragement and priority for anything your team is doing that shows ownership of the product or process.
Often this comes from individuals, such as the "go to" person who hacks on the development environment the most, or the engineer who everyone seems to ask for help writing tests. If you can see the value in those activities, it would be much appreciated if you schedule time for them, taking the day-to-day pressure off the individual a bit.
Like so many other treatises on engineering management, this fails because it does not focus on people, it focuses on tasks and treats people as compute.
Always communicate clearly and directly without ambiguity and assume by default engineers are communicating that way.
I don't know what it says about me but it's a f@king nightmare trying to decipher what managers mean and always saying things clearly and specifically myself and yet that gets interpreted wildly wrong.
Dumbest comment I've seen on HN all week. How is that a suggestion and how can my surprise be downvoted? Sometimes this community likes to think it's superior but acts no better than reddit.
Not everything needs to be optimized for mobile. The FA clearly is not, so don't read it there. I don't think that's necessarily meant to be as snarky as it may have come off.
Thus, unlike with IC-track positions, it is likely that an engineer promoted into a management role is coming in cold. And while there are a variety of helpful books and training materials about engineering management, in general new EMs are expected to mostly learn by doing.
“Learn by doing” can be tricky, however, because many of the issues a seasoned engineering manager is expected to be able to capably handle do not happen every day. They happen relatively infrequently, and sometimes only when you change teams, but you need to know how to handle them when they do occur.
Because engineering management is largely a “learn by doing” craft, and because it can take years in the role to experience even the half of what a seasoned EM is typically expected to be able to capably handle, I would argue that the best EMs are those who have had abundant opportunities to learn from their mistakes. But you can certainly speed that up at least a little bit by learning from other people's mistakes instead :)