9 Things “Engineering Leadership: The Hard Parts” Gets Right That Most Leadership Books Get Wrong
A field guide for engineering managers who inherited a mess — or are about to.
Most engineering leadership books are written from the penthouse. They assume you have a functional team, a clear roadmap, and the luxury of applying frameworks methodically. Juan Pablo Buritica and James Stanier wrote this one from the trenches. They met in a breakfast group for startup engineering leaders — part networking, part therapy — where they kept noticing something strange: completely different companies, completely different people, completely different problems, all producing the same dysfunctional outcomes.
That observation became a decade-long investigation. Engineering Leadership: The Hard Parts is the result: a practical, deeply human guide to leading engineering teams when everything around you is on fire.
If you’re an engineering manager navigating ambiguity, chaos, or a team you inherited from someone else, this book is for you. Here are the most surprising, actionable, and honest takeaways.
1. Chaos Becomes Normal — and That’s the Real Danger
The book opens with a blunt warning: chaos doesn’t announce itself. It creeps in. The authors borrow the “boiling frog” metaphor — not because it’s scientifically accurate, but because it perfectly captures how dysfunction becomes invisible when you’re inside it.
The symptoms are recognizable once you know to look: unclear ownership, blame culture, constant crisis mode, no meaningful measurement, and high turnover. But here’s the counter-intuitive twist — leaders often don’t see these things clearly until they get promoted. A layer of management insulation can make a healthy team look fine from the outside, right up until you’re responsible for it.
The first act of leadership, then, isn’t fixing anything. It’s diagnosing accurately. You can’t navigate chaos you haven’t learned to see.
2. Your Job Isn’t What You Think It Is
Most people who step into engineering leadership think their job is “lead a team and ship great code.” The book quickly corrects this. Your actual job, in chaotic environments, is to be the glue — simultaneously a people leader, technical guide, strategist, product manager, firefighter, and occasionally, a therapist.
The authors frame this around five pillars: people, mission, plan, process, and product. Each pillar is a direct antidote to a specific symptom of chaos. Unclear ownership? That’s a people problem. Lack of direction? A mission problem. Constant fire-fighting? A process problem. The framework is simple, but the discipline of applying it when everything is urgent is anything but.
“Your team will mirror you. If you’re confused, they’ll be lost. If you’re clear, they’ll find clarity too.”
3. Leadership Range Beats Leadership Style
This is one of the book’s most original ideas. Most leadership advice tells you to develop a leadership style. Buritica and Stanier argue that what you actually need is range — the ability to shift your approach based on what the moment demands.
They call these shifts “switches,” and there are four: diagnosing context, thriving in chaos, focusing on outcomes, and shifting between roles (pilot, medic, or engineer). A burned-out team needs a different leader than a team racing toward a deadline. A startup crew under existential pressure needs different guidance than a scaled team optimizing for predictability.
The leaders who fail in chaos aren’t necessarily bad leaders — they’re leaders who found one thing that worked and kept doing it after the context had already changed.
4. Psychological Safety Is the Only Foundation That Matters
Before process, before roadmaps, before technical debt — you need people who feel safe enough to tell you the truth. The book references Google’s Project Aristotle study, which found that psychological safety was the single most important factor in team effectiveness. Not intelligence. Not tooling. Not tenure.
The authors illustrate this through a recurring fictional character, April, who joins a new team and immediately notices the signs of a psychologically unsafe environment: cameras off, short answers, nobody volunteering struggles, senior engineers saying “nothing we can’t handle” when everything is clearly on fire.
Her breakthrough comes not from authority but from vulnerability — sharing her own confusion about the codebase in a team meeting. The lesson is uncomfortable: you cannot drive change in a team that feels under threat. The first thing you have to do is lower the threat level.
5. Saying Yes to Everything Is the Same as Saying No to Everything
Chapter 5 is one of the book’s richest. When Juan led Stripe’s LATAM engineering team, the team was managing 30 competing priorities — each one urgent, each one “critical.” On paper, they looked productive. In practice, the wheels were spinning.
The breakthrough came not from more people or better process, but from clarity. In a virtual off-site during the 2020 pandemic, leadership put all 30 priorities on the table, had brutal conversations about trade-offs, and reduced them to six — two per team.
“From the outside, chaos looks like momentum. From the inside, it feels like drift.”
Drift is the silent killer of engineering teams. It doesn’t just waste effort — it erodes ambition. When engineers can’t see how their work connects to outcomes, they stop making bold technical decisions and start optimizing for getting through code review.
6. Process That Serves Itself Is Worse Than No Process
When it comes to shipping in chaotic environments, the authors make a case that will frustrate people who love methodology: elaborate processes often make things worse. Applying highly structured frameworks to a chaotic environment means you end up serving the process instead of driving the outcome.
Their alternative is lightweight, adaptable, execution-focused — built around four criteria: inspire confidence, be execution-focused, stay lightweight, and foster learning. The 80/20 rule applies: if a process works 80% of the time, it’s a success. Starting small and building only when needed consistently outperforms implementing the “correct” framework upfront.
The counterintuitive prescription here is to acknowledge uncertainty explicitly rather than pretend you have more clarity than you do. A 50% variance on an estimate, openly communicated, builds more trust than a “confident” estimate that’s wrong by 200%.
7. Budgeting Is an Engineering Skill, Not a Finance Problem
Most engineering leaders see budgeting as someone else’s job. The authors push back hard on this. Budget decisions are how you get the people and resources to deliver. More than that, budgets are a truth-telling mechanism — they reveal whether your stated priorities match your actual spending.
If you say customer experience is your top priority but your resources are all going to internal tools, the budget will show you the lie. This makes financial literacy not just useful but ethically necessary for anyone leading a team.
The chapter is practical, unpretentious, and full of useful frameworks for engineering leaders who never expected to spend time in spreadsheets. It won’t make you a CFO, but it will make you a much more credible leader in rooms where money decisions get made.
8. Technical Strategy Is Not a Document — It’s a Living Practice
Chapter 8 demystifies technical strategy, cutting through the enterprise-architecture jargon to a simple definition: what does your technology need to look like, and how do you get there to meet your business goals?
The book proposes 14 shared technical principles — simplicity first, scalability, modularity, reliability, maintainability, documentation, testing, visibility, security by design, performance awareness, consistency, and automation — not as rigid rules but as navigational guides. When developed collaboratively, they create shared understanding of what “good” looks like across a team.
The key insight is that in most chaotic organizations, any rigid plan will be obsolete before you finish your morning coffee. Technical strategy has to be flexible and iterative — a living document, not a slide deck.
9. Metrics Can Hurt More Than They Help
Chapter 10 opens with a scenario every engineering leader recognizes: someone in a meeting asks “how’s the engineering team doing?” and everyone stares at dashboards full of squiggly lines that nobody quite knows how to interpret.
The authors make a sharp distinction between metrics that reveal and metrics that deceive. Vanity metrics look impressive in slide decks but tell you nothing useful. Surveillance metrics make teams feel monitored and destroy the psychological safety you worked to build. The metrics that actually matter are the ones that identify problems before they become disasters and show whether your improvement efforts are working.
The chapter covers the DORA framework (deployment frequency, lead time, change failure rate, time to restore) while being honest about its limitations in chaotic environments. The broader lesson: measure what you want to improve, but be suspicious of any metric that starts to feel more important than the outcome it was designed to track.
The Real Message of the Book
Engineering Leadership: The Hard Parts is ultimately a book about endurance with intelligence. It doesn’t promise that chaos is fixable — sometimes the right answer really is to walk away, and the authors say so explicitly. But for leaders who choose to stay, it offers something more valuable than a playbook: a way of seeing.
The recurring insight across all eleven chapters is that the tools are less important than the judgment to deploy them at the right moment. Range beats style. Clarity beats control. Safety before everything else.
The most honest line in the book may be in the final chapter: “Chaos doesn’t give out medals for endurance. But you’re still here, and that matters.”
If you’re an engineering leader navigating disorder, this book won’t make the chaos disappear. But it might help you stop being surprised by it — and that’s the beginning of actually leading through it.