Engineering Management

https://github.com/ixaxaar/awesome-engineering-management

by arnet • 5 years ago

106 44 5 years ago

“List of links on topics that might be interesting to engineering managers”. It’s not a book, an article on how to manage engineers, a FAQ, or even an opinion piece on any aspect of engineering management.

To be clear, it does have value but the title here could be made clearer.

tux3• 5 years ago

For those that haven't seen it before, "Awesome X" stands for "list of (mostly free) resources on X", usually on a Github repo like this one.

Some of these are pretty good!

thewakalix• 5 years ago

The word “awesome” is also filtered out of HN titles, presumably because it’s frequently used as a meaningless intensifier, but at the expense of its meaningful use here.

hprotagonist• 5 years ago

for a very tech-centric definition of “engineering”, perhaps.

nickserv• 5 years ago

What would nontechnical engineering be?

bmeski• 5 years ago

Writing React components.

manigandham• 5 years ago

The term "tech" has become a meaningless now. 99% of the time, people really mean software.

But yes, this is software-centric. There are lots of other engineering disciplines that operate differently.

ook2• 5 years ago

Put another way this is focused on project management and software architecture. It’s a good list for a tech lead or architect but is no where near complete for a people manager.

There are many other areas a good manager should cover:

  - hiring & internal talent pipelines
  - career progression - mentoring, coaching, 1 on 1s
  - performance management - promotions and firing 
  - budgeting and other finance areas
  - if required vendor management, purchasing, dealing with legal etc
  - cross team / org collaboration; working with your peers (other managers and leaders)
  - managing upwards - reporting status, flagging risks and blockers and asking for help/time, advocating for the team and projects etc
  - providing clear direction for the team while balancing that with shielding them from crap so they can focus 
  - for services - Service Ownership, Cost to Serve, On call, Security and Compliance, Legal liaison for open source use, post mortem retro’s etc  
  - general admin; vacation scheduling, expenses, it escalations, tracking mandatory training etc
  - product management and long term view - either owning it, working with an agile product owner within the team, or working with product management org
  - anything else that would fall through the cracks otherwise to keep team on track - “servant leadership”

This is just off the top of my head as a former manager and manager of managers. Depending on your org and methodologies there may be others who own lots or the above, either within the team or elsewhere. As the manager though the buck still stops with you.

ixaxaar5• 5 years ago

Indeed. I found other awesome lists that cover these topics and linked them instead. Check out https://github.com/charlax/engineering-management and https://github.com/LappleApple/awesome-leading-and-managing as examples.

dfee2• 5 years ago

What should my expectation be for EMs as an IC? I’ve spent time in management and time in The Valley, but not in management in The Valley.

It generally appears they take care of “other stuff” but are generally expensive proxies (in time, cost, clarity… “truth”) with a sprinkling of HR nonsense like personnel management, hiring and firing.

mathattack• 5 years ago

I used to undersell them HR processes as nonsense. Then a realized that a company’s true values show in hiring, firing and promotion decisions.

ixaxaar5• 5 years ago

Products change but what should remain constant are the people and the process that delivers them.

sombremesa• 5 years ago

While I agree with you in principle that engineering management is actually pretty far down the ladder in terms of real value to a business (the top and bottom layers of the org structure are usually far more important in what the company will end up doing than the middle), there does need to exist such an abstraction (in sufficiently large companies) for a plethora of reasons, many of them quite obvious.

However, that's not why I chose to reply to your comment.

HR nonsense like personnel management, hiring and firing.

Hiring and firing is right up there in terms of factors that decide the fate of a company. It absolutely cannot be considered 'nonsense', at least if you want the company to be around for a while.

milofeynman• 5 years ago

My personal view on myself as an EM is protecting my engineers from distractions (other teams, people, meetings, etc) while getting them the growth the need and the growth they want. I also help prioritize stuff working with PM so there is no confusion or wasted time thinking about what they're working on next.

bojo2• 5 years ago

As an EM I handle the two dozen bullshit things that come up each day that none of my ICs care to deal with (usually rightfully so).

