An Elegant Puzzle deep dives into pretty much every aspect of being a tech leader at modern software companies. The author, Will Larson, has worked at Yahoo and Digg, moved on to engineering manager at Uber, then joined Stripe, and is now CTO at Calm. Quite the CV, and it shows.
Impressions
I’ve nicknamed the book “The Manual”. I keep coming back to it whenever I need guidance or just a reminder that the struggles of leading teams are universal. If you’re even slightly tempted, buy the physical book and not the Kindle version. Much easier to highlight, reference, and hand around when you want to convince someone else on your team to take a look.
One of my favourite aspects is how grounded the book is in reality. Larson’s been at the coal face for years. Whether it’s managing tech debt, negotiating hiring headcount, or knowing when to say no, you get the sense these are lessons learned by running into the wall himself, not just observing from afar.
A few standouts for me:
- What to do when your systems are slowing you down, but migrations are stacked up higher than you can count.
- How to say no, when there’s endless work and not enough people.
- Practical ways of paying down tech debt (not just hand-wavy “prioritise it” advice).
Structure
The book is split into six chapters, all independent, and you can dip in wherever you like:
- Organisation: Team structure, org design, and the subtle ways design decisions play out over time.
- Tools: Systems thinking, and practical tools to manage change at org, team, and individual level.
- Approaches: Challenging situations engineering managers run into, with options on how to navigate them.
- Culture: Small, persistent actions that shift culture (or entrench it).
- Careers: The messy world of hiring, performance, promotions, and retention.
- Appendix: Templates, checklists and reading lists that you’ll actually use.
Highlights
If you’ve just started a new job, write a 90-day plan covering what you want to learn, ship and understand in the first three months. Larson lays out why this matters and how to use it to spot gaps early or steer back if you drift. (If you’ve read A Manager’s Path, this will sound familiar, but Larson gives more concrete guidance.)
Another bit I keep returning to is the framework for presenting to senior management in Chapter 3. The point isn’t sounding smart. It’s building enough trust that people can support your decision without having to re-derive it themselves.
For engineers, build a real relationship with your manager. Larson lists the things your manager should know about you:
- What problems you’re trying to solve
- What you like to work on
- How you believe you’re being measured
- How busy you are
- Your goals and growth areas
That list alone is worth checking in with your manager next 1:1. If they can’t answer those about you, odds are you’re not getting what you need, and neither are they.
One idea I’ve stolen for my own toolkit is Larson’s four states of an engineering team. A team that’s falling behind watches its backlog grow every week. A team treading water gets the critical work done but has no room for anything else. A team repaying debt is starting to make space again. A team that’s innovating has low debt, high morale, and features going out of the door. Larson doesn’t stop at naming them. He sets out how to get unstuck from each one.
What makes An Elegant Puzzle different from most leadership books is its honesty about trade-offs. It doesn’t pretend every problem dissolves if you just empower your team. It’s about working within constraints and picking your battles.
Larson reminds you that organisational design is never finished. Teams, structure, and incentives quietly shape every outcome. You can’t out-process a bad structure, and you can’t out-hire a broken culture. The work is ongoing.
He’s also pragmatic about tech debt. Not all debt is equal, and often the real work is separating the kind that matters from the kind you can safely ignore. Naming the specific pain takes more discipline than labelling everything “debt”.
The book is packed with frameworks and checklists, but the value is in the stories around them. It’s the kind of book that gets better the more real-world experience you bring to it.
If you’re leading engineers, or want to, this is the one I keep reaching for when things get complicated. It won’t solve your problems, but it will help you see them more clearly, and that’s usually enough to find a way through.
Published on .