PDF Summary:An Elegant Puzzle, by Will Larson

Often, engineering teams can’t escape dysfunction—not because they aren’t talented or hard-working, but because their organization’s structure makes good performance impossible. In An Elegant Puzzle, engineering leader Will Larson argues that managers need to learn systems thinking to figure out why their teams struggle and how to create lasting improvement. Whether you’re managing engineers or leading any knowledge work team, you have to learn to distinguish between symptoms and root causes—and stop blaming people for structural problems.

In this guide, we’ll explain why structural changes create lasting improvement when tactical responses can’t, how Larson’s systems thinking framework helps managers diagnose why their teams are stuck, and how to apply this thinking consistently in practice. We’ll also connect Larson’s ideas to insights from cognitive science, organizational psychology, and management classics—from why the brain resists structural change to why copying successful companies’ practices almost always backfires.

(continued)...

Both can be correct because they’re describing different situations. Brooks warns against a specific managerial reflex: the panicked decision to flood a struggling project with new hires. Larson is prescribing something fundamentally different: a deliberate, structural change to the team’s long-term capacity, made before a crisis becomes unrecoverable. Brooks walked back his own law’s absolutism in later editions of his book, noting that early, deliberate hiring—the kind Larson prescribes—gives new people time to find their footing before the pressure builds. The lesson from putting the two ideas together is that hiring works as a structural fix when it’s planned and proactive. It backfires when it’s a panic response.

Larson cautions that there’s an important constraint to observe as your staff and capacity grows. You may be tempted to reorganize teams, but Larson says you should always move work, not people. Rather than reassigning engineers from one team to another, he recommends reassigning which projects teams are responsible for, so that each team stays together while the work changes hands.

(Shortform note: Larson’s advice to “move work, not people” squares with research showing that when a team works together for a while, its members build up informal roles: who tends to spot problems early, who checks in with whom without being asked, whose judgment gets trusted on which kinds of calls. These habits distribute awareness across the group in ways that nobody planned and nobody fully documents—and that determine how resilient the team is. A newly assembled team hasn’t had time to develop that distributed awareness yet, so when you move people rather than work, you don’t just reset relationships; you take your most resilient teams and make them temporarily fragile.)

State 2: Treading Water

Teams that are treading water complete critical work but lack the bandwidth to address their technical debt or to start major improvements. Larson explains that these teams have reached an equilibrium where capacity matches incoming work, but at a suboptimal level. The system is stable but stuck. Any attempt to reduce technical debt or innovate means some urgent work doesn’t get done, creating pressure to return to maintenance mode. A team can sustain this state indefinitely, but it can’t escape it through increased effort alone.

The structural solution: Reduce work-in-progress. Have people work on fewer projects simultaneously to complete things faster, freeing up time and mental space. It feels counterintuitive that asking people to do less could help you achieve more, but Larson argues it’s the only way to break the equilibrium. Once you’ve freed up the team’s capacity, redirect people’s time to paying down technical debt. As debt decreases, work moves faster, freeing more time in a compounding cycle that gives people breathing room.

Why Doing Less Works: The Math

Other experts agree with Larson that a treading-water team needs to reduce the amount of work it has in progress—and they’ve done the math to explain why. In The Phoenix Project, Kim, Behr, and Spafford offer a formula for calculating how long any task in a team’s queue will wait before someone gets to it: The wait time equals the percentage of time the team is busy divided by the percentage of time it spends idle. This equation demonstrates that the relationship between how busy a team is and how long tasks will wait doesn’t progress linearly: A team running at 80% capacity doesn’t just feel busier than one at 50%—its wait times are four times as long. When the team is running at 95% of what it can handle, that wait-time multiplier hits 19.

This shows that if managers push a team too close to their capacity, they don’t just add pressure—the math ensures that the team isn’t ever going to get ahead. The math is also what makes the improvements in Larson’s compounding cycle compound rather than simply add up: Modest reductions in the amount of work in progress produce disproportionately large improvements in how much the team gets done. The first reductions pull them out of the danger zone where backlogs grow faster than the team can work through them, freeing up far more time and cognitive bandwidth than you’d expect.

