[HN Gopher] Engineering Management Checklist (2021)
___________________________________________________________________
Engineering Management Checklist (2021)
Author : luu
Score : 208 points
Date : 2023-10-19 18:25 UTC (3 days ago)
(HTM) web link (pnewman.org)
(TXT) w3m dump (pnewman.org)
| lloydatkinson wrote:
| This is really hard to read on mobile
| fancymcpoopoo wrote:
| don't read it on mobile
| lloydatkinson wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| "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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| ebiester wrote:
| 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.
| paulddraper wrote:
| > I would wager that very few engineering managers have
| significant formal training in management.
|
| I would wager this is true of most managers.
|
| I would also wager that any formal training would fail HN
| approval anyway.
| 3c6bYDXLMj wrote:
| 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"
| :).
| _rm wrote:
| 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.
| marcus_holmes wrote:
| 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.
| tuatoru wrote:
| 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.
| pandog wrote:
| 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.
| pvdoom wrote:
| 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.
| franzb wrote:
| One can also learn a great deal from their own (seasoned)
| engineering manager.
| jlengrand wrote:
| 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.
| seabass-labrax wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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_...
| pc86 wrote:
| 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 wrote:
| Please name the company if you can. Good companies need to
| be highlighted more.
| ocimbote wrote:
| I was hoping your link pointed to this picture.
| opportune wrote:
| 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.
| icedchai wrote:
| 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.
| nine_zeros wrote:
| > 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.
| 3c6bYDXLMj wrote:
| 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.
| nine_zeros wrote:
| > 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.
| elbear wrote:
| Good managers coordinate. They don't give orders
| _s wrote:
| 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.
| liquidpele wrote:
| 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.
| lifeisstillgood wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| badrabbit wrote:
| 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.
___________________________________________________________________
(page generated 2023-10-23 09:01 UTC)