Ask HN: Books to read when you transform from SWE into SWE Management?

314 points by DDerTyp ↗ HN
Hello HackerNews!

I started my SWE career in 2016. I'm in a team which develops an enterprise SaaS-Application. Now I got the opportunity to transform into a leader role which focuses on DevOps, Tests, QA, Documentation and related topics.

So far, we set goals and start to introduce the team (around 5 people) into that topic.

My question is - are there any good books, articles, podcasts, ... which can help me in this "challenge"? I already got some basic (practical) knowledge in leading people and managing a product.

Stay safe!

96 comments

[ 3.0 ms ] story [ 213 ms ] thread
The usual suspects: The Mythical Man-Month by Fred Brooks. Management by Peter Drucker.
Leadership Strategy and Tactics: Field Manual
Here's the single one resource I'm giving any of our new leaders, it's really short and the highest signal-to-noise ratio I've ever seen:

https://www.defmacro.org/2014/10/03/engman.html

I'm personally revisiting it every time I send it around, because it's just so good.

Here's another I've seen recently that goes into a bit of detail while not being quite as succinct:

https://news.ycombinator.com/item?id=30240428

EDIT: replaced second link with HN one as it contains an Emoji and broke due to policy

The "defmarco" blog post is gold. I appreciate that he put it a quick bullet format, rather than a long fleshed-out ebook.

Most of the rules actually applies across all types of roles and not just a engineering one.

Gonna print this one out and nailed it on my desk.

The Manager’s Path by Camille Fournier
- Peopleware

- The Mythical Man Month

- High Output Management

At my previous company I was the lead on a team that was tasked with taking projects that had gone off the rails a bit (or a lot...) and try to get them back on track. If you land a role managing a team with a project that's not going well (a common reason for management change) then the book I'd recommend most is "Catastrophe Disentanglement" by E. M. Bennatan. It's very insightful.
I’ve just made this transition myself! Congratulations! I have a very short list of reading recommendations here: https://www.cenizal.com/reading/

In addition to the blog links on that page, I found these books to be the most useful:

High Output Management, by Andy Grove. My number one recommendation for anyone interested in managing people, particularly engineers. This book presents methods and processes for helping individuals maximize their impact, while remaining grounded in reality and humanity.

Thanks for the Feedback, by Douglas Stone and Sheila Heen. This book gave me great insight into how I handle feedback and what I can do to make the most of it. It also helped me understand how others might take my feedback, and develop methods for sharing my feedback effectively.

The Manager's Path, by Camille Fournier. A pragmatic guide to the stages of technical leadership, from tech lead to CTO. A great read even for engineers with no interest in people management, because it provides a clear line-of-sight into what those folks care about and how they make decisions.

High Output Management always gets recommended. How did his management work out for Intel?
To quote Wikipedia:

> He was the third employee and eventual third CEO of Intel, transforming the company into the world's largest semiconductor company.

Looks like it worked pretty well.

Also from Wikipedia:

> He relinquished his CEO title in May 1998, [...] and remained chairman of the board until November 2004.

Care to guess when the decisions causing today's woes for Intel started happening?

He became CEO in 1987, when Intel's stock price was in the range of $0.10-0.20.

When he left the post of CEO in May 1998, Intel's stock price was ~$9.50.

A 10x return over a decade is pretty damn good.

> A 10x return over a decade is pretty damn good

I think it was 100x

Assuming your facts are correct, your math isn't. $0.10 -> $9.50 is a 95x return.
The Prince by Machiavel.
I don't remember the exact wording, but "if you're going to do many evil things, do all of them at once" really has shaped how I organize myself when I need to screw people.

Non ironically I think that's a great book for anyone working in a company.

If you go this route, read Anti-Machiavel at the same time, by Frederick the Great, a chapter by chapter rebuttal written just prior to him becoming King of Prussia.
There’s really only one thing you have to take away from ‘The Mythical Man Month’ and ‘Peopleware’ in my opinion (more people != more work), but they’re still valuable reads.
This.

DeMarco's Peopleware is a bit more hands on compared to the man month.

Man month is also pretty dated by now. There is some valid advice in the book still, but oftentimes it has to be 'translated' to the modern computing environment. Other things in it are just completely outdated.
I wouldn't recommend it as a starting point, but I learned a lot from The Mythical Man Month. It seems like every agile/scrum/kanban/lean book starts by arguing that the old ways of managing projects had problems. It was useful for me to read Brooks' deep dive into what, exactly, those old ways were. Some of the methods stand the test of time and others have not (e.g. not using too many comments in your code because of how much disk space they consume).
Another vote for Peopleware. It felt like it was written for a prior era, and that's when I read it in the early 2000s!

But then you realize that the fundamentals of being a good engineering manager are the same regardless of the technologies you're using and building.

One quick observation: you say that your new role focuses on Devops etc... That sounds like a tech lead to me. A manager focuses on their people, not a tech stack. One of the hardest parts of transitioning from an IC to a manager is letting go of control of technical decisions, and learning to trust your team. Of course you need to be able to set the general direction, but it's more about building a culture than it is about the exact implementation. If the team doesn't want to do devops, or testing, or write documentation, etc then it doesn't really matter which tech you choose. Getting people to work together and build consensus is the hard part.
As a military officer I agree that trust is a huge amount of effective leadership. It’s something that is immediately visible when visiting a different team.