State 3: Repaying Debt

Teams in the repaying-debt state successfully reduce technical debt through a compounding effect. Each improvement creates the capacity for more improvements: Better tools make development faster, and reduced debt means fewer emergencies. Larson explains that in this performance state, the feedback loops have flipped positive—progress creates more capacity for progress. The compounding effect takes time to build momentum; early improvements might free only a few hours per week, but as improvements stack, the freed capacity grows and eventually creates a substantial surplus that accelerates further improvements.

Larson cautions that although teams that are repaying debt make real progress, that progress is fragile. While the compounding cycle is running in this state, it hasn’t yet built enough momentum to become self-sustaining. Therefore, the same organizational pressures that created the technical debt in the first place can interrupt its repayment at any point. A manager who notices the team has more breathing room than it did last month, a new feature request that seems urgent, a crisis that demands immediate attention—any of these can break the cycle before it generates meaningful surplus and can push the team back into the treading water state.

Small Gains, Big Momentum

The compounding effect Larson cites has a formal name in systems thinking: a reinforcing feedback loop, where each improvement actively increases the rate of future improvements, not just the total amount. The mechanism is well-documented, but it has one frustrating property: As Rhiannon Beaubien and Rosie Leizrowice note in The Great Mental Models Volume 3, compounding tends to be invisible when it matters most. Early in the debt-repayment cycle, when improvements free up only a few hours per week, the system looks like it isn’t working—which is exactly when the pressure to abandon it and chase new features feels most reasonable.

The compounding effect works on a psychological level, too. Researchers find that making progress is the single strongest predictor of employees reporting a great day at work. This happens in part because, as Anne-Laure Le Cunff explains in Tiny Experiments, the brain releases dopamine when it registers forward movement, boosting motivation and energy. For a team that’s been treading water, small improvements in the debt-repayment phase signal that the system is working, that effort is producing results, and that the work is becoming more sustainable—which rebuilds the belief that improvement is possible.

The structural solution: Protect time. People need sustained focus to build momentum. Resist pressure to abandon improvement work for new features. Remember that early improvements free only small amounts of time. Larson says that if you interrupt people to chase new opportunities, you abort the cycle before it generates meaningful momentum. This requires months, not weeks. But once the cycle builds sufficient momentum, people find they have substantial capacity freed up, and the work becomes more sustainable.

Sustained Focus Is Irreplaceable

Larson’s insistence on protecting time reflects the cognitive demands of knowledge work. Psychologists say that complex intellectual work requires “flow”: a state of deep focus characterized by euphoria, a distorted sense of time, and effortless progress.

Neuroscience explains why the flow state is so captivating and enjoyable: When you begin to focus deeply, your brain shifts from explicit processing (conscious, effortful thinking) to implicit processing (which is fluid and automatic). The brainstem fine-tunes your attention so you respond strongly to information relevant to the task while filtering everything else out. As these changes occur, neurochemicals flood your system—dopamine for motivation, norepinephrine for focus, anandamide for creativity—while the default mode network, which activates when your mind wanders, shuts down. The result is a state where every action flows into the next.

But, this state is fragile: Reaching it requires about 15 minutes of uninterrupted concentration, and any interruption breaks the state entirely. Because reentry takes 15 minutes, it’s entirely possible to be present in an office for eight hours and spend only an hour or two in actual flow. This is why Larson’s prescriptions—like reducing work in progress or protecting time for improvement work—aren’t just organizational preferences. They’re preconditions for the kind of thinking that makes software engineers and other knowledge workers valuable in the first place.

State 4: Innovating

Teams that are innovating maintain sustainably low technical debt while spending most of their time delivering new capabilities and features. Larson explains that this is because they have slack: surplus capacity beyond what’s needed for routine maintenance and urgent problem-solving. This slack lets the team maintain code quality, respond to new opportunities, experiment with better approaches, and pursue interesting problems. Team morale is high because people can do good work on meaningful projects without constant crisis management. The team has enough capacity to do what needs doing, plus enough margin that occasional problems don’t trigger cascading failures or force a return to maintenance mode.

