Engineering Management Checklist (2021)
pnewman.org
pnewman.org
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 :)
Shameless plug: I help EMs on this journey as a coach, advisor, and partner.
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.
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 would wager this is true of most managers.
I would also wager that any formal training would fail HN approval anyway.
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.
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.
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.
Becoming an employer with responsibility for employee supervision, benefits, payroll, rent, etc is ignored in medical school.
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.
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.
https://substackcdn.com/image/fetch/w_1272,c_limit,f_webp,q_...
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.
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.
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.
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.
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.
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.
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.
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
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.
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.)
Very much disagree on that point.
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.
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 :)
> 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.
Interested to hear what others think here!
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.
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.
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.
You know DEI has reached terminal velocity when this starts showing up on linux mailing group text emails archives.