Margin Notes Ep. 1: An Elegant Puzzle — When Engineering Is a Moral Act

Show: Margin Notes Episode: 1 Book: An Elegant Puzzle: Systems of Engineering Management by Will Larson Publisher: Stripe Press (May 2019) · Hardcover, 288 pages · ISBN 978-1732265189 Recorded: 2026-05-12 Duration: ~20 minutes

Here's a question I want you to sit with for a second: when was the last time your team was actually innovating?

Not shipping. Not surviving the week. Not chipping away at a backlog that somehow keeps growing. Actually innovating — building something new, with slack in the schedule and morale high enough that people are excited to come to work.

If that question made you uncomfortable, good. That's exactly where Will Larson starts.

Welcome to Margin Notes — the show where we close-read one Stripe Press book every week and pull out the ideas that actually matter for people building small software businesses.

I'm your host. Each week we pick up one book from Stripe Press's catalog — a pretty remarkable list, by the way, that runs from engineering management to economic philosophy to the oral history of AI — and we read it closely, together.

For this first episode, we're starting with An Elegant Puzzle: Systems of Engineering Management by Will Larson. Published by Stripe Press in 2019. 288 pages. And to give you a sense of how the engineering community received it: four-point-five stars on Amazon with over thirteen hundred ratings, and the top-ranked book in its category. Gergely Orosz, who writes the Pragmatic Engineer newsletter, called it the most hands-on perspective on engineering management in a high-growth organization that he'd ever read.

That's a strong endorsement. So let's see if it holds up.

Before we get into the book itself, let me tell you a bit about how this thing was written — because the process is almost as interesting as the content.

Will Larson has been writing about engineering management on his blog, Irrational Exuberance — that's lethain.com — since 2007. By the time he sat down to write this book, he'd published something like five hundred posts over a decade. In 2018 he set a goal of writing one post per month. He ended up writing around seventy.

Most of those posts became book chapters. He wrote them in Markdown with a custom script that converted to LaTeX. One or two sections per week, early mornings and weekends, about eight hours a week. And when the manuscript was done, Stripe Press came in — not with a proposal, the way most publishing works, but with a completed draft — and bought it outright. That gave Larson what he described as extraordinary latitude over format, approach, and marketing.

His career trajectory is worth knowing too. Yahoo, then Digg, where he led a fourteen-person infrastructure and UI team. SocialCode, then Uber, where he scaled the SRE and Platform team from five engineers to over seventy while the broader Uber Engineering org grew tenfold to two thousand people. Then Stripe as Head of Foundation Engineering, running a hundred and seventy engineers across San Francisco, Dublin, Seattle, and remote. After that, Calm. Then Carta. Currently CTO at Imprint.

The book draws from all of that — specifically the Digg, Uber, and Stripe years. When he says something worked, you have a reasonable sense of what scale and context he's talking about.

Okay. The book itself. Seven chapters: Introduction, Organizations, Tools, Approaches, Culture, Careers, and an Appendix. Larson explicitly says they can be read in any order, and that's true — each section is relatively self-contained. It reads more like a collection of essays than a single sustained argument. We'll come back to whether that's a feature or a bug.

The central thesis is this: engineering management is not a collection of soft skills. It's a discipline that can be approached with the same analytical rigor you'd bring to a hard technical problem. Systems thinking — stocks, flows, feedback loops — is the methodology. And pretty much any difficult management problem is worth trying to model as a system before you try to solve it.

Larson writes: "Once you start thinking about systems, you'll find it's hard to stop. Pretty much any difficult problem is worth trying to represent as a system, and even without numbers plugged in, I find them powerful thinking aids." That's the spirit of the whole book.

Chapter Two is called Organizations, and it's where most people open their notebooks. The core is team sizing — and Larson's rules here are specific enough to be genuinely useful.

Managers should support six to eight engineers. Fewer than four and you're a tech lead manager — you're still coding, you're not fully managing. More than eight and you've become a coach and a safety net rather than someone who actually knows what's going on.

Managers of managers should support four to six managers. And on-call rotations? You need eight engineers for a sustainable two-tier rotation — otherwise people burn out covering nights and weekends.

Here's the one that surprised me when I first read it: teams with fewer than four people are, in Larson's words, not teams. He says: "I've sponsored quite a few teams of one or two people, and each time I've regretted it. To repeat: I have regretted it every single time." That's the kind of sentence you only write if you've actually learned it the hard way.

For indie developers who are used to building alone or in pairs, this raises a real question. When does a project stop being a solo effort and need to become a team? Larson would say: when you need it to be sustainable, accountable, and resilient to people leaving — and that requires at least four people.

The other big contribution of this chapter is the Four States of a Team. It's a model of where any team sits at any given time, and what that state requires from a manager.