The innovating state presents a different kind of problem from the previous three: The team isn’t visibly struggling, so the threat isn’t obvious. A high-performing team with slack is one with visible spare capacity—and spare capacity invites additional commitments. The organizational pressure to fill available space is structural and constant, and it doesn’t require any bad decisions for it to have a negative impact. Work simply flows toward capable teams, and the slack that makes innovating possible quietly disappears.

The Inertia Problem

Larson describes the innovating state as one where teams have enough slack to do their best work. In Innovation and Entrepreneurship, Peter F. Drucker explains why slack is so difficult to protect: organizational inertia. The tasks needed to sustain your current projects compete with any time and resources you’d invest in innovation because those tasks are already in motion. They have active users, pending deadlines, and organizational weight behind them. In other words, the slack to innovate is easily erased because the forces that erode it are structural and constant.

Drucker’s solution for large organizations is to keep innovative work separate from the rest of your operations so it can’t be cannibalized by other priorities. That might not work for a single team, but the principle to keep in mind is that protecting the time and energy to innovate requires real commitment, not just good intentions.

The structural solution: Maintain slack. Resist filling everyone’s calendar with commitments. Don’t view slack as waste, but as what enables high performance by giving people room to absorb variation (as when someone gets sick or urgent issues arise) without triggering cascading failures. When others request more work from the team, the proper answer should be “We’re maintaining the capacity that enables our people to sustain this level of performance.”

(Shortform note: Maintaining slack doesn’t just enable better performance—it also helps retention. Research on why workers quit points directly to the conditions that slack prevents: People most often leave because they see a lack of advancement opportunities (63%), feel disrespected (57%), or feel they’re not being paid enough for the work they’re doing (63%). Teams that are permanently in damage control mode create exactly these conditions. When there’s no capacity for anything beyond urgent maintenance, people can’t develop new skills, take on meaningful challenges, or see a path forward.)

How to Apply Systems Thinking in Practice

We’ve established that teams are systems whose behavior is determined by structural dynamics; managers who understand those dynamics can diagnose which performance state their team is in and what kind of structural change it requires. What remains is the question of how to make systems thinking a part of the daily practice of managing a team.

Larson’s answer is a list of principles—not one-time interventions, but ongoing habits of a manager who’s internalized the idea that teams are systems and that structure determines outcomes. Applied consistently, these practices prevent the organizational drift that pulls teams toward dysfunction. Each principle is a small structural commitment that, compounded over time, keeps the system healthy.

Build Consistent, Structured Processes

First, Larson argues that repeatable, documented processes create the consistency needed to treat people fairly. Structure makes decisions visible and improvable—you can see patterns, measure results, and iterate toward better approaches. Without structure, decisions get made informally: Someone chooses based on intuition, personal relationships, or whoever asks first, creating inconsistency that undermines trust. Consider hiring: If different managers apply different standards, then candidates’ evaluations will feel arbitrary. A structured process—with defined requirements, consistent interview loops, and calibrated assessments—ensures that everyone who interviews for a job is evaluated comparably and fairly.

Larson emphasizes that consistency matters more than perfection in how you treat people. A good-enough process applied consistently beats a theoretically perfect process applied inconsistently, because consistency helps people trust the system even when individual outcomes disappoint them. Larson recommends resisting requests for special treatment: When someone asks you to bend the rules for them, don’t agree on the spot. Instead, watch for patterns. If many people ask for the same accommodation, that’s a signal your process has a gap—but fix it by updating the process itself, rather than addressing one-off special cases that make some people feel favored while others feel disadvantaged.

The Hidden Cost of Informal Decisions

Larson’s case for structured processes is largely an ethical one: Consistency is fairer than intuition. In Noise, Daniel Kahneman, Olivier Sibony, and Cass Sunstein illustrate just how unfair the alternative really is. They found that unstructured decisions don’t just risk bias but also produce what the authors call noise: chance masquerading as judgment. For example, studies show that judges pass harsher sentences after their local football team loses. College admissions officers weigh students’ credentials differently on cloudy versus sunny days. Interviewers form different impressions of a candidate depending on who they spoke to just before. In each case, the outcome of the resulting decision is largely the result of chance.

