Buy at https://amzn.to/4o2a4aC

What It's About

Matt Watson spent twenty years learning what most CTOs figure out too late: your best engineers can ship flawless code on time and still build the wrong thing. Product Driven tackles the gap between technical execution and business impact—the space where teams deliver features nobody needs while the competition figures out what customers actually want.

The book’s central argument is simple but uncomfortable. We’ve spent decades teaching engineers to write better code, adopt better practices, and ship faster. But speed doesn’t matter when you’re running in the wrong direction. Watson argues that engineering teams need to think like product owners, not ticket processors. That means understanding business context, owning outcomes instead of outputs, and having the judgment to push back when requirements don’t make sense.

What makes the book relevant right now is the AI angle. As code generation gets commoditized, the teams that win won’t be the ones who can build faster—they’ll be the ones who know what to build and why. Watson’s “Product Driven Model” is his framework for making that shift, built from his experience scaling two companies to successful exits and watching plenty of smart teams fail along the way.

This isn’t another book about Agile transformation or OKRs. It’s about changing how engineers see their role—from implementers waiting for specs to problem solvers who understand the business deeply enough to make good decisions without constant handholding.

Why I Recommend It

I’ve spent 25 years watching talented engineering teams build themselves into irrelevance. They hit every sprint goal, their pipelines stay green, their code reviews are thorough—and then they wonder why the business isn’t growing or why their best people keep leaving for companies where they get to own real problems.

Watson nails what I learned the hard way: you can’t scale impact by just scaling team size and velocity. I’ve inherited teams that could ship features at impressive speed but had no idea whether those features mattered. The disconnect wasn’t a process problem or a communication problem. It was an ownership problem. Engineers treated themselves as a service organization, and management let them.

What I appreciate about this book is it doesn’t preach product thinking as some abstract ideal. Watson comes from the same place I do—he’s built teams, shipped products, dealt with the mess when things don’t work, and had to figure out why smart people with good intentions still miss the mark. His framework isn’t academic theory. It’s the pattern recognition that comes from doing this work long enough to see what actually moves the needle.

The timing matters too. I’m watching AI change what engineering work means, and not everyone sees it coming. When anyone can generate working code, the value shifts to knowing what code to write. That judgment—understanding user problems, business constraints, and technical trade-offs well enough to make good calls—that’s what separates high-performing teams from high-activity teams.

If you’re leading engineers who complain they never have enough context to make decisions, or if your roadmap is full but your business impact is empty, this book will show you what you’re missing. It’s not a fix-everything solution, but it’s a clear articulation of a problem I see everywhere and a practical path toward fixing it.

Buy at https://amzn.to/4oueqHs

What It's About

Patrick Lencioni frames team dysfunction as a pyramid of interconnected problems. At the base is trust—or rather, the absence of it. When team members won’t show vulnerability, won’t admit mistakes or ask for help, everything else falls apart.

That lack of trust makes people avoid conflict. Not the toxic kind, but the productive disagreement that every good decision needs. Teams end up in fake harmony where nobody really says what they think.

Without real debate, you get weak commitment. People nod in meetings but don’t actually buy in. Then nobody holds anyone accountable because they never truly agreed to the plan in the first place. And at the top of the pyramid, the ultimate failure: team members care more about their own goals than collective results.

The book delivers this through a business fable about a CEO fixing a dysfunctional executive team at a struggling tech company. It’s a quick read—you can knock it out in a few hours—but the ideas stick with you.

Why I Recommend It

I’ve seen every one of these dysfunctions play out in real teams. The “trust” problem hit me hardest because I used to think trust meant believing your colleagues were competent. Lencioni argues it’s actually about vulnerability—being willing to admit when you’re wrong or don’t know something.

That reframing changed how I ran leadership meetings. I started admitting my own uncertainties first. “I’m not sure this architecture will scale, and I need your honest take” opened up conversations that “What do you think of my proposal?” never did. The quality of our technical debates improved within weeks.

The conflict section resonates because I’ve watched too many teams mistake politeness for professionalism. We’d leave meetings with “alignment,” then executives would quietly pursue their own agendas. The book gave me language to call out that behavior and permission to push for real disagreement in the room.

What makes this book valuable isn’t some breakthrough framework—it’s that Lencioni names dynamics every leader has experienced but struggled to articulate. The fable format makes it accessible without dumbing it down. You can hand this to a new engineering manager or a board member and they’ll both get something from it.

The limitation? It’s light on the “how.” Lencioni tells you what’s broken and why it matters, but you’ll need to figure out the specific interventions for your context. When I had an executive team that wouldn’t hold each other accountable, the book helped me diagnose the problem. Fixing it required six months of uncomfortable conversations and one firing.