So what do you do, as a software manager, if you don’t trust your team? Do you set higher technical standards? Do you invest in training? Do you hold responsible for failure to deliver a certain level of quality?

Depends on the diagnosis!

Two blog posts: [1] from Rands on skill vs will.

And [2], from Roy Rapoport on a five-step process for dealing with problems.

In both cases, it’s not enough to say you “don’t trust” your team. You have to do the work to diagnose WHY things aren’t working the way you want - do they see there’s a problem? Do they want to fix it? Do they have the skills?

Trying to fix a problem you can’t diagnose is going to be very hard.

[1] https://randsinrepose.com/archives/avoiding-the-fez/

[2] https://medium.com/@royrapoport/the-five-conditions-for-impr...

It's not really about the manager trusting the team, it's the other way around, gaining the trust of your reports. If you don't trust your team to achieve their goals, then yes you do have a problem and you can address that in all kinds of ways. But by default you should trust the team. On the other hand, you don't deserve your team's trust until you've earned it.

From the military side you might be familiar with Auftragstaktik [0]. Basically, you set the goal and a timeframe and let the team figure out how to achieve it. You have to connect their work to some kind of success metric. Otherwise you're just saying something like "we have to implement Devops", as a goal in itself, not connected to anything else.

[0] https://en.wikipedia.org/wiki/Mission-type_tactics

Second the recommendations for "an elegant puzzle" and "the manager's path".

Cant believe this one has not been mentioned yet: "Becoming an effective software engineering manager" by James Stanier (https://pragprog.com/titles/jsengman/become-an-effective-sof...) - a good book, and very specific for exactly your situation.

Would also like to mention my own podcast "Ask an engineering manager" - more focused on SWEs, but also has some episodes about how to be an Eng Mgr, e.g. https://askanengineeringmanager.libsyn.com/017-typical-mista...

Thanks for mentioning my book. Indeed, it's written exactly with that moment of time in mind: the "OK, so I want to do this. But how?"
I enjoyed an Elegant Puzzle but often felt it was targeted at a step above first time management, with topics on having interview pipelines, org design, etc. But it was still a good read.

His follow up book on Staff Engineering I think is a good read for first time managers. It lays out the other leadership path, which is helpful both for understanding where you fit in and the other leadership path you can guide your reports towards, based on their trajectory and interests.

I recommend you start an MBA program at night. There is no single book, there is no single topic, you need a broad range of new perspectives to be a truly effective manager.
Which MBA program covers engineering management specifically? I have a close friend who completed an MBA at Harvard and that program did not cover anything related to the type of people management engineering managers do. When my friend became a manager, had to learn all this on the go and from peers / managers and some of the resources linked in this thread.
Your friend must have been asleep, Harvard MBA 100% covers engineering management. If you mean how to manage in the specifics of a Scrum or Agile or TDD environment, yes, covered, but lightly. What is taught during an MBA tends to be more universal; there was a topic of "why is 'Six Sigma' not taught?" in my MBA program from the early 00's. Because Six Sigma is a product and constitutes a passing fad. And it's fad has passed, nobody cares about Six Sigma anymore. What is taught are the universal skills of good communication, material cultural sensitivity, group dynamics, and organizational behavior management, aka incentive design. What is not taught is the passing fads business culture consumes.
Everyone recommends The Manager's Path, but I don't think it's a good book to explain HOW to become a manager. The book's goal is to explain the career path of a manager from tech lead to CTO.

My #1 recommendation these days is "Become an Effective Software Engineering Manager" by Jamies Stanier. This book explains how to approach the work a manager is involved in and what you can expect from the day to day. Planning, hard conversations, performance reviews etc.

Also, look for general management books. Leadership is something all humans do – software management is about managing creative people. Some other books I recommend are:

• Creativity, Inc by Ed Matmull • Crucial Conversation • Team of Teams

For email newsletters, I recommend Software Lead Weekly (https://softwareleadweekly.com/) and Better Allies (https://betterallies.com/more-content/).

Lastly, I also write a blog called Build the Stage (https://www.buildthestage.com) about managing SWEs. I've got posts about performance reviews, team meetings, how to give feedback, etc. It'll help you out.

Stanier's book should be required reading for anyone becoming a people manager for the first time. I cannot recommend it enough and regularly give it to new or aspiring managers.
I second this. The Manager's Path is a terrible book.
What's wrong with it? I'm just gathering recommendations myself, and it'd help to know especially if there are more general red flags to watch out for.
The book is completely fine and worth the read! Just know that it's a book to explain the career path of an Engineering Manager in the tech industry.

My criticism is around how often the book is recommended. Many people want to learn HOW to become a manager. Manager's Path doesn't provide that.

Conversely, a lot of people recommend An Elegant Puzzle. Great book, but I would not recommend it to first time managers – it's too advanced.

Elegant Puzzle is for experienced managers, specifically people that are managing Managers. Check it out if you're 2+ years into their management career.

Yep, I really like sports related books too, such as Eleven Rings: The Soul of Success, and Leading: Learning from Life and My Years at Manchester United
Before answering, can you share what do you want to get out from your career? Some starter questions: Why do you want to get into software management? Do you want to get into software management in general, or for the particular company you working for? Is it a stepping stone to your goal, e.g. building your own product?

The books shared in other comments are all good, I personally vouch for the Mythical Man Month. I consider High Output Management a must read for management in general. The Elegant Puzzle is quite useful for team of certain scale, but I would say less useful for startup of a few engineers. Still useful, just less.