What 'An Elegant Puzzle' Gets Right About Engineering Leadership

Introduction

What I appreciate most about An Elegant Puzzle is that it treats engineering management as a systems design problem, not just a coaching problem.

That distinction matters. A lot of management advice focuses on behaviours, communication, and one-to-ones. Those things are important, but they are only part of the picture. Engineering leaders also shape the conditions in which teams operate: ownership boundaries, planning discipline, organisational incentives, technical investment, and the amount of work the system is expected to absorb.

That is where I think Will Larson gets a lot right. The book is strongest when it explains that many delivery problems are not caused by weak individuals. They are the result of poor team design, unclear trade-offs, overloaded systems, and organisational habits that make good execution harder than it needs to be.

Below are the ideas that stood out most to me, along with why I think they matter in practice.

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 more fragile than leaders sometimes admit. Even small changes in team composition can disrupt trust, context, and momentum. In practice, it is often better to move scope than to keep moving people around.

I think this is one of the most important leadership points in the book. Some organisations treat people as interchangeable resourcing units. They are not. Stable teams build shared context, operating rhythm, and trust over time. Once you disrupt that too often, delivery becomes noisier and management gets harder.

One of the clearest signs of immature leadership is a willingness to reorganise people before questioning the shape of the work.

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 a team slower rather than faster.

As The Mythical Man-Month reminds us: adding more people to a late software project makes it later.

That ties closely to prioritisation. When a team is overloaded, reducing scope is often a better move than increasing pressure or adding headcount in the hope that throughput will magically improve.

This is really a lesson about constraints. If the bottleneck is ambiguity, dependency management, architectural complexity, or decision latency, adding more people will not solve the underlying issue. It may even make it worse.

Good leaders learn to ask a harder question than “How do we add capacity?” They ask, “What is the actual limiting factor in this system?” In my experience, work-in-progress limits and scope reduction are often more effective than adding people.

Teams need slack

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.

Leaders sometimes talk about efficiency when they really mean utilisation. Those are not the same thing. A fully utilised team is often a brittle team. It has no room to absorb change, no room to improve its tools, and no room to respond well when reality interrupts the plan.

If everything is urgent, the system is already in trouble. Slack is not waste. It is the buffer that lets a team handle real work like professionals rather than constantly operating in recovery mode.

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.

This is another area where leadership quality shows up very clearly. Plenty of organisations claim that they care about technical debt, yet few of them are willing to protect the time, sequencing, and sponsorship needed to reduce it.

Debt does not usually get resolved through goodwill and spare cycles. It gets resolved when leaders decide that reducing future drag is important enough to compete with near-term feature pressure. Sometimes you do need to go slower in the short term if you want to move faster later.

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.

This is probably the central idea in the whole book, and it is one I strongly agree with. Leaders get into trouble when they diagnose systemic issues as if they were single-point failures.

If quality is poor, morale is slipping, delivery is erratic, and priorities keep colliding, the answer is rarely just “manage harder”. More often, the system is producing exactly the behaviour it is set up to produce.

That is why good engineering leadership requires a level of organisational design thinking. You are not only managing people. You are shaping an environment.

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 would add here is that strategy should be focused on a small number of organisation-wide priorities. If you have more than 3 or 4, you probably do not have a strategy at all. You have a wish list.

I think this is where many leadership teams make life harder for themselves. They avoid hard trade-offs, keep too many things in flight, and then wonder why teams feel stretched and progress feels thin everywhere.

Saying no is not a communication style. It is a core operating discipline. If leaders cannot narrow focus, the organisation pays for that ambiguity in coordination cost, context switching, and missed execution.

For further reading on this subject, I recommend reading Good Strategy Bad Strategy by Richard P. Rumelt.

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, protected technical investment, and a bit of breathing room do not sound especially glamorous, but they matter a great deal.

That is one reason I think the book is worth reading. It reinforces a view of engineering leadership that I find increasingly important: the job is not simply to push teams harder or motivate individuals more. The job is to design an environment in which good decisions, steady execution, and healthy teams are more likely by default.

The best engineering leaders I have seen are not heroic fire-fighters. They are thoughtful system builders.