But that diagnostic clarity matters. Half the battle is recognizing which dysfunction you’re actually dealing with. I’ve seen leaders try to solve commitment problems by demanding accountability, when the real issue was three levels down at trust. This book helps you see the foundation you’re missing.

If you lead a team that feels stuck—hitting deadlines but not really performing, agreeing in meetings but not executing, talented individually but weak collectively—read this. Then pick one dysfunction to address and give it three months. You’ll know pretty quickly if you’re working on the right problem.

Buy Now

What It's About

Edmond Lau's "The Effective Engineer" tackles the exact challenge most engineers face: working incredibly hard but struggling to articulate or maximize their impact. The book introduces the concept of "leverage" - the value produced per unit of time invested - and provides a systematic framework for identifying and pursuing high-leverage activities. Lau draws from his experience at top tech companies like Google, Facebook, and Quora to show how the most successful engineers don't just write more code; they focus on work that multiplies their impact across teams and organizations.

The book covers practical topics like how to prioritize tasks based on impact rather than urgency, how to measure engineering productivity in business terms, and how to build tools and systems that amplify your effectiveness. Most importantly, it teaches you to think like an owner rather than an employee, constantly asking "What's the highest-impact thing I could be working on right now?" rather than just completing assigned tasks.

Why I Recommend It

This book is essentially the technical companion to building your Impact Portfolio. Where my article focuses on documenting and communicating your value for promotions, Lau's book teaches you how to create that value in the first place. His framework for calculating leverage directly translates to the kind of quantifiable metrics that make promotion conversations straightforward rather than painful.

What sets this book apart is its focus on business impact over technical elegance. Lau repeatedly emphasizes that the "best" solution is often not the most technically sophisticated one, but the one that delivers the most value to users and the business. This mindset shift is crucial for engineers who want to move beyond individual contributor roles - it's precisely the thinking that separates staff engineers from senior engineers.

The book's emphasis on measurement and iteration also perfectly complements the weekly impact tracking I recommend. Lau provides specific techniques for quantifying engineering work that seems unquantifiable - from developer tool improvements to technical debt reduction - giving you the vocabulary and frameworks to translate technical achievements into business value. If you've ever struggled to explain why refactoring that legacy system matters to non-technical stakeholders, this book provides the blueprint.

For engineers serious about accelerating their careers through impact rather than tenure, this book is required reading. It's not about working harder; it's about working on the right things and being able to prove it.

Buy Now

What it's about

A modern take on non-linear career paths, providing tools for navigating careers that zig-zag rather than climb straight up. Includes exercises for identifying strengths, values, and possibilities beyond traditional corporate ladders.

Why I recommend it

The days of 30-year tenure at IBM are dead, and this book gets it. What resonates is their "career portfolio" approach—treating your career like a distributed system rather than a monolithic application. The exercises on values and strengths cut through the noise to what actually drives your decisions. I recommend this especially to engineers feeling trapped in the "senior engineer to staff engineer to principal" conveyor belt. Sometimes the most strategic move is sideways or even backwards. Their framework helps you evaluate non-obvious moves that compound over time.

Buy Now

What it's about

A systematic approach to navigating career transitions, whether joining a new company, getting promoted, or switching roles. Watkins provides frameworks for learning, securing early wins, and building critical relationships during crucial transition periods.

Why I recommend it

Most engineers fumble their first months in new roles, wasting precious momentum. This book transformed how I approach transitions—treating them like system deployments that need careful planning, not random events. The STARS framework (Start-up, Turnaround, Accelerated growth, Realignment, Sustaining success) helps you diagnose your situation and adapt accordingly. I've watched engineers who apply these principles reach productivity 50% faster than those who wing it. The 90-day plan isn't just about surviving; it's about positioning yourself for the next leap before others even finish onboarding.

Buy Now

What it's about

A systematic approach to navigating career transitions, whether joining a new company, getting promoted, or switching roles. Watkins provides frameworks for learning, securing early wins, and building critical relationships during crucial transition periods.

Why I recommend it

Most engineers fumble their first months in new roles, wasting precious momentum. This book transformed how I approach transitions—treating them like system deployments that need careful planning, not random events. The STARS framework (Start-up, Turnaround, Accelerated growth, Realignment, Sustaining success) helps you diagnose your situation and adapt accordingly. I've watched engineers who apply these principles reach productivity 50% faster than those who wing it. The 90-day plan isn't just about surviving; it's about positioning yourself for the next leap before others even finish onboarding.