Who wants to spend time: writing new job descriptions, interviewing, handling administrative duties, setting expectations with the executive team, working out cross-functional team logistics, making sure people aren't overworked, making sure company and personal career goals align, creating opportunities for training, deflecting insane requests, onboarding new members, purchasing equipment for people, let alone doing technical things like participating in architecture discussions, doing code reviews, pair programming, and as a rare treat maybe actually fix a bug?

My teams tell me I do right by them, and I hope that is true. If I ever went back to being an IC though I'd be thrilled to have a manager willing to shield me from all of this busy-yet-necessary work. As a former engineer I understand the value of being able to keep your head down distraction free.

dfee2• 5 years ago

Wow. Ok, great reply. Advice to you: don’t just market up the chain, also market back down.

Obviously this is general advice, and not specifically to you, but if I don’t see my EM adding value, then it’s little different than then not seeing me move tickets.

Again, thanks for the thoughtful response.

salawat• 5 years ago

I happen to be an expert (read: flailing desperately to do this work right) at the moment, and I thought a lot like you a year plus ago.

Oh God... How that view has changed. As a manager, if you're actually trying to make your team's lives easier, it's bloody hard work. I started out as the first IC and sort of had my role take shape from there.

I know where the skeletons are, and spend a great deal of time making sure my people know about them before falling victim to them. I'm often troubleshooting cross-team problems, and either localizing the nebulous stuff to a particular team, or getting the best teams to work together to resolve the issue in the same room, talking, and understanding each other. I'm sanity checking requirements, auditing everyone's meetings, to make sure important things propagate beyond team's silos.

I'm constantly switching between an understanding of work about 3 weeks minimum ahead of everyone else, and now, trying to figure out if divergences from what's planned is just statistical noise or something to worry about.

Then there is the HR side. Everyone has their own bucket of stuff, and it's my job to help make sure they have the tools they need to overcome it. Sometimes this means looking up weird jurisdictional things, rewriting a job description, shuffling around work, book or resource recommendations, or sometimes long after hours calls or the occasional emergency interference running. There's also making the hard calls on whether someone's forseeable future is going to be upset or not. I'm not jaded enough to just not care anymore, so I always try to make sure if a hard call has to be made, I can make sure everyone involved leaves with something in the sense of a possible new direction. That's not part of my JD but something I just feel like should be done and I'll continue to do until a really unlucky streak of bad hires beats it out of me I guess. I hope by that time I won't need to do this anymore.

The way I see it, I'm sacrificing my ability to shut up and engineer the stuff I like (software) to make sure my teams can concentrate on just doing what they are best at, and I'm context switching too much to do reliably anymore. The fact is, all these "odd-jobs" have to get done to ensure the organization runs and someone has to do it... Might as well be the one who knows the org best until I've got others trained up and confident enough to do the same.

Re: Expensive proxies I try to act as the anti-proxy. When I see bad communication, I try to get people circled around in the same room looking at the same things. My goal is not to say X has it all wrong to Y, and Z, but getting X, Y, and Z all saying the same thing about the same thing.

Sometimes you have to unlearn organizational habits to come to terms with what's actually going on. My higher ups may share your sentiment of that making me an "expensive proxy" but after the second or third projectt that has to get redone, eh, the grumbling quiets down.

Haven't been fired yet! So there's that!

cornel_io• 5 years ago

Hiring, firing, and making sure that people who are good are happy to stay around are three of the most important things that happen at a company. Teams that are bad at any one of them will fail miserably in the long run.

The toughest is probably the third, making good people want to stay around, especially when you're a middle manager who has limited power to do anything meaningful like give raises or promotions or pick projects to work on. The most powerful tool is to form good personal relationships with reports without blurring the line between manager and peer (common rookie manager mistake). Beyond that it's mostly about delivering near constant small feedback (positive and negative, mostly positive unless someone needs to be fired), shit-shielding from stuff that drains productivity, and giving opportunities to grow and learn whenever possible.

sharken2• 5 years ago