Moreover, the authors of Noise find that inconsistent decisions don’t cancel each other out over time. Every decision affects a real person, and the unfairness accumulates. Each accommodation you make means some people get different treatment than others—and not because of any meaningful reason, but because of timing, framing, or simply your mood. A process that handles exceptions systematically is the only reliable way to keep noise from accumulating.

Why Structure Matters More Than Skill

Larson’s central argument is that structure matters more than individual skill or effort in determining team outcomes. This doesn’t mean people don’t matter—within a good structure, individual capability absolutely influences results. But structure sets the bounds of what’s possible. An exceptional team with brilliant engineers will fall behind when its structural imbalance overwhelms its team members’ capabilities. A team with exceptionally hardworking people that gets stuck treading water can’t escape without structural change. No amount of individual excellence compensates for a system designed to produce mediocre results.

This logic explains a phenomenon Larson considers one of the most common mistakes in management: copying practices from successful companies. If structure determines outcomes, then the behaviors visible in high-performing organizations—such as minimal process, autonomous decisions, rapid iteration, or high trust—aren’t techniques that can just be transplanted. They’re the natural behavior of people operating within healthy structural conditions. Adopt those behaviors in a structurally dysfunctional team, and you don’t get the results; you just add new processes to a team that lacks the slack required to implement those behaviors. The structural conditions have to come first.

When Practices Are Symptoms, Not Causes

Geoffrey West’s research in Scale accords with Larson’s insight that structure, not individual behavior, determines a system’s output. West finds that once you know the structure of a system (how its networks are organized and how resources flow through it), you can predict its outputs with mathematical regularity. Those predictions will be accurate regardless of what the individual components are doing. For example, a neuron in a mouse brain and a neuron in an elephant brain are functionally similar. What differs between them is the structure of the network each is embedded within, which accounts for the difference in what each animal can do. The neuron’s ability isn’t irrelevant, but it’s bounded by the structure it operates within.

Because behavior emerges from structural conditions (not the other way around), transplanting what you observe in a high-performing team without replicating its structural conditions is like expecting a neuron from an elephant’s brain to give a mouse elephant-scale capabilities. The behaviors we admire in high-performing organizations—like the creative density of a fast-moving startup or the innovative output of a thriving team—aren’t techniques that can be extracted and transplanted in isolation. They’re emergent properties of underlying structure.

Measure to Understand and Influence

Without deliberate measurement, a manager’s evaluation of their team’s performance is mostly intuition—and intuition is a poor substitute for knowing where you actually are, which way you’re moving, and whether what you’re doing is working.

Larson explains that effective metrics serve two functions simultaneously: They help you understand how the system is behaving, and they guide people’s actions toward the outcomes you want. Good metrics include four elements: where you are now, where you want to be, your current direction, and when you hope to get there. This structure lets anyone on the team evaluate whether a goal is ambitious and to assess whether they’ve succeeded. Larson recommends pairing each goal for improvement with metrics you want to protect, so that optimizing for one outcome doesn’t inadvertently degrade another.

Larson notes that metrics shape how people behave, sometimes in unintended ways: People optimize for what you measure, so emphasizing “lines of code written” encourages people to write more code, not better code. Focusing on “bugs fixed” encourages people to find trivial bugs rather than prevent serious ones. Larson also argues that managers must accept that some important things—like whether people feel supported, or whether they’re learning and growing—are hard to measure precisely, but shouldn’t be ignored just because they resist quantification.

(Shortform note: Other experts agree with Larson that measuring the wrong things risks directing people’s time and attention away from what’s important. John Doerr reports in Measure What Matters that for a time, YouTube was tracking metrics like clicks, views, and revenue, but the company later recognized that watch time better captured what it cared about. Later, YouTube shifted toward measuring and optimizing for user satisfaction, which had become the more meaningful signal. If the company hadn’t shifted its focus as it understood what metrics best reflected what it wanted to prioritize, engineers would have been spending their time and energy optimizing the wrong things.)