State one: Falling Behind. The backlog is growing faster than the team can ship. The fix is hiring — but Larson is careful to say you need to hire deliberately, not spread resources thin across multiple struggling teams. Fix one team at a time.

State two: Treading Water. The team is getting critical work done, but that's it. No innovation, no debt repayment, just heads above water. The fix is to reduce work in progress — pick fewer things and finish them.

State three: Repaying Debt. The team finally has enough bandwidth to address the technical debt that's been slowing everyone down. The fix here is simply time — protect the team from new demands so they can actually pay it down.

State four: Innovating. Tech debt is low, morale is high, the team is building things they're excited about. The fix — and this is counterintuitive — is to maintain slack. Don't fill every hour. Reserve about twenty percent for exploration, or you'll slide back to treading water within a quarter.

One thing Larson emphasizes: move scope between teams, not people. When a team is struggling, resist the urge to shuffle engineers around. A gelled team that knows how to work together is one of the most valuable things you have. Re-gelling costs are real.

Chapter Three is called Tools, and it covers a lot of ground — systems thinking, metrics, migrations, and re-orgs. I want to spend some time on migrations because I think this is the most underappreciated insight in the whole book.

Larson writes: "Migrations are usually the only available avenue to make meaningful progress on technical debt." And the observation that follows is one of those things that should probably be posted on the wall of every engineering office.

Systems survive roughly one order of magnitude of growth. If your company is doubling every six months, every system will need to be reimplemented twice every three years. That's just math. The real productivity killer is not the rewrite itself. It's the migration that comes after — when you have to move everything from the old system to the new one, and you've designed that migration badly.

His migration playbook has three phases. First, de-risk: run the new approach in parallel with the old one and prove it works. Second, enable: build tooling that makes it easy for the rest of the organization to migrate — you want to handle ninety percent of cases automatically. Third, finish: deprecate the old system and make sure every new code path uses the new approach. The goal is to eliminate the old system entirely, not let it linger.

The chapter also covers metrics and goal-setting. A good goal has four numbers: a target, a baseline, a trend, and a timeframe. That's not four optional components — all four. If you don't know your baseline, you don't know if you're making progress.

And on re-orgs: "The best kind of re-org solves a structural problem. The worst kind of re-org is done to avoid a people management issue." I've seen the second kind go badly more times than I'd like to count.

Chapter Four: Approaches. This is where Larson gets into the harder stuff — how to say no, how to think about your personal management philosophy, and the ways managers get stuck.

There's a section on working the policy rather than the exception. When you keep granting exceptions — this team gets a different deadline, that person gets a different title — you're creating what he calls exception debt. The right response is to fix the underlying policy, not make another exception. Collect the escalations, look at the pattern, and update the rules.

Saying no is framed entirely in terms of constraints — not preferences. "I can't prioritize that right now" isn't an opinion; it's a statement about capacity. There are only two ways to add capacity: move existing resources, or hire. Everything else is wishful thinking.

Then there's this: Larson says management is, at its core, an ethical profession. That's not throwaway language. His argument is that managers leave a broad wake — the way you treat someone who isn't succeeding, the culture you create, whether you give people real opportunities or just tell them they have them — all of it compounds over time. And you often don't see the damage until it's already done.

He also has a section I found genuinely useful called "Ways Engineering Managers Get Stuck." He distinguishes between new managers and experienced managers, which is smart — they get stuck in different ways.

New managers: only looking up or down, never sideways. Optimizing locally without regard for the broader system. Not building cross-functional relationships. Defining their role too narrowly.

Experienced managers: trying to replicate what worked at a previous company. Spending so much time on relationships that they're not actually managing. Abdicating rather than delegating — the two feel similar but are not at all the same. And becoming disconnected from the day-to-day reality of their teams.

The one that crosses both groups: mistaking team size or title for impact. This is endemic in tech. Bigger team, more impressive title. But Larson points out that impact often has very little to do with headcount.

Chapter Five is Culture, and according to every reviewer who has written about this book in depth, it's the chapter that sticks with people the longest.

The central move here is the distinction between two things a good organization needs to provide: opportunity and membership. Opportunity is access to professional success — the chance to do high-visibility work, to get promoted, to grow. Membership is being able to show up as a comfortable version of yourself. Larson argues that structured process is the most effective way to deliver both. Not vibes. Process.

The section on making your peers your first team is the part I keep coming back to. The default for most managers is to think of their immediate reports as their first team — the people they protect, advocate for, and prioritize. Larson argues that this is actually a trap. When you treat your peer managers as your primary team, you get better information, faster coordination, and a culture where people help each other solve problems instead of competing for resources.

He puts it this way: "Long term, I believe that your career will be largely defined by getting lucky and the rate at which you learn. I have no advice about luck, but to speed up learning I have two suggestions: a rapidly expanding company, and make your peers your first team." That's a pretty clean formula.

