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.

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.

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

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.

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

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

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.

https://randsinrepose.com/

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

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

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

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.

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

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

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.

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

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.

I think it was 100x

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

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

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.

Was a really helpful and great book to help put in words some of the challenges I faced on a previous team (while I had an absent manager).

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

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.

Some examples: https://staysaasy.com/communication/2021/10/30/look.html https://staysaasy.com/management/2021/07/17/Less-Divisive.ht... https://staysaasy.com/management/2021/06/26/check-on-your-te...

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.

- 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

I strongly disagree with this.

While there is a fact/data side to being a manager, the key skill is understanding the human/soft side of it.

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

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?

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

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

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.

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.

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.

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.

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.

Most text/theory in Quality Management lit focuses on industrial/manufacturing incarnations and there are some (the most tiring people on the planet) who insist somehow Software engineering is fundamentally different than manufacturing; it isn't. That's a myth disproven time and time again. The book will walk you through how the work of Quality Management permeates all layers of any number of different business verticals.

I scored mine in paperback used for a steal. It was awesome.

Long story short, it isn't. It's just easier because material expenditure tends to be lower, but this is compensated for in higher communication overhead when interfacing between teams.

The reasin they aren't in print, is since, as the name suggests, it is a reference book, they generally do not fly off the shelves like hot cakes, and are the kinds of texts you reach out for when you've basically exhausted everything you have and still have no idea what it is you are missing, and damnit, someone had to run into something like this before.

Remember, publishers are profit driven, and the practitioners in a field, (nevermind the subset that actually take into account the historical theory in their field) is not a numerous bunch.

Even for 230, I'd have bought it just to have the theory in my hands in a form I find more conducive to reference than otherwise.

I'd also caution against scoffing at out of print literature. We lose reams of expertise and old nuggets if wisdom that when cross referenced with newer material actually help build up a profound understanding of a field. I've not gotten one book I regret buying in terms of professional brush up, and it does more than you think to proof you against the great hype BS cycle that tech is so rife with. I can't count the number of times I've caught domething in tge bud as abother manifestation of a path already tread.

But you do you. Your style and mind probably works different than mine.

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

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

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

- The Mythical Man Month

- High Output Management

The Goal, as written, is about manufacturing processes and a lot of people have trouble seeing past that domain when reading it. That is, they fail to generalize, or understand how to generalize, the ideas of Theory of Constraints. Critical Chain takes, essentially, the same Theory of Constraints and applies it to project management, versus production management. The Phoenix Project continues that sort of explicit extension by moving from general project management to IT systems management.

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