Book Notes - An Elegant Puzzle
My notes on An Elegant Puzzle

Introduction
I recently finished reading An Elegant Puzzle by Will Larson. I found it useful because it talks about engineering management as a systems problem rather than just a people problem.
I read it with a colleague at work, and we are now using it as the basis for a small book club. They are a senior engineer stepping into leadership as an interim tech lead, and I have been coaching them along the way. The book has been a useful starting point for a number of conversations.
Below are the ideas that stood out most to me.
Team design matters - a lot
Team size, ownership boundaries, and reporting lines all affect delivery. Teams of around 6 to 8 engineers seem like a sensible balance. Big enough to carry meaningful scope, small enough for good coaching and coordination.
High-performing teams are also fragile. Even small changes in team composition can disrupt trust and momentum. It is often better to move scope than to keep moving people around. This aligns with my experience.
Adding people is not a silver bullet
New people bring onboarding cost, more coordination, and often more system complexity. In the short to medium term, that can make things slower rather than faster.
That ties closely to prioritisation. When a team is overloaded, reducing scope is often a better move than increasing pressure.
Slack is useful
Teams need room for interruptions, improvements, documentation, migrations, and the general messiness of real work. If a team is planned to 100% capacity all the time, every surprise becomes a problem.
Sustained high workload is usually a sign that the system is wrong, not that people are lazy. I strongly agree with this point.
Technical debt needs deliberate work
If an organisation wants to reduce drag, it usually needs to invest in deliberate migrations with actual support behind them. Otherwise the debt just sits there and slows everything down a little more each year. You need to go slow to go fast.
Systems thinking is important
Many engineering problems are not isolated. They come from the interaction between team structure, incentives, planning, architecture, and communication. That is why local fixes often fail or just move the problem somewhere else.
Strategy and saying no
I liked the distinction between strategy and vision. Vision gives direction. Strategy is about making explicit trade-offs against the constraints you have right now.
Saying no matters as well. A lot of leadership seems to come down to protecting teams from too much work-in-progress.
Something I’d like to add here: strategy should be focused on a small number of org-wide priorities. If you have more than 3 or 4, you probably don’t have a strategy at all.
Closing Thoughts
My main takeaway from An Elegant Puzzle is that strong organisations rely less on heroics and more on good systems.
Clear ownership, stable teams, sensible scope, and a bit of breathing room do not sound exciting, but they seem to matter a lot.