What Your Metrics Really Measure

Larson’s approach to metrics is about reducing uncertainty: You’re not just declaring a target, but documenting what you know right now so you can tell whether you’re making progress. In The Art of Uncertainty, David Spiegelhalter notes that while we sometimes face uncertainty due to genuine randomness, where no amount of information can help us predict what will happen, we also face gaps in our knowledge that measurement can close. Each of Larson’s elements chips away at a piece of that uncertainty: where you are, which way you’re moving, when you’ll see progress, and where you’ll end up.

Douglas Hubbard makes a related point in How to Measure Anything. He notes that the goal of measurement isn’t certainty—even a rough estimate is more useful than no estimate at all. This framing also sharpens Larson’s point about the things that resist quantification—the ones managers are tempted to set aside because they seem impossible to track. That temptation confuses two kinds of uncertainty: things that are genuinely unpredictable (like whether a specific engineer will quit) and things that just haven’t been measured yet (like whether team morale is improving). The second kind can always be estimated: For morale, you might look at attrition patterns, what people say in one-on-one calls, or results from a short survey.

Understand System Limits

Larson argues that when it comes to making progress, every system has limits—and that engineering organizations typically hit those limits after an order of magnitude of growth, at which point their current processes break down. For instance, a planning process that works well for 20 engineers becomes unmanageable at 200. These limitations don’t manifest as gradual degradations where people can slowly adapt. Instead, you’ll often encounter cliffs where the system suddenly becomes dysfunctional and people can’t do their jobs effectively. This means you need to design for the scale you’re approaching, not the scale you have.

Larson recommends that if your organization currently has 100 engineers and is growing rapidly, you should design processes for 1,000 so people won’t have to learn entirely new ways of working every six months. If your website traffic doubles every quarter, plan technical infrastructure for the next order of magnitude so engineers aren’t constantly firefighting scaling crises. The goal is to project forward based on current trajectories and make structural changes before you hit limits that will overwhelm your staff. But Larson cautions against over-engineering for scales you’ll never reach, since that wastes people’s time building unnecessary complexity.

Designing Ahead—But Not Too Far Ahead

Larson’s next-order-of-magnitude rule might seem like merely an engineer’s rule of thumb, but in Blitzscaling, Reid Hoffman and Chris Yeh do the math to show why it’s correct. As your team grows, the number of relationships that need to be coordinated doesn’t grow at the same rate as headcount—it explodes. A team of 5 has 10 pairwise connections to manage, while a team of 100 has 4,950 (the same mathematical relationship we saw earlier with growing cities and innovation). At some point, that overhead simply overwhelms whatever processes you’ve built to manage it—which is why Larson describes scale failures as abrupt cliffs rather than gradual slopes.

This context also helps resolve an apparent contradiction that readers familiar with startup culture may notice. Hoffman advises founders to “do things that don’t scale”—don’t build infrastructure for a million users when you barely have 10, and write throwaway code rather than over-engineering for a future that may never arrive. That sounds like the opposite of Larson’s prescription to design for the scale you’re approaching. But Hoffman is addressing early-stage founders whose primary risk is burning through resources before finding the right market. In that context, building ahead of your actual scale can be wasteful.

Larson, on the other hand, is writing for managers at organizations already on a sustained growth trajectory, where the primary risk is the kind of structural dysfunction that traps teams in firefighting mode indefinitely. Both authors make the same underlying point: Match your system design to your actual trajectory, neither lagging behind it nor racing so far ahead that you build complexity you’ll never need.

Make Knowledge Explicit

Larson emphasizes that in addition to designing your practices, you need to document and share your team’s knowledge. He explains that tacit knowledge doesn’t scale: When critical information exists only in people’s heads, it creates bottlenecks where nothing can happen without those specific people. But knowledge that’s made explicit—written down, documented, and shared—can be referenced, improved, and used by anyone, which respects people’s time and lets them work autonomously. Larson recommends that when you or your team make a significant change, updating documentation should be considered part of completing that change—a way of respecting the people who will encounter the system after you.