On the topic of making good people want to stay around, i would add that having smarter people than myself in the team is a huge factor.

I'm still not sure that achieving this by hiring consultants is a good idea, but it is better than nothing.

And it happens that consultants become employees, so i take comfort in that.

roughly• 5 years ago

The only thing that matters as a manager is how you manage people. The rest is window dressing. If your people are unhappy, if you're dealing with attrition, if you can't make a team cohere together, if you can't navigate your space with your peers and org, no amount of agile raci matrices will save you. Pick your head up and look at your people.

decebalus1• 5 years ago

Oh, super! A comprehensive list of pointers to an overwhelming quantity of information (as basic as linking to wikipedia or to slack? seriously?) which probably has some value in terms of cataloging?

Is anyone actually a fan of those `awesome` lists? They get starred and everyone tweets and retweets them but in theory it sounds like something awesome, while actually being pretty dull and quite useless in the long run.

In this case specifically, where engineering management is something intrinsically people focused, oh great, a bunch of links to email providers. This is some prime content spam.

coffeefirst• 5 years ago

Yeah, especially when you actually become an engineering manager, the first problem you run into is how to deal with information overload.

It'd be better to recommend one or two books.

sharken2• 5 years ago

Not a fan, was expecting at least some coherent text about Engineering Managers, but instead get a long list of links, not much better than what I can find myself.

At least the comments in this thread are useful and interesting.

ixaxaar5• 5 years ago

Information overload can only be tackled by organizing stuff, documentation, knowledge management etc. Most of which are processes or tools, which this list tries to capture.

I wrote this list for EMs in my org so they can have a handy list of tools and a good point to start digging deeper.

Of course, sharing such a long list will inevitably cause the TLDR effect. https://www.psychologytoday.com/us/blog/boundless/201903/the...

thanhhaimai• 5 years ago

I randomly clicked on a bunch of links and read them. To be honest, it scares me a bit, since it matches the description and behaviors of engineering managers I had bad experience with and would avoid if possible.

The best characteristic for a good manager is that they care. This list to me highlights a path for "how to be a bad manager". I hope people don't follow this.

amirkdv• 5 years ago

I suppose link compilations like this have some value some times. But if you clicked on it because you're new to EM and keen, here are a few books that are much more helpful IMO:

- The Manager's Path, by Camille Fournier

- An Elegant Puzzle, by Will Larson

- Team Topologies, by Matthew Skelton and Manuel Pais

- Thinking in Systems, by Donella Meadows

- Also see: references cited in the above and other works by same authors

Disclaimer: Not a seasoned EM and definitely not the first to recommend these on HN.

brianfitz• 5 years ago

Also highly recommend the book “The Phoenix Project”. It highlights common pitfalls and solutions through a narrative of a character thrown into their first time leading a team.

ixaxaar5• 5 years ago

The "Devops Handbook" should be a must if you're into platform.

ook2• 5 years ago

- “Managing Humans” by Michael Lopp aka rands - https://managinghumans.com/

A edited collection of blog posts with other material that does a very good job describing how to tackle the transition from Engineer to Manager.

- “The Truth About Managing People” by Stephen Robbins https://www.pearson.com/us/higher-education/program/Robbins-...

An invaluable “Cliff Notes” style book about many topics (truths) in management. Each topic (“truth”) gets a page or so overview, key points and links to the standard “references”.

wsinks• 5 years ago

Hahah, Managing Humans is great. I saw someone reading it on Muni, read it over their shoulder for a few stops, and bought it later that day.

ixaxaar5• 5 years ago

The Manager's Path, by Camille Fournier is my personal favorite. Highly recommended.

jacobsimon• 5 years ago

+1 to Manager's Path and Elegant Puzzle

One other point I'd add that isn't covered particularly well in this list: the process of becoming an engineering manager and interviewing for the job[1] are both challenging processes unto themselves.

[1] https://blog.tryexponent.com/how-to-prepare-for-an-engineeri...

eatonphil• 5 years ago

