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!
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.
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
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...
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.
[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.
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.
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.
- 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.
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
- 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)
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.
Software Project Survival Guide - for software specific issues. (Don't be discourged by all the documents it discusses.)
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.
https://stackoverflow.blog/2022/02/23/what-you-give-up-when-...
- The Mythical Man Month
- High Output 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.