Engineering Management

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.

- “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”.

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

+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...

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.

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

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.

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/

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!

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.

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.

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...

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.

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.

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.

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.

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!

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.

What would nontechnical engineering be?

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.

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.