I would not recommend anyone An Elegant Puzzle. No disrespect to the author's writing ability and no discredit to his experience. I thought the book had no flow (it was a curated collection of his blog posts, or something like that). He described in detail the decisions he made or things he learned but since he didn't explain any context about the company at the time I could not figure out how any of it was relevant to me. And I've worked everywhere in companies of varying size between F500 and Series A.

I do agree The Manager's Path is a good one though.

Some other favorites are High Output Management by Andy Grove, Managing Transitions by William Bridges, The Toyota Production System by Taiichi Ohno, Measure What Matters by John Doerr, Peopleware by Tom DeMarco, The Innovator's Dilemma, etc.

Fire-Dragon-DoL• 5 years ago

I read team topologies and found some of the information highly inaccurate. Even the idea of recommending that the shape of your team shapes the architecture of your software seems suggest an extremely low discipline and foresight of business needs

emailslacked• 5 years ago

The fallacy of all these books, advice, philosophical quotes, so called knowledge about people is that, it’s too bookish and often advice is impractical to implement.

I have been EM for 5+ years now. There are number of factors on which I have zero control. M1 and M2 are doing often have no power besides sprint, agile processes. For whatever reason people are inherently unhappy. I have seen this happening in 3 different companies.

Compensation is major factor in unhappiness. But, lately it’s also the work that makes people unhappy. No one likes to do Oncall or operational or migration work or deal with mess left by earlier group.

Almost every single engineer think that they know better. I see large disagreements and often grunting agreements. You can apply advice like this all day long , but if compensation and work items are not satisfying, team will be unhappy.

Now, don’t get me even started on the hiring. It’s bizarre practice of leetcode, every tom,dick,Harry copying large organization processes like Amazon and Google.

I am actually quite frustrated in my manager career as someone who is not new the management. I am thinking if director and above level roles are more IC type but have better control over their career. Middle management is powerless in almost every aspect as far as I can tell. Please advice if you know how to get better.

ferryman• 5 years ago

I think the work factor is addressable to some extent. For example - my team was unhappy about working on a legacy , monolithic codebase so we pushed for rewriting it , convinced the leaders about the benefits and now are spending significant time on it.

molsongolden• 5 years ago

Some people are inherently unhappy but also keep an eye out for unhappiness caused by misalignment, misunderstanding, or disengagement relating to feelings of disempowerment.

Compensation is important up to a point but nobody likes feeling like they are wasting their time and powerless to make positive change.

No one likes to do Oncall or operational or migration work or deal with mess left by earlier group.

No one likes doing these things if they don't see the point, if there's no buy-in and the work is just a directive from above, if everybody feels like they are treading water and not making any progress, etc...

There are too many possible contributing factors to list them all but most solutions involve listening, communicating, and making small changes that compound over time.

Build teams that: make progress, understand why their work is important, have meaningful feedback loops.

Some good starting points:

[1] The Management Flywheel - https://skamille.medium.com/the-management-flywheel-c076f398...

[2] Work is Work (In which returns diminish) - https://codahale.com/work-is-work/

[3] Model, document and share - https://lethain.com/model-document-share/

[4] Why limiting work-in-progress works - https://lethain.com/limiting-wip/

packetlost• 5 years ago

To kind of expand on this, I actually like doing on-call and operational work. I find it very engaging and rewarding in the right context. The last company I was at, lower management had so little power, and the company was so unwilling to move anywhere (fairly old ISP) that it resulted in nearly all of the senior developers being either frustrated or jaded. It was a really toxic environment.

acjohnson55• 5 years ago

This is a nice compilation of resources on methodology, but a new EM could be misled by thinking this has much to do with managing people or leading.

dang• 5 years ago

Lists don't make great HN submissions because there's little to discuss other than the lowest common denominator of the items of the list items, and that's too generic: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...

It's also too much indirection since HN is already a list of articles: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

It's better to post the most interesting specific item from the list.

flakiness• 5 years ago

It's funny to see the books section covering EM-like books while other parts covering PM-like books. These are getting so disentangled these days that reading ones in the books section won't help understanding PM-like concepts, and vise versa.

Engineering Management

Related Stories