Leadership, People & Teams
The most expensive skill in software is leading the people who build it, not building the software. These books shaped how I think about leading engineers: building psychologically safe teams, giving feedback that lands, designing organizations that ship, and growing into senior technical leadership without losing the craft. Whether you are a lead, a manager, a director, or a senior engineer who has just realized the problem is no longer technical, this is where I would start.
Heavily weighted toward books about people, which age slower than books about systems.
Lead Engineer | MBA Candidate | M.Sc. Software Engineering & Ubicomp
Peopleware: Productive Projects and Teams (3rd Edition)
If I could put one book in the hands of every engineering manager and senior engineer in the industry, it would be this one.
DeMarco and Lister argue, with thirty-plus years of data and field experience, that the major problems in software work are sociological, not technical. The most expensive thing in a software team is the cost of disrupted attention, mishandled people, and offices designed for visibility rather than thought. Most of what we still get wrong in 2026 is documented in this book from the 1980s.
Read it once for the ideas, then keep a copy on your desk to push back with the next time someone proposes open-plan offices, fungible “resources”, or back-to-back meetings as a productivity strategy. It is the conscience of engineering management.
Radical Candor: Fully Revised & Updated Edition
Most managers fail at feedback in one of two directions. Some are nice but unhelpful, soft-pedalling the things their people most need to hear. Others are blunt to the point of being cruel, mistaking aggression for honesty. Kim Scott’s framework, care personally and challenge directly, names the third path and gives it a vocabulary.
The book is full of examples from Scott’s career at Google and Apple, including the famous moment Sheryl Sandberg told her she was about to derail her career by saying “um” too much. The lesson lands because Sandberg cared first, then was direct.
If you are growing into giving harder feedback, or if you have ever come out of a 1:1 wishing you had said the real thing, this is the book.
Turn the Ship Around!
The author, David Marquet, was given command of the worst-performing submarine in the U.S. Navy and turned it into the best-performing one. He did it by inverting the command-and-control model that the Navy is famous for: pushing authority down to where the information already lived, rather than pulling information up to where the authority lived.
The mechanism, “I intend to…” instead of waiting for orders, is deceptively simple and applies almost word for word to engineering teams. If your seniors are bottlenecked waiting for your sign-off, or if your team escalates decisions that they have all the context to make themselves, the playbook is here.
A short book, written like a memoir, full of stories you will quote at work.
The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth
Amy Edmondson’s research on psychological safety is the empirical backbone behind every modern conversation on high-performing teams. Google’s Project Aristotle pointed at her work. Accelerate cites it. Most of the leadership books on this page assume it.
This is the source. Edmondson defines psychological safety precisely, separates it from being “nice”, and shows with case studies (hospitals, Wells Fargo, Volkswagen, Pixar) what the absence of it costs. The most useful chapter explains how to actually build it as a leader, which is harder than declaring an open-door policy.
If your team is quiet in retros, hesitant to admit mistakes, or surprised by problems they should have raised weeks earlier, the diagnosis is in this book.
Managing Humans: More Biting and Humorous Tales of a Software Engineering Manager
This book is perhaps one of the most impactful birthday gifts I’ve ever received. I might not be a people manager (at least at this point in time) but making technical decisions for teams requires a fair share of human interaction which is, ehm, hard.
Michael Lopp has a rich management background in companies like Apple, Pinterest, Palantir, Netscape, Symantec, Borland and Slack, and has distilled his experience in humorous and sometimes unexpected stories.
To my surprise, many of the stories felt more familiar than I’d like to admit. I got hooked and finished the book in about two weeks during my daily commute. About half a year later I got promoted, and I strongly believe that the book was instrumental to achieving that.
The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition)
Technologies may change, but people don’t. This book is legendary. Some of the essays are dated, but others have stood the test of time and prove that some management problems have been solved decades ago and we still don’t want to listen.
When I find myself in an job interview on either side of the table I usually ask the other person about this particular book. Whether they have read it or not, it’s a great source of discussion points on managing software engineering projects and gives me valuable indications of what I should expect when working with that person.
The Five Dysfunctions of a Team: A Leadership Fable
Patrick Lencioni’s leadership fable about a Silicon Valley executive team that cannot get out of its own way. It is a short novel, the kind of book you can finish on a single flight, but the model it leaves you with stays for years.
The five dysfunctions stack: absence of trust feeds fear of conflict, which feeds lack of commitment, which feeds avoidance of accountability, which feeds inattention to results. Each layer reinforces the next, and you cannot skip a layer to fix the team.
Read it before your next offsite. Engineering leadership teams, in particular, tend to live at “lack of commitment” and “avoidance of accountability” and assume the problem is roadmap clarity. It is rarely roadmap clarity.
Multipliers: How the Best Leaders Make Everyone Smarter
Some leaders multiply the intelligence and capability of the people around them. Others, often without realizing it, do the opposite: they make everyone around them dumber, slower, and less confident. Liz Wiseman’s research surveyed 150 leaders and identified the small behavioral differences that explain the gap.
The painful chapter is the one on “accidental diminishers”: well-meaning, competent leaders who diminish their teams because they jump in with the answer, rescue people too quickly, or talk over thinking time. Most senior engineers who get promoted into leadership are accidental diminishers, because the habits that made them effective as individual contributors are exactly the wrong habits for multiplying others.
This is the book to read when you find yourself doing more work than your team and wondering why.
Drive: The Surprising Truth About What Motivates Us
Daniel Pink’s synthesis of decades of motivation research, distilled into three words: autonomy, mastery, purpose. Carrot-and-stick management works well for narrow, mechanical tasks and works poorly, sometimes counterproductively, for anything creative, including software work.
The book is short on field-tested management advice and long on the underlying research, which is why it is on this list. If you understand why extrinsic incentives misfire for engineers, you will design your performance system, your bonus structure, and your team rituals very differently.
Pair it with [[thefearlessorg]] and [[fivedysfunctions]] for a complete picture of what makes engineering teams want to do their best work.
Crucial Conversations: Tools for Talking When Stakes Are High, Third Edition
The conversations that matter most in your career are the ones you most want to avoid: telling a senior engineer their work is not good enough, pushing back on a director’s plan, raising an interpersonal issue with a peer, telling your manager you are leaving.
This book is a practical toolkit for those moments. The authors break down what high-stakes conversations have in common, why they go wrong (we go silent or we go violent), and the techniques to stay in the productive middle. Plenty of dialogue examples. Some of the frameworks, “make it safe”, “start with heart”, “state my path”, will become vocabulary you use in 1:1s.
Less elegant prose than [[radicalcandor]], but more practical when you actually have to walk into the room.
High Output Management
Andy Grove was a chemical engineer who became the CEO of Intel during the period it defined the modern semiconductor industry. This book, written in 1983 and revised in 1995, is what he taught his managers.
It is the most concrete management book on this list. Grove treats management as a craft with measurable output: a manager’s output is the output of their team, plus the output of teams influenced by them. From that one idea he derives 1:1s, performance reviews, planning rhythms, decision-making frameworks, all with the precision of an engineer.
Every modern tech management practice you have encountered, from OKRs to weekly 1:1s, has its roots either in this book or in the people Grove trained. Read it once a year.
The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change
Camille Fournier walks the reader through every step of the engineering management ladder, from mentoring an intern to managing managers to running an organization. Each chapter is structured around the question “what does this role actually look like day to day”, which is exactly the question most engineers have when they first consider the management track.
What makes the book unusually useful is its respect for the difficulty of each transition. Going from senior engineer to tech lead is not the same skill upgrade as going from tech lead to manager, which is not the same as going from manager to director. Fournier explains the new failure modes at each step and what to do about them.
If you are considering the engineering management track, or you have just been thrown into it, start here.
Staff Engineer: Leadership Beyond the Management Track
For most of tech history, the only way to grow as an engineer past the senior level was to become a manager. The staff engineer track changed that, and Will Larson’s book is the canonical guide.
The first half is Larson’s own framework: the different archetypes of staff engineer (tech lead, architect, solver, right hand), the work that gets you there, and how to operate once you arrive. The second half is interviews with staff and principal engineers at companies like Stripe, Slack, Squarespace, and others, which makes the abstract concrete.
Pair with [[managerspath]] for the management ladder. Together they cover the two directions an ambitious senior engineer can grow.
An Elegant Puzzle: Systems of Engineering Management
Will Larson’s first book is a collection of essays on the problems engineering managers actually run into: how to size teams, how to handle on-call, how to migrate large codebases, how to grow people, how to design career ladders, how to interview, how to write documents that make decisions instead of describing them.
It reads like the wisdom of a senior peer who has been doing the job for a decade and is willing to share the patterns that worked. Larson has been an engineering leader at Stripe, Calm, Digg, and Uber, and the essays are grounded in real situations, not abstract advice.
I return to this book most often when I am about to make an organizational change and want a sanity check. Pair with [[staffengineer]] and [[executiveprimer]] for Larson’s complete arc on engineering leadership.
Resilient Management
A short, tightly written book about managing engineering teams through the hard parts: layoffs, performance issues, conflict between team members, your own energy as a leader.
Lara Hogan was an engineering director at Etsy and Kickstarter before becoming a coach, and her writing is practical to the point of being almost utilitarian. Frameworks like “Manager Voltron”, “BICEPS” (the core human needs your team is unconsciously protecting), and her one-on-one templates have become widely used in tech management.
A book you can finish in an afternoon and reference for years. Particularly useful for managers in their first or second year, when the gap between knowing you should give feedback and actually doing it is widest.
The Engineering Executive's Primer: Impactful Technical Leadership
Will Larson’s third book, written for engineers stepping into executive roles (Head of Engineering, VP, CTO) for the first time. It covers the work that is invisible from the manager and director levels: navigating the executive team, working with the board, running a finance function, doing strategy that survives contact with reality.
I will be honest: this is the least page-turning of Larson’s three books. The work it describes is genuinely less narratively exciting than the work of [[elegantpuzzle]] or [[staffengineer]]. But if you are about to take an executive engineering role, or you report to someone who has, this is the only book I know of that maps the territory plainly.
Read it like a reference manual rather than cover to cover. The strategy and finance chapters in particular are worth their own re-reads.
Debugging Teams: Better Productivity through Collaboration
Brian Fitzpatrick and Ben Collins-Sussman, both long-tenured Google engineers, distill what they have learned about the human side of engineering teams. Their thesis: software engineering is a team sport, and almost every “engineering” problem you hit past a certain point is actually a people problem.
The acronym at the center of the book, HRT (Humility, Respect, Trust), is the kind of thing you would dismiss as soft if it were not backed by a long list of concrete failure modes: the engineer who builds in a cave for six months, the brilliant jerk who burns down a team, the manager who optimizes for visibility over impact, the team that mistakes agreement for alignment.
A spiritual companion to [[peopleware]], but written from the inside of modern tech rather than a 1980s consulting practice.
Never Split the Difference: Negotiating As If Your Life Depended On It
Chris Voss was the FBI’s lead international hostage negotiator for two decades. This is the book that came out of that career, and it is the best book on negotiation I have read.
The premise sounds dramatic but the techniques are useful in mundane settings: salary discussions, vendor contracts, scope negotiations with a stakeholder, hard conversations with your CFO about engineering headcount. Voss argues that traditional “split the difference” negotiation is lazy and leaves value on the table. His alternative, tactical empathy and calibrated questions, is more effective and, helpfully, less adversarial.
The chapter on “no” being the start of a negotiation rather than the end will change how you read every email you have ever sent. A surprisingly practical book for engineering leaders.
Dare to Lead: Brave Work. Tough Conversations. Whole Hearts.
Brené Brown’s research on vulnerability, courage, and shame, applied specifically to leadership. The premise is that the leaders who scale are the ones who can stay in hard conversations long enough for the real issue to surface, instead of armouring up and looking strong.
A lot of engineering culture rewards the opposite: certainty, sharp answers, never looking like you are figuring it out in real time. Brown argues that this trade-off costs you trust, costs you good engineers, and eventually costs you the ability to lead. The “rumble” framework for conversations and the “armoured leadership versus daring leadership” list are worth the price of the book.
Some readers find Brown’s voice and TED-talk-adjacent style not to their taste. If that is you, push through, the substance is real.
Win Every Argument: The Art of Debating, Persuading, and Public Speaking
Mehdi Hasan is a journalist known for being unusually difficult to debate on television, and this book is his teardown of how he does it. Part rhetorical history (the Greeks, Cicero, Frederick Douglass), part working manual on how to win an argument in real time.
For engineering leaders, the relevant chapters are the ones on structuring an argument, anticipating objections, and handling a hostile room. If you have ever walked out of an executive review feeling like the technical merits of your proposal were ignored, this book will give you a much better diagnosis than “they did not understand the architecture”.
A useful counterweight to the conflict-avoidant framing of [[crucialconversations]]. Sometimes the right move is not to find common ground. It is to make a clear case and let it stand.
Thinking in Systems: A Primer
Donella Meadows was one of the lead systems thinkers of the late 20th century, and this book, published posthumously, is her gift to the rest of us. It is the most accessible introduction to systems thinking I know of, and it is short.
For engineering leaders, the value is in the vocabulary. Once you can name stocks, flows, balancing loops, reinforcing loops, and leverage points, you start to see them everywhere: in your deployment pipeline, in your hiring funnel, in the way your incident-response process either improves or degrades over time. Meadows’ list of intervention points, ranked from “where almost everyone tries to intervene” to “where the actual leverage lives”, is the most useful 12-line table in the book.
Read this and you will stop fighting symptoms.
Thinking, Fast and Slow
Daniel Kahneman won a Nobel Prize for the work behind this book. It is the definitive popular synthesis of the cognitive biases that quietly shape how humans (including engineers and engineering leaders) make decisions.
The two-system framing, fast intuitive thinking versus slow deliberate thinking, is by now common vocabulary. What is less appreciated is how thoroughly System 1 runs your day: which engineers you think are talented, which architecture proposals feel right, which incidents feel preventable in retrospect. If you make decisions that affect other people’s careers and a company’s product, you need to know what your own brain is doing behind the scenes.
A long book, but you can read it in chunks. The chapters on availability bias, the planning fallacy, and “what you see is all there is” are essential for anyone running engineering planning.