HACKER Q&A
📣 DDerTyp

Books to read when you transform from SWE into SWE Management?


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!


  👤 strife25 Accepted Answer ✓
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.


👤 endymi0n
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


👤 Scarblac
Things I've saved from previous discussions:

HN Question "Advice for a new & inexperienced tech lead?": https://news.ycombinator.com/item?id=22255301

HN Question "Best book / resources on leadership, especially for tech teams?" https://news.ycombinator.com/item?id=21712194

HN Question "I want my tech lead's job" https://news.ycombinator.com/item?id=21369535

Useful comments on a leadership blog post link https://news.ycombinator.com/item?id=21376838


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


👤 brianmcc
I recommend "Managing Humans" by Michael Lopp aka "Rands".

https://randsinrepose.com/

It's a bit tongue in cheek rather than "management theory" but no less worthwhile for it.


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

👤 mooreds
Join the Rands Leadership Slack. Highly highly recommended: https://randsinrepose.com/welcome-to-rands-leadership-slack/

You can learn an awful lot by just browsing around, but they also have channels for questions, both with your name and anonymous.


👤 philk10
Becoming a Technical Leader - an Organic Problem-Solving Approach by Jerry Weinberg (https://geraldmweinberg.com/Site/Technical_Leader.html)

👤 ChrisMarshallNY
I'd say almost anything by Joel Spolsky[0]. Smart and Gets Things Done[1] was one that I enjoyed.

[0] https://www.joelonsoftware.com

[1] https://www.joelonsoftware.com/2007/06/05/smart-and-gets-thi...


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


👤 pan69
Peopleware: Productive Projects and Teams

https://en.wikipedia.org/wiki/Peopleware:_Productive_Project...


👤 mro_name
"Getting to Yes: Negotiating Agreement Without Giving In" by Roger Fisher and William Ury

https://en.wikipedia.org/wiki/Getting_to_Yes:_Negotiating_Ag...


👤 DanielBMarkham
I'll take a shot, assuming that you are asking how to manage a technology team, not how to understand technology at a wider scale. You need both tech leadership and end-to-end/shallow-deep abilities. But the tech side is a different question entirely. Looks like some other folks have provided answers so I won't go there. (The tech side is a lot to go into in a thread, and would include some kind of conversation figuring out where you are technically. "I'm a SWE" doesn't begin to cover it.)

Without any thought at all:

- One Minute Manager

- Debugging the development process

- The Culture Code

- The Five Dysfunctions of a Team

- Difficult Conversations

Take some negotiation and interviewing hands-on courses.


👤 flakyfilibuster
Lots of good recommendations in the thread.

I found this one to be pretty valuable: https://www.amazon.de/Difficult-Conversations-Discuss-What-M... (sorry, amazon link)

Because, obviously you're going to get into situation as a manager where you have to have difficult conversations.


👤 qiskit
If you are replacing a previous manager, you could ask him. He'd probably give you the best recommendation tailored specifically for your office/business domain/environment. In my experience, manager's/tech lead would recommend books. But a good habit in general is to proactively look at your manager's/tech lead's library if they have one in their office.

👤 intellectronica
- Power: Why Some People Have It and Others Don't by Jeffrey Pfeffer

- What Got You Here Won't Get You There: How Successful People Become Even More Successful by Marshall Goldsmith

These two books are not specifically on the topic of becoming an engineering manager but cover the important aspects of how to work effectively as a leader in organizations. Turns out that's very important too.



👤 NikolaNovak
The very first article from this book was the most "lightbulb" moment for me in my transition from technical SME to management:

https://store.hbr.org/product/hbr-s-10-must-reads-for-new-ma...

It's NOT IT related. But the key lessons on how our role changes, how our goals and methods should change, and which of our expectations/assumptions of leadership are catastrophically incorrect, I think is universal.

For example, if I may be so bold, you said "to transform into a leader role which focuses on DevOps, Tests, QA, Documentation and related topics". NOWHERE in there you mention people ... and that's the #1 problem those of us coming from technical to leadership make :). We think "now we'll have the power to fix all those stupid technical deficiencies", rather than "Now I'm responsible for making sure team is motivated, inspired, working well, and they are in line with company's (and client's) goals and requirements".

It's the one 12-pager I recommend to all people who are becoming or relatively new managers (I read it after about 12 months in management; on one hand I wish I read it day 1; on the other hand, I'm not sure if I would've believed / embraced it as much until I lived it. Your mileage may vary).

Edit: For what it's worth; I did NOT believe or embrace this the first couple of years, but there is no upper limit to training, practice, and enhancing our emotional intelligence skills. It's harder than technical skills, not the least because as techies we may not see its value immediately, and it's a lot less clear cut of a topic. But learning how to understand, get along with, and inspire/motivate/coach/lead your fellow human beings, is a life long study.


👤 nonrandomstring
Going from SE toward SEM I'd suggest you get into s/w metrics. Nothing is better for decision making and advancing good arguments at meetings than being able to give numbers.

- Fenton: Software Metrics

Obviously there's a ton of pop management stuff. A few of my favourites:

- Horowtz: The Hard Thing About Hard Things

- Pink: Drive

- Evans: The Trousers of Reality

- Gall: General Systemantics


👤 jll29
* read (all or at least the top 3):

- Death March

- Peopleware: Productive Projects and Teams

- The Mythical Man Month

- Growing Software: Proven Strategies for Managing Software Engineers

- Managing Humans: Biting and Humorous Tales of a Software Engineering Manager

* consider getting PMI certified (PMP): https://www.theknowledgeacademy.com/de/offers/pmi-certificat...

- technical tools for planning

- stakeholder communication

* follow your gut (if you are a developer you will know how they want to be treated)


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

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


👤 Zaheer
The Manager's Handbook is a great free online resource (by the founder of Clearbit): https://themanagershandbook.com/

👤 robin_reala
You should definitely subscribe to Charity Major’s blog. Every post gets a “oh, of course” from me. https://charity.wtf/

👤 fallmonkey
I'd recommend Julie Zhuo's The Making of a Manager. She's got a twitter https://twitter.com/joulee where you could check out her sharing of managerial wisdom to have your own gauge.

This book focuses on the practical side like sharing useful feedback, smart recruiting strategy and meeting optimization, all towards the goal of greater outcome and amplifying team success, instead of just more activities entailed by conventional manager model.


👤 kaycebasques
Regarding documentation, check out Docs for Developers by Bhatti et al. The subtitle describes the book as "an engineer's field guide to technical writing" and that's exactly what the book is. It provides you a detailed step-by-step overview of what high-quality documentation process and output looks like. I've been a technical writer for 9+ years and can vouch that anyone following the blueprints laid out in that book will probably end up with significantly better docs.

👤 tsm
An Elegant Puzzle by Will Larson: https://press.stripe.com/an-elegant-puzzle

👤 unculture
The Manager’s Path by Camille Fournier

👤 goodgoblin
There are kind of two main axes you can impact

1. The Devs

2. The Org

For The Devs

With regard to the developers you need to make sure they have what they need to succeed, and to help them grow.

For this "Peopleware" is great - it helps understand the "servant leader" mindshift

For The Org

With regard to the organization, your main job will be making sure the organization doesn't make classic mistakes.

Mythical Man Month is great for this. Another great resource is the "Classic Mistakes" section from McConnell's book Rapid Development.

If you google that you can find a PDF for it.


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

👤 gashmol
High Output Management - for general management issues.

Software Project Survival Guide - for software specific issues. (Don't be discourged by all the documents it discusses.)


👤 cnj
One book I haven't seen mentioned so far is Elastic Leadership - https://www.elasticleadership.com/

I like that it's quite hands-on, and that it also explicitly focuses on HOW to get teams out of a bad state.

If your team is doing perfectly fine right now, it may not be the best book to pick up, but when things spiral downwards, I can highly recommend it.


👤 salawat
Handbook of Total Quality Management.

Demings, Jaran, Ishikawa, Crosby, Taguchi

Divest yourself of the impression that Quality is just about Testing. It's a long uphill fight.

Godspeed friend, and stay sane.


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

👤 silent1mezzo
The First 90 Days by Michael Watkins is an amazing book for anyone getting into management and then again whenever you move roles/companies.

👤 colemanron
I'd recommend you check out the Level-up Engineering podcast. They cover engineering management topics with a large library of content out already, and it keeps going strong. https://codingsans.com/engineering-management-podcast

👤 wiz21c
The Prince by Machiavel.

👤 max23_
Just read this recently from SO blog, hopefully it is helpful:

https://stackoverflow.blog/2022/02/23/what-you-give-up-when-...


👤 rg111
- Peopleware

- The Mythical Man Month

- High Output Management


👤 jrs235
Debugging Teams: Better Productivity through Collaboration http://amzn.to/2FQb9xx (affiliate link)

👤 casralad
Software Engineering at Google [https://abseil.io/resources/swe-book]

👤 ep103
The Culture Code was the most impactful book I read when I first made this transition, particularly since I was coming from smaller, more unstable companies at the time

👤 mr90210


👤 brobinson
Leadership Strategy and Tactics: Field Manual

👤 adastra22
The usual suspects: The Mythical Man-Month by Fred Brooks. Management by Peter Drucker.

👤 twox2
"The Phoenix Project"

👤 maksa
Gerald M. Weinberg books. Just get them all. QSM 1-4 for start.

👤 kqr
If you read nothing else, read Edwards Deming. He clearly outlines what the management philosophy of modern creative jobs must be like:

- Focus on what matters.

- An organisation needs an aim, a meaningful goal, that's not just "do what we have always done except better".

- Don't invest in shiny things because they are shiny – investments basically cost you the interest rate on a loan, rain or shine, even on Sundays.

- You can't inspect quality into a product or process.

- When your inspectors fix minor quality problems themselves instead of rejecting the product, the upstream process learns that minor quality problems are acceptable.

- Quality starts at the upstream process – this applies also to the upstream process.

- Making and then fixing quality problems can be a huge part of an organisations expenses, but of course there's no line item on the books for "mistakes", so that huge cost gets absorbed as the cost of doing business.

- The organisation hierarchy doesn't matter – how the work flows between people is what matters.

- Management by numeric goals results in cheating, information hiding, and bad decisions to meet the quota at any cost.

- Management by results ends up wasting a lot of effort trying to correct for statistical noise.

- To improve outcomes, you must improve the process.

- Don't compare yourself to arbitrary goals – estimate what the current process costs you and what you could earn with an improved process, then find out if that's worth the investment.

- To get a sense of the process, use statistical process control charts.

- Unless there's something truly extraordinary going on, don't judge individuals for their performance.

- Individual performance is almost always random noise compared to team performance.

- Judge team performance, and reward fairly based on that.

- In the rare case where individual performance is consistently beating team performance and you have statistical evidence of this, see it as a learning opportunity: if the rest of the team did what this person did, its performance would be insanely improved – find out what that is.

- Team performance is the outcome of manager performance.

- The point is not to be right, but to be learning.

- Humans have a right to take joy and pride in their work, free from fear of grading or ranking.

- When optimising an organisation, parts of the organisation might have to operate at a loss – trying to operate every part of an organisation at profit easily deoptimises the organisation.

- Avoid unnecessary paperwork or approval procedures, rely instead on statistics and sampling to ensure the system is stable.

- Well, technically, if inspection is really, really cheap (which it rarely is – consider also delay costs!) or mistakes really, really expensive (which they sometimes are, like for code that hits production), 100 % inspection makes sense.

- Putting out fires or fixing problems with clear, assignable causes is not process improvement – it's simply putting the process back where it should have been to begin with.

- Help people understand the greater context: how is the product used, who uses it, what do they think, how is the company making money, and so on, and so on.

- Leaders should be skilled in the jobs of the people they lead.

- How do you know whether you're doing your job well? How does other people in your organisation know?

- Everyone thinks it's obvious what success or failure would look like, but when probed for details, it turns out no two persons have the same definition. Ensure everyone agrees on how a test for success is performed.

- If you find signal in the data, first verify the validity of the data. Look first for errors in measurement.

- Plan, Do, Check, Act. Use the Shewhart cycle to learn!

- Once a process is in statistical control, a sample drawn from that process gives you no information whatsoever that you didn't already have. A sample from a process in statistical control is by definition a random number to you.

As you can see, there's a very wide variety of important things one can learn from Deming. Everyone should do it.