Then there's "Kill your heroes." The section on hero culture is blunt. In engineering teams, heroism — the person who stays up all night, saves the launch, fixes the outage singlehandedly — is usually a sign of a broken system, not a strong team. The hero absorbs the dysfunction of the system and makes it slightly survivable. But they also make it impossible for the system to improve, because the pain is always being managed away just in time.

Larson writes: "A deeply flawed system can't be saved by bandaids, but can easily absorb your happiness to slightly extend its viability." That is a sentence worth memorizing.

Chapter Six covers Careers — hiring, performance systems, and how to build roles that last. A few things worth pulling out.

On hiring: don't hire for potential. That's Larson's rule, and he's clear about why — it's a major vector for bias. Potential is subjective. What you're really doing when you say "high potential" is projecting your own background and experience onto a candidate. He advocates hiring for demonstrated skills and current needs.

On performance systems: this is where Larson says something that's easy to miss. "If you want to shape your company's culture, inclusion, or performance, this is your most valuable entry point." Not your all-hands. Not your values doc. Your performance management system. How you measure, how you evaluate, who gets promoted and why — that's the real culture document.

He also has a useful taxonomy of what goes wrong with career ladders over time: designation momentum, where people keep getting promoted to avoid difficult conversations; tit-for-tat level trading between managers; and level creep, where the titles inflate until they lose meaning. Anyone who's worked at a company past Series B has seen at least two of these.

Now let's take the honest look. This book gets strong praise — and it deserves most of it — but there are real criticisms worth sitting with.

The blog-to-book transition is choppy. This isn't a secret — Larson basically acknowledges it. The chapters read like polished essays that have been put next to each other rather than woven together. If you come in expecting a sustained argument that builds chapter by chapter, you'll be frustrated. If you come in expecting a practical reference — something you open to the chapter you need right now — you'll be fine.

The diagrams are weak. This is a common complaint, and it's fair. For a book that puts systems thinking front and center, the visual representations of those systems are surprisingly underdeveloped. Some reviewers used words like "faux-scientific." The writing is strong enough to carry the argument, but the diagrams don't add much.

There's also a Silicon Valley gravity to this book that's real. The frameworks were designed for high-growth, venture-backed tech companies — teams doubling every year, migrations happening constantly, re-orgs every six months. If you're running a small, stable software business that grows ten percent a year, some of the advice is too hot for your situation. You have to scale it down, and the book doesn't really help you do that.

Finally, the systems thinking section is genuinely too brief. Scott Brady, an engineering manager who wrote a detailed review, put it well: the book references systems thinking constantly, invokes it as the backbone of the whole approach, but barely scratches the surface of what systems thinking actually is. If you want depth on that, Donella Meadows's Thinking in Systems is the real source — and Larson recommends it in the appendix.

Let me leave you with what I think is the real gift of this book — the thing that's hard to find anywhere else.

Most management writing either tells you generic truths — communicate clearly, build trust, set goals — or it tells you war stories that are too specific to one company at one moment to transfer. Larson operates in the middle. His frameworks are specific enough to apply immediately and general enough to survive a change of context.

The four-state team model alone is worth the price of the book. If you can look at your team and honestly say which state you're in — and if you can name the correct system fix for that state — you already know more than most engineering managers.

For indie developers specifically: you might not have six engineers on your team. You might not have a manager of managers. But you absolutely have technical debt. You absolutely have to say no to things. You absolutely have to decide who does what kind of work, and whether the team you have is gelled or falling apart. The scale differs; the underlying problems don't.

One concrete takeaway to act on this week: map your current team to the four states. Where are you? Falling behind? Treading water? And then ask: what's the actual system fix for that state? Not the workaround. The fix.

An Elegant Puzzle is available from Stripe Press in hardcover, on Kindle for about ten dollars, and on Audible. Most of the original blog posts that became chapters are still free on lethain.com — so if you want to test-drive the ideas before buying, that's a legitimate way to do it.

That's it for episode one of Margin Notes. Next week we'll be opening another book from the Stripe Press catalog and reading it closely with you. If this landed, tell someone who's building something.

Thanks for being here.

Episode audio: output/final.mp3

Theme music: "Margin Notes Theme" — generated original instrumental music (fal.ai / MiniMax Music v2.6, instrumental mode). Acoustic guitar fingerpicking with light piano accompaniment, ~70 BPM, no lyrics, no vocals. Generated for this show and not derived from any existing recorded work. Used as intro (0–12 s), low-volume background loop throughout, and outro fade (final 12 s). No third-party copyright claim applies.

Voice synthesis: All narration synthesized with MiniMax Speech-2.8-Turbo via fal.ai, using the English_CaptivatingStoryteller system voice. No voice clone or identity replication was used.