# Will Larson's An Elegant Puzzle: a reference book for FDEs about to become leads > When you move from writing code at a customer site to answering for a whole team, this Stripe Press book teaches you to see the team as a system with flows, not a list of fires to put out. Original: https://fdetimes.net/en/books-courses/an-elegant-puzzle-will-larson-fde-lead/ A good FDE is often rewarded with something few people prepare for: more people. Yesterday you were writing pipelines for a customer yourself. Today you have three engineers, two engagements running in parallel and a question no technical documentation answers: why does the work get slower as the team gets bigger? Will Larson's *An Elegant Puzzle: Systems of Engineering Management* offers no ready-made formula for that question. What it gives you is a way of thinking that lets you find the answer yourself. The book was published by Stripe Press in 2019, and Larson has said it took him about a year to put together. For an FDE about to become a lead, the book's value is not in management tips. It lies in turning vague complaints such as "the team is overloaded" into a system you can draw, measure and fix. ## What is the book really about? Stripe Press presents the book as an answer to the typical questions of engineering management: how to deal with technical debt, and how to make sure each engineer on the team grows at the right pace. The publisher describes Larson's approach as a balance between structured principles and people-centred thinking. According to Gergely Orosz's review in The Pragmatic Engineer, the book is divided into six parts: Organizations, Tools, Approaches, Culture, Careers and Appendix. The Appendix provides tools for running an organisation at three levels: line manager, middle manager and manager of managers. Orosz calls it the best resource he knows of for engineering leaders who already have some experience. The second half of that sentence is the part worth noticing. If you have never mentored anyone or been accountable for other people's results, many chapters will read like theory. ## Idea one: a team is a system of stocks and flows Luca Rossi, author of the Refactoring newsletter, sees systems thinking as the core of the book, with its view of every system as stocks and flows. A stock is what accumulates; a flow is the rate at which it comes in or goes out. Picture a three-person FDE team. The stock is the list of customer integration requests waiting to be handled. Each week 6 new requests come in and the team closes 5. Nobody is lazy, nobody is weak, but after ten weeks the backlog has grown by 10 items and the customer is starting to complain. The reflex of a newly promoted lead is usually to work overtime alongside the team. Systems thinking forces a different question: should you reduce the inflow (filter requests during customer discovery), or increase the outflow (automate the repetitive parts of integration)? Now work through it. Suppose that at the discovery stage you can screen out 2 of the 6 weekly requests because they are not tied to the customer's goals. Inflow drops to 4, outflow stays at 5, so the backlog shrinks by 1 item a week, and the 10 outstanding items are cleared in ten weeks without anyone working extra hours. The most common mistake is to look only at the stock. A lead reports that "the backlog has 10 items" but does not know how many come in and go out each week, and so cannot say when things will improve. A backlog count tells you only where you stand; the two flow numbers tell you where you are heading. The first thing to do at a customer is to count those two numbers over the past four weeks, before promising anything more. **Key point:** Leading a team means solving a system, not putting out individual fires. ## Idea two: technical debt and people's growth are the same problem The two questions Stripe Press chose to introduce the book, technical debt and the pace at which each engineer grows, sound like separate topics. For FDEs they are tightly linked. Code written in a hurry at a customer site creates debt; the engineer who is forever fixing that debt stops learning. From the way Larson sets structured principles alongside care for people, a simple habit follows for a new lead. Whenever you assign a piece of work, ask whether it pays down debt, creates new value for the customer, or helps the person taking it grow. A good assignment should do at least two of the three. If an engineer has received nothing but bug fixes for three months running, you already have the answer to the question "are they growing at the right pace?" ## Idea three: hiring, evaluating and retaining people are skills to learn The book's Careers section covers hiring, performance evaluation, promotion and retention. For an FDE used to measuring themselves by code shipped and customers satisfied, these are entirely new tasks, and none of them gets better on the strength of technical ability alone. In career terms, this is also where you can stand out. When you read job ads for FDE lead or engagement lead roles, look for lines such as "mentor", "hiring" or "grow the team". On a CV, a sentence like "mentored 2 engineers, both leading engagements on their own after six months" is far more convincing than "strong leadership skills". ## Who should read it, and in what order? Rossi notes that the book is most useful for managers and tech leads in large organisations; smaller teams may find that not every chapter applies. He also observes that the content is extremely dense and rich, so it works better as a reference than as something read straight through. The advice that follows is fairly clear. If you are at a startup with a five-person FDE team, start with the Careers section and stocks-and-flows thinking, and leave Organizations and the Appendix for when the team grows. If you are in a large organisation, the Appendix and its three management levels will help you understand what your boss's boss is worrying about. If you would rather not buy the book yet, Orosz notes that Larson published drafts of the chapters on his Irrational Exuberance blog while writing it. Reading one post on exactly the problem you are stuck on is the cheapest way to find out whether the book suits you. The question "why does the team get slower as it grows?" will come back at every step up the ladder. The difference between an exhausted lead and a calm one often comes down to who practised drawing the system before it landed on top of them. **Try this week:** - Draw a stock-and-flow diagram for your current team or engagement: what is accumulating, what flows in and what flows out each week - Read one chapter draft on Larson's Irrational Exuberance blog about the topic you are most stuck on - For each person you mentor, write down what new thing they learned this week, and whether that pace of growth is fast enough ## Sources - [Stripe Press – An Elegant Puzzle](https://press.stripe.com/an-elegant-puzzle) - [An Elegant Puzzle: Systems of Eng Management (lethain.com)](https://lethain.com/elegant-puzzle/) - [An Elegant Puzzle Book Review: an Overdue Read for Software Engineering Leads](https://blog.pragmaticengineer.com/an-elegant-puzzle-book-review/) - [An Elegant Puzzle](https://refactoring.fm/p/an-elegant-puzzle)