7 ms·

Engineering Management Checklist (2021)

227 points by luu 3y ago

lloydatkinson 3y ago
This is really hard to read on mobile
- fancymcpoopoo 3y ago
  don't read it on mobile
  - lloydatkinson 3y ago
    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.
    - pc86 3y ago
      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.
nodoodles 3y ago
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.
- koliber 3y ago
  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.
- dasil003 3y ago
  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.
  - nodoodles 3y ago
    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!
    - dasil003 3y ago
      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.
      - nodoodles 3y ago
        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.)
- simonw 3y ago
  "It’s not a hard job" 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.
  - nodoodles 3y ago
    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 :)
r0s 3y ago
Pretty good list. 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.
jawns 3y ago
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 :)
- koliber 3y ago
  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.
- Aurornis 3y ago
  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.
seabass-labrax 3y ago
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. Interested to hear what others think here!
- riwsky 3y ago
  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”.
- pnewman002 3y ago
  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.
liquidpele 3y ago
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.
- nine_zeros 3y ago
  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. https://substackcdn.com/image/fetch/w_1272,c_limit,f_webp,q_auto:good,fl_progressive:steep/https://substack-post-media.s3.amazonaws.com/public/images/7af71b76-bfc1-4572-ba48-98954b78fa91_437x492.png https://substackcdn.com/image/fetch/w_1272,c_limit,f_webp,q_...
  - pc86 3y ago
    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.
    - nine_zeros 3y ago
      Please name the company if you can. Good companies need to be highlighted more.
      - devonbleak 3y ago
        Pretty much anyone below VP at Fox is expected to still be getting their hands dirty, and I know VPs that are still deep in it.
  - ocimbote 3y ago
    I was hoping your link pointed to this picture.
  - 3y ago
lifeisstillgood 3y ago
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
- pnewman002 3y ago
  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!
  - lifeisstillgood 3y ago
    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)
Racing0461 3y ago
> 12 diversity is represented and embraced; a broad spectrum of views are considered You know DEI has reached terminal velocity when this starts showing up on linux mailing group text emails archives.
gamesbrainiac 3y ago
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.
_8j50 3y ago
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.
say_it_as_it_is 3y ago
I don't see the entry for knowing nothing about the work involved but debating to get your way about a design that doesn't solve the problem

227 points by luu 3y ago

lloydatkinson 3y ago

This is really hard to read on mobile

fancymcpoopoo 3y ago
don't read it on mobile
- lloydatkinson 3y ago
  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.
  - pc86 3y ago
    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.

nodoodles 3y ago

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.

koliber 3y ago
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.
dasil003 3y ago
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.
- nodoodles 3y ago
  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!
  - dasil003 3y ago
    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.
    - nodoodles 3y ago
      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.)
simonw 3y ago
"It’s not a hard job" 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.
- nodoodles 3y ago
  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 :)

r0s 3y ago

Pretty good list. 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.

jawns 3y ago

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

koliber 3y ago
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.
Aurornis 3y ago
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.

seabass-labrax 3y ago

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. Interested to hear what others think here!

riwsky 3y ago
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”.
pnewman002 3y ago
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.

liquidpele 3y ago

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.

nine_zeros 3y ago
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. https://substackcdn.com/image/fetch/w_1272,c_limit,f_webp,q_auto:good,fl_progressive:steep/https://substack-post-media.s3.amazonaws.com/public/images/7af71b76-bfc1-4572-ba48-98954b78fa91_437x492.png https://substackcdn.com/image/fetch/w_1272,c_limit,f_webp,q_...
- pc86 3y ago
  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.
  - nine_zeros 3y ago
    Please name the company if you can. Good companies need to be highlighted more.
    - devonbleak 3y ago
      Pretty much anyone below VP at Fox is expected to still be getting their hands dirty, and I know VPs that are still deep in it.
- ocimbote 3y ago
  I was hoping your link pointed to this picture.
- 3y ago

lifeisstillgood 3y ago

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

pnewman002 3y ago
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!
- lifeisstillgood 3y ago
  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)

Racing0461 3y ago

> 12 diversity is represented and embraced; a broad spectrum of views are considered You know DEI has reached terminal velocity when this starts showing up on linux mailing group text emails archives.

gamesbrainiac 3y ago

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.

_8j50 3y ago

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.

say_it_as_it_is 3y ago

I don't see the entry for knowing nothing about the work involved but debating to get your way about a design that doesn't solve the problem