Book review: An Elegant Puzzle

I’ve been reading Will Larson’s blog, lethain.com, for a couple of years, mostly because it’s one of the few places that writes about engineering management as if it were an engineering problem. So when Stripe Press announced it was turning the blog into a book, An Elegant Puzzle: Systems of Engineering Management, I preordered it, and it showed up the week it came out at the end of May.

Fair warning on what it is. It’s a collection, and you can tell. A lot of chapters are a few pages long, some of them read like the blog post they started as, and there’s no single argument running through it. If you want a narrative about a manager’s journey, read something else. If you want a reference you’ll keep opening when a specific problem lands on your desk, this is that.

The part I’ve already used is the section on sizing teams. His numbers are that a manager should support six to eight engineers, that a team smaller than about four isn’t really a team (it can’t absorb a vacation or an on-call rotation), and that a manager of managers should have four to six reports. None of that is new, exactly, but I’d been making those calls by feel for about ten years and it’s nice to have someone write the reasoning down so I can argue with it. We have one team at three people and one manager at eleven reports right now, and I’ve known both were wrong. Now I have a page I can hand to the CEO.

The chapter I’d tell everyone to read is the one on the four states of a team. A team is either falling behind (the backlog grows every week), treading water (keeping up, but with nothing left for improvements), repaying debt, or innovating. His argument is that each state has a different fix and that most of us apply the wrong one. A team that’s falling behind needs more people, and pretty much nothing else works. A team treading water needs you to cut its work in progress so it can finish things, not more people. A team repaying debt mostly needs time, which is the hardest thing to give it because it looks like nothing is happening. I read this and immediately put each of our teams into a box, and I got one of them wrong. I’d been treating it as falling behind, but it’s treading water. Hiring for it would have made the next six months worse.

The migrations chapter is the other one I underlined. His claim is that migrations are the only fix for tech debt that scales, and that you run them in three phases: de-risk (prove it on the hardest few teams first, not the easiest), enable (build the tooling so moving is cheap for everyone else), and finish (the last 10% that nobody wants to do and that you have to actually own). We have two migrations sitting at about 80% right now, which according to this book is a very normal place to be stuck. I’ve got a plan for one of them.

What I liked less: the systems-thinking chapter, stocks and flows, is a bit thin if you’ve read Donella Meadows and a bit abstract if you haven’t. The careers section, ladders and performance cycles and so on, is sensible but felt like it was written for a company with a few hundred engineers. Some of it doesn’t translate to a startup where the ladder is a page I wrote and the performance process is me and a spreadsheet.* And the book’s tone is a little detached for my taste. People mostly show up as numbers in a sizing model. That’s partly the point of a “systems” book, but the hardest management problems I’ve had weren’t about systems.

It’s also, I have to say, a beautiful object. Stripe Press makes nice books. It’s the first management book I’ve owned that I’m happy to leave on my desk.

* Larson was at Uber and is now at Stripe, so that’s not a criticism exactly, just a note on who the book is for.