(Shortform note: Larson’s advice to treat documentation as part of your team’s work is easier said than done. In The Checklist Manifesto, Atul Gawande explains the psychology that makes updating documentation so easy to skip. First, memory and attention for non-urgent tasks fails when more urgent things compete for our focus. Second, we skip steps even when we remember them because they feel optional until the day they aren’t. Gawande’s solution is to define a clear “pause point” at which a checklist item must be confirmed before moving on. Applied to Larson’s principle, that pause point is the moment a change is complete. Establishing that can make updating documentation a structural requirement, not a mere aspiration.)

Anticipate Lag Time

Structural changes work—but Larson notes that they work slowly, typically requiring months to take full effect. You must hire people, give them time to complete onboarding, and allow them to build relationships and reach full productivity. You must protect improvement work long enough for any compounding cycle to build real momentum. During this lag, managers may feel tempted to abandon structural fixes and return to tactical responses—to just ask people to work harder right now, which produces visible activity even if it doesn’t change the system’s dynamics.

Larson emphasizes that patience here is essential. The slow operation of structural solutions is inseparable from their durability. Quick fixes don’t stick because they depend on people sustaining unsustainable effort. Structural changes take time precisely because they’ are draining dysfunction and establishing a new equilibrium that people can maintain long-term.

(Shortform note: The temptation to abandon structural changes before they take full effect isn’t just impatience: It may reflect loss aversion, the brain’s tendency to feel losses twice as intensely as it feels gains. This bias is hardwired into three brain regions: the amygdala, which processes fear; the striatum, which anticipates events; and the insula, which reacts to disgust. For a manager watching their team continue to struggle during the time it takes for a structural fix to take effect, the brain treats any deviation from the status quo, including the change itself, as a potential “loss” to be avoided. The tactical alternative—asking people to work harder right now—can feel like relief from that discomfort, even when Larson would note it’s the wrong call.)

Finish What You Start

Finally, Larson emphasizes that you must make sure your team finishes the projects you start. Projects that remain unfinished create an ongoing burden for people while failing to deliver the benefits they were meant to achieve. An incomplete technical migration means engineers must maintain both old and new systems, doubling their workload and mental overhead. An incomplete reorganization leaves people confused about reporting structures and accountability. An incomplete performance cycle leaves people without closure about where they stand, creating anxiety that damages their trust in leadership.

Finishing everything you start requires discipline at two stages. First, commit to completing a project before starting it—for example, if you lack the resources or organizational will to finish a migration, don’t start and leave people stranded halfway through. Second, push through the difficult final phase. Larson notes that in engineering work, the last 20% of a project is typically the hardest because it involves unusual situations that don’t fit standard approaches. It may also involve politically difficult conversations that people have been avoiding. But that’s where problems accumulate if you stop, leaving people to manage the mess indefinitely.

Why Finishing Is Always Harder Than You Planned

Larson’s principles for finishing what you start—don’t leave projects half-done, only commit to what you can complete, and push through the final phase—ask us to act against deep-seated cognitive tendencies. The planning fallacy, explored by Daniel Kahneman in Thinking, Fast and Slow and Rolf Dobelli in The Art of Thinking Clearly, describes our tendency to estimate project timelines based on the best-case scenario instead of thinking more realistically about the edge cases, complications, and obstacles that almost always materialize. This is why the decisions you have to make and the problems you have to solve during the final 20% of any project come as a surprise: You never planned for it in the first place.

The cognitive cost of leaving those projects unfinished is higher than you might think. In what psychologists call the Zeigarnik effect, your brain treats incomplete tasks as open loops, cycling through them in working memory until they’re resolved. An unfinished migration or reorganization doesn’t just create a doubled maintenance burden; it also creates a cognitive tax on everyone who knows the work is unresolved. That said, there’s one useful exception: Making a concrete plan to finish the work can quiet the open loop. For managers stuck mid-migration or mid-reorganization, that’s a meaningful lifeline: You don’t have to finish everything today, but you do have to mean it when you say you’ll finish it.