Reading leadership books is nice, but you’ll learn 10X more by reading books written by actual Engineering Managers - who have been in your shoes.
I also wrote a list of the 10 must-read leadership books, written by non-EMs.
In the last 5 years, I’ve read every such book I could find. Here are the 7 must-reads:
Become an Effective Software Engineering Manager
Peopleware: Productive Projects and Teams
An Elegant Puzzle: Systems of Engineering Management
The Art of Leadership: Small Things, Done Well
The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change
Leading Snowflakes: The New Engineering Manager's Handbook
Extreme Programming Explained: Embrace Change
For each book, I’ll share a key lesson, and which audience it fits best. The article became quit long, so I cut ~50% of it. Check out the full article for more insights from each book.
Most of the article consists of direct quotes from the books, with some minor changes.
1. Become an Effective Software Engineering Manager
By , 2020, 4.4 on goodreads.
Ideal audience: first-level Engineering Managers.
My favorite author on Engineering Management - covers EVERYTHING you need to know as a fresh EM. If you have to read one book, get this one. Stanier is still in the trenches, and he writes The Engineering Manager.
Here’s my favorite lesson:
The Zone of Proximal Development
The area where an engineer cannot progress without someone with a higher skill level to assist them. Once the task is understood and completed, they can take on more difficult tasks, expanding their zone of proximal development.
In classic computer RPGs, a character gains experience, levels up, and earns skill points to improve at specific actions. These skills are often arranged in a tree, where each achievement unlocks the next, building the character's skill set.
In one-on-ones, your staff will share their career desires - perhaps to be a CTO or rearchitect search infrastructure at Google.
As their manager, you can help them place these goals at the bottom of their skill tree and plan milestones to push their zone of proximal development further and further.
2. Peopleware
By Tom DeMarco and Timothy Lister, 1987, 4.1 on goodreads.
Ideal audience: Experienced hands-on EMs.
Almost 40 years have passed, and this book is still super relevant! Tons of golden nuggets on leading great engineering teams and successful projects. Best read when you have some experience.
Demarco and Lister coined the term ‘Jelled Team’, which is basically a dream team - and a big chunk of the book is on how to improve the odds it’ll happen to YOUR team.
Signs of a jelled team
A group of people so strongly knit that the whole is greater than the sum of the parts. A few very characteristic signs indicate that a jelled team has occurred:
There is a sense of eliteness, team members feel they’re part of something unique. They have a cocky, SWAT Team attitude that may be faintly annoying to people who aren’t part of the group.
There is low turnover during projects and in the middle of well-defined tasks. The team members aren’t going anywhere till the work is done.
The final sign of a jelled team is the obvious enjoyment that people take in their work. Jelled teams just feel healthy. The interactions are easy and confident and warm.
You can’t make teams jell. You can hope they will jell; you can cross your fingers; you can act to improve the odds of jelling—but you can’t make it happen. The process is much too fragile to be controlled.
3. Leading Snowflakes
By Oren Ellenbogen, 2013, 3.9 on goodreads
Ideal audience: newly promoted EMs.
In his short-no-nonsense book (~100 pages), Ellenbogen covers the 9 main lessons he learned along the way from developer to SVP of engineering. He’s focused on helping newly-promoted managers.
Here’s my favorite lesson:
Optimize for business learning
It’s our job to protect the team from investing in the wrong places. While we might feel it’s the CEO’s or Product Team’s responsibility, it’s our job to make these trade-offs visible. We can’t just bury our heads in the code, hoping things will be fine.
Technical Debt is less scary than going out of business - optimizing code or scaling components that may not be used is avoiding the issue.
I like using the Pirate Metrics (AARRR) framework:
Acquisition – Bring more users to the app.
Activation – Ensure users enjoy their first experience.
Retention – Increase repeat visits.
Referral – Get users to bring friends.
Revenue – Monetize users.
If retention is low and users aren’t coming back, we shouldn’t spend on acquiring more users yet.
If activation is poor and few complete the task that represents our value, improving retention would be a waste.
I wrote a dedicated article on the book, where I covered 4 additional lessons (and Oren shared the 2 missing parts he would have added to a 2nd edition):
Switching between “Maker” and “Manager” modes
“Code Review”ing Your Management Decisions
Confronting and challenging your teammates
Building trust with other teams in the organization
4. An Elegant Puzzle
By Will Larson, 2019, 4.1 on goodreads.
Ideal audience: experienced managers (but valuable for beginner EMs too!).
Will Larson is my second most favorite Engineering Management author (after Stanier). He is a CTO at Carta, and writes the Irrational Exuberance blog. His current focus is on more senior leadership/technical strategy, but his earlier works for EMs are amazing.
Here’s my favorite part:
5 Ways engineering managers get stuck
Only manage down. This often manifests in building something your team wants to build, but which the company and your customers aren’t interested in.
Only manage up. Some managers focus so much on following their management’s wishes that their team evaporates beneath them.
Never manage up. Your team’s success and recognition depend significantly on your relationship with your management chain. It’s common for excellent work to go unnoticed because it was never shared upward.
Don’t spend time building relationships. Your team’s impact depends largely on doing something that other teams or customers want, and getting it shipped out the door. This is extraordinarily hard without a supportive social network within the company.
Define their role too narrowly. Effective managers tend to become the glue in their team, filling any gaps. Sometimes that means doing things you don’t really want to do, in order to set a good example.
I wrote a dedicated article about that part from the book, where I dove deeper into each mistake and also covered 5 additional ones:
Forgetting your manager is a human being
Neglecting Personal Development
Ignoring destructive behaviors
Trying to please everyone
Fighting too hard for your principles
5. The Manager's Path
By Camille Fournier, 2017, 4.3 on goodreads.
Ideal audience: early-career managers (and developers who consider that role).
The most well-known book on the list, it covers all software engineering roles - from developer to tech lead, EM, CTO, and VP of R&D - and provides valuable insights from Fournier on excelling in each role. It offers more breadth but less depth.
Here’s one insight I loved:
You should demand to be managed
3 key lessons on how to be managed:
Expect regular one-on-ones, ask for them if needed. Prepare an agenda, and guide your manager to where you need her most.
Give your manager a break. The manager's job is not to make you happy all the time, but to do what's best for the company and the team. Your relationship with your boss is like any other relationship - the only person you can really change is yourself.
This said, choose your manager wisely when switching jobs. He may have a huge effect on your career. As often said - people leave managers, not jobs.
6. The Art of Leadership: Small Things, Done Well
By , 2020, 4.2 on goodreads.
Ideal audience: all levels.
Lopp is currently a Senior Director of Engineering at Apple, previously VP of Engineering at Slack. He writes the popular Rands in Repose, and manages the biggest engineering leadership community in Slack (30k+), which I really love.
The book is a collection of his best essays, so it’s a bit all over the place, but his writing is the most fun to read. The chapters are divided into 3 parts:
His time as Manager at Netscape
Director at Apple (in his first stint there)
Executive at Slack
Here’s a part I loved, about why you should delegate until it hurts. It’s written about a director managing an EM, but the same lesson applies for engineers!
Delegate Until It Hurts
Your VP gives you a new project. It’s work you’ve done many times. It’d be a slam-dunk if you were solo, but you’re a director, so you hand it to your manager, Julie.
In your 1:1 with Julie, you explain the project—what winning looks like, resourcing, and scheduling. Julie has never done this before, so she asks many questions. You answer fully, and she scribbles down notes, learning. Thirty days into the 90-day project, you hear concerns from the team. You mention discussing it in your next 1:1.
Julie comes prepared. She’s heard the worries and has ideas, but they’re wrong. This is fine. She’s never done it. You discuss a new direction, and she adjusts, asking questions. As the project winds down, the final product is a B. It works, but will need a month of unplanned work before the next release. It’s a B. A voice in your head says, “If it had been me, it’d be an A.”
Shush, little voice. Here’s why a B is credible leadership.
First, Julie knew this would stretch her and the team. You showed trust by giving them the project, even though it was beyond their means.
Second, when things got bumpy, you didn’t overreact. You sought understanding and coached them through it. More trust.
Third, you learned how not to micromanage. You gave initial guidance, answered questions, and let them run with it. When it went sideways, you coached, not punished.
Fourth, they did it. The project is done, and they gained valuable experience. How did you do on your first attempt? I likely messed it up in ways you can’t imagine. But in this situation, you’ve increased the odds that the next project by this team and leader has a better chance of being an A.
Delegating familiar work to another is a clear vote of confidence, forming trust within a team. Letting go of the hands-on work is tricky but essential. As a leader, you build yourself by building others.
7. Extreme Programming Explained
by and Cynthia Andres, 1999, 4.1 on goodreads.
Ideal audience: technical leaders (both managers and ICs).
Extreme programming is “a software development methodology that organizes people to produce higher-quality software more productively”.
In the book, Beck (one of the authors of the Agile Manifesto) presents the values, principles, and practices of XP. Why do we need all 3 types?
Values and practices are an ocean apart. Values are universal. Ideally, my values as I work are exactly the same as my values in the rest of my life. Practices, however, are intensely situated.
Bridging the gap between values and practices are principles. Principles are domain-specific guidelines for life.
It was written 25 years ago, and 95% of it is still relevant (and unfortunately, rarely implemented in companies).
Today, I will cover my 5 favorite principles and 5 favorite practices (semi-quoted from the book, Beck’s voice).
The 5 values
Communication
Simplicity
Feedback
Courage
Respect
5/14 Principles
Failure - I coached a team that had several good designers, so good that each of them could come up with two or three ways of solving any given problem. They didn’t want to waste programming time, though, so they wasted talking time instead. Fail instead of talk.
Economics - Make sure what you are doing has business value, meets business goals, and serves business needs.
Mutual Benefit Every activity should benefit all concerned. Extensive internal documentation of software is an example of a practice that violates mutual benefit (you need to suffer for the future person)
Quality - Sacrificing quality is not effective as a means of control. Projects don’t go faster by accepting lower quality. Quality isn’t a purely economic factor. People need to do work they are proud of. XP chooses scope as the primary means of planning, tracking, and steering projects.
Accepted Responsibility Responsibility cannot be assigned, it can only be accepted. The practices reflect accepted responsibility by, for example, suggesting that whoever signs up to do work also estimates it.
5/24 practices
Team Continuity - Keep effective teams together. Value in software is created not just by what people know and do but also by their relationships and what they accomplish together.
Whole Team - Include on the team people with all the skills and perspectives necessary for the project to succeed.
Informative Workspace - An interested observer should be able to walk into the team space and get a general idea of how the project is going in fifteen seconds.
Incremental Design - Invest in the design of the system every day, not just once before starting.
Real Customer Involvement - Make people whose lives and business are affected by your system part of the team. No customer at all, or a “proxy” for a real customer, leads to waste as you develop features that aren’t used.
What I enjoyed reading this week
My Path Into Tech: What Worked, What Sucked, What Stuck - a great article by , about her journey from a science PhD to a software engineer.
How to use Cursor AI to build side projects by , and . Very interesting and relatable (manager.dev was built fully with cursor!).
Return-to-Office mandates are more about strutting than strategy by .
LLMs: an operator's view by (who’s still in the trenches with us 🙃)
