An Elegant Puzzle

About the book

An Elegant Puzzle gathers Will Larson's writing on managing engineering organizations. Its subject is the practical machinery of technical leadership: how teams are sized and structured, how work gets planned and prioritized, and how managers handle the transitions that come with growth. Larson writes from inside the discipline, treating management as a craft with reusable patterns.

The book is organized around problems rather than a single argument. It moves between organizational design, hiring and retention, performance, and the day-to-day systems a manager builds to keep decisions visible. The framing is systems-minded: a manager diagnoses a situation, chooses a structure, and watches what the structure produces. That approach suits readers who want frameworks they can adapt.

Larson's background in engineering shapes the vocabulary. He writes about organizations the way engineers write about systems, with attention to constraints, feedback, and failure modes. Management decisions come across as design decisions, open to revision when the evidence changes.

How to read it

Read it as a reference before reading it as a narrative. The material is organized for lookup, and many sections stand alone. A reader working through a specific problem, such as a team that has outgrown its structure, will get more from targeted chapters than from a single front-to-back pass.

Watch how Larson separates diagnosis from remedy. His examples tend to begin with a described situation and then work toward a structure or process. Test each recommendation against the size and stage of the organization you know. The advice is calibrated to growing technology companies, and the fit will vary elsewhere.

Who it suits

Engineering managers, directors, and technical leads will find the most use here, especially those moving from managing individuals to managing managers or redesigning teams during growth. Founders who supervise engineers without a management background can borrow its vocabulary for structure and planning. Readers in other fields may still find the organizational-design sections useful, though the examples assume software teams.

Reading considerations

The book reflects technology-company management as of its publication, and some tooling and hiring practices have shifted since. Its guidance is directional rather than prescriptive, so readers should treat recommendations as hypotheses to test against their own organizations. Later printings may differ in minor details; check the edition if citing specific passages.