Several months ago, everyone on my Twitter feed started talking about An Elegant Puzzle: Systems of Engineering Management by Will Larson, an engineering manager who has worked at Uber and Digg, and currently works at Stripe.
When it arrived, this book, published by Stripe Press, turned out to be one of the most beautiful books I’ve ever seen. (In fact, people tweeting their pictures of the physical book is what originally drew me to it.)
I mean, just look at it:
I feel like I should be photographing this book at a bespoke coffee shop next to a perfectly-crafted cappuccino with a heart drawn into the foam. My poor table (covered with the remnants of breakfast, crayons, and drool) is not worthy.
Look at the inside! The layout! The fonts! The kerning! The pictures! It’s so, so, so pretty. Picking it up makes you feel like you are a Serious Engineer, ready to read some Serious Thought-provoking Engineering Content that you will then impart upon your team, like Moses bringing down the tablets down from the mountain, if Moses worked in Cupertino.
But, the more I read this book, the more I was disappointed by the actual content.
I want to preface this by saying that as someone who’s been writing technical (and non-technical) content for a really long time online now, I know how hard it can be to write good stuff and then put it out there for the whole world to read and review. This is particularly hard when you’re working for a long time on a book.
I respect the amount of effort (and time spent at these companies and accruing this wisdom!) that Will spent crafting this work.
However, things started going south almost immediately in the first chapter, where we are presented with this visualization:
I looked at this picture for a very long time, trying to figure out what it meant. “I’m not smart enough for this book,” I thought. “Just as it is too classy and elegant for me, the visuals are meant for people of a higher caliber - people who program in Lisp and can pass dynamic programming interviews at Google.”
What does this mean? Is the square with the triangle inside of it the manager? What are all the other squares? What is the “well-sized manager of manager” text connecting?
For reference, I read the accompanying text, which told me,
“When I transitioned from supporting a team to supporting an organization, I started to encounter a new category of problems that I had never thought about. How many teams should we have?[…] It’ll be an unusual month that you won’t consider some aspect of team design.
The next page says, “Managers should support six to eight engineers.” Was that what was being referenced in the diagram? I still couldn’t tell, so I moved on. However, I was already (elegantly) puzzled. Why is the first chapter talking about how big managers should make teams?
If you’re writing a book about management, to people coming into management, the first thing you should probably do is to talk about what managers do on a day-to-day basis and how that relates to the team.
The text didn’t get much clearer for me from there on. The book goes on to talk about different states of a team, and the visuals don’t add much to explain what these different states are (can I just add that as a data scientist, the lack of y-axis labeling really stresses me out):
And the book goes on much in this vein: Very beautiful, but almost useless, visuals, accompanied by very abstract text that’s really hard to grasp at an individual level. For example, this one says it’s a “visual representation of a well and poorly balanced organization.” (Please pardon my creepy thumb.) All I’m seeing is a bunch of boxes.
It’s important to note that the subtitle of this book is “Systems of Engineering Management,” which means the author is talking about a very abstract approach, but I think that abstract approach is what makes the book, for me, very hard to relate to.
After I finished the book, I sat with it a while, and then I went on Twitter and Medium, where everyone has been praising it.
Cindy writes,
There are two common threads that run through every chapter of this book. First, the book distills valuable insights into high level frameworks that can be customized, instrumented, quantitatively evaluated and iterated upon to serve different contexts and needs. Second, the book provides the reader with tools and techniques that are lightweight enough to be able to provide immediate value without being too prescriptive.
Amazon reviews are equally glowing, with phrases like “success bible,” “prescriptive”, and “must-read.”
Did these people see the illustrations? Here’s another actual one from the book. What does it mean? (And can I phone-a-friend for an Uber engineer to help me figure it out?)
But, in spite of all of these things that puzzled me, everyone loved it.
Was I wrong? I thought about it for a long time.
Maybe my reaction said more about me than it did about the book. I’ve been digesting this book and the surrounding reviews and tweets for the past several months now, and I think I have several fundamental criticisms as to why it’s not for me.
1) Management as fantasy
I saw this quote on Twitter a bit ago and I can’t stop thinking about it (by the way, if you don’t already, you should follow @generativist).
It’s so entirely true. Management books are mostly not for actual managers. Actual managers are busy managing. (Except for Patrick, who, I’m guessing does not sleep and is a honest-to-god vampire, just constantly reading and #hustling.)
Or rather, managers at who this book is targeted, people with the power to manage teams of teams, change organizations, and report up to the C-level, don’t read books.
These people are on flights, at presentations, giving updates to shareholders, firing people, hiring people, looking at or charts and budgets, and generally just consistently too busy to read books like this. They simply don’t have time. They need bullet lists. Which is why there are entire services summarizing business book ideas.
(People at the C-level, prove me wrong and shoot me an email if you have read this book! Also, please give me some free credits for your SaaS service and a t-shirt.)
Most people who read management books, myself included, are not the high-level managers this book is targeting. However, that hasn’t stopped me from reading lots of management books. Over the past several years, not counting all the books I’ve read as part of my MBA program, I’ve also read: Mythical Man Month, High Output Management, The Manager’s Path, The Phoenix Project (which I reviewed for Normcore) and many, many more books that I’ve probably blocked out of my mind, about how to be a manager.
Why? Because it’s interesting. I want to know what the people I report to are thinking. I want to think about strategy. And, maybe, someday, I think, I’ll also be a high-level executive. Gotta be prepared. Never hurts, right? I’d wager that at least 80% of management books are purchased by non-managers thinking these same kinds of thoughts.
Aside from being generally aspirational, this book also encompasses only the author’s experience at fast-moving tech companies. This review from Gregely clarifies this:
An Elegant Puzzle is to date the most hands-on perspective on engineering management within a high-growth, tech-first organization, that I have read. It's a long overdue book for engineering managers and leads.
For me, reading the book was full of "aha!" moments. When I joined Uber, the Amsterdam office was 25 engineers. I started to manage 5 people when moving into engineering management. Three years later, the Amsterdam office is 150 people - doubling every year - and my team tripled. Many of the problems I faced are challenges the book discusses in detail. Challenges like setting a vision/strategy for my team, building a robust hiring and onboarding pipeline, or dealing with a never-ending stream of migrations.
For people who work in a similar environment like Will does, the advice is very relevant. These are places that are considered "top tier" companies, meaning the engineering environment is strong, leaders are technical, compensation is close to top-of-market, and engineering is a value-add, not just a cost center.
Most companies are not these companies. Like I’ve Normcorely said before, most tech runs on Java 8, waterfall, IT budgets that are constantly slashed and readjusted, and companies that are not making music services or smartphones or smart thermostats. Most companies are boring AF, and make solidly good money.
None of these strategies will work in those cultures, cultures where you have to have days of meetings to justify an extra engineer in headcount, companies where developers are not given admin access to their computers, companies where IT is still seen as an afterthought.
But the book doesn’t acknowledge that. It doesn’t start with a huge preface that says, hey, if you’re working at Uber or Stripe and managing teams, but don’t really care about the day-to-day implementation details as much as the abstract view, (and also like beautiful but very puzzling diagrams) you’ll love this book!
By making this book for everyone, it’s almost for no one.
2) Books from blog posts don’t convert very well
The second problem with this book is that, as I mentioned, I noticed that the chapters didn’t flow well together. I had a hard time connecting the dots. After some research, I learned that this book had come together from his blog.
Generally, books being put together from blogs can be really tricky, unless you do it right. I should know - in 2012, I decided, as an experiment, to create an ebook from a series of travel blog posts I wrote about Scotland (please don’t read this book. It’s terrible.) The book came out just ok, and I learned a ton about how ebook publishing and revenues work in the process, but the hardest part was reorganizing the content and tone in a way that made sense for a continuous text rather than a series of unrelated thoughts.
Synthesizing a lot of different ideas into one big one is always the absolute hardest part of writing. I wrote in my Goodreads review of Elegant Puzzle that it felt fragmented.
The content was taken from blog posts, and as such, does not form a cohesive narrative, but is instead chapters upon chapters of bite-sized bullets that are hard to remember and don't tie together well.
The organization of the book is strange: it starts off by talking about how many people you should hire if you're managing managers. This is not applicable to most people reading the book, unless you're a c-level exec, and if that's the case, you're definitely not spending time reading this book, you're too busy. Most people come into management through promotion, and have no idea what to do They also don't immediately have the power to hire 8-10 people, or change anything about the team size. I'd have liked to see this book tackle the subject from that approach.
In a similar vein, I felt that Manager’s Path also struggled with this:
I hate to say that this book was disappointing because I enjoy following the author on Twitter and have enjoyed lots of her clear, well-written blog posts about management and technical strategy, particularly ones like "how do individual contributors get stuck".
I think this book essentially tried to stretch those blog posts into an entire volume, which doesn't quite work. There is a lot of repetition of concepts, and even though the book is clearly organized according to the table of contents, it doesn't seem to follow any particular logical pattern when you're in the weeds.
The problem is that blog posts, like newsletters, are fragments of thoughts, jotted down while you’re thinking about every day life. They’re not holistic systems that need to constantly reinforce a single message. It takes a lot of work to get them to that point. I don’t feel like Elegant Puzzle quite got there.
As an additional aside, the voice of the book was really uneven, switching from formal to informal very quickly, another symptom of a bad blog-to-book conversion.
3) The Tyranny of Modern Workplaces
Finally, one of the biggest problem for me was the lack of concrete examples, just abstraction. I wanted to know about the author’s actual experience at Uber and Digg and Stripe. What were the actual problems that he faced that led him to the thoughts that formed this book? What databases went down? How much budget did he have to ask for? How big were his teams? Who did he have to fire, hire, and convince? The few examples he did include did a lot to color in those details for me, but there were only two or three.
Obviously, this is not something we can get out of any management book, and that’s an enormous shame.
This is an issue larger than Elegant Puzzle. Just yesterday, I came across the review for a very intriguing book, called “Private Government: How Employers Rule Our Lives (and Why We Don't Talk about It).”
The blurb reads,
In many workplaces, employers minutely regulate workers' speech, clothing, and manners, leaving them with little privacy and few other rights. And employers often extend their authority to workers' off-duty lives. Workers can be fired for their political speech, recreational activities, diet, and almost anything else employers care to govern.
When reading this, something clicked for me. We can’t write the details simply because we are blocked from our employers, both legally and culturally, from doing so. Sure, Will could have written about that time that his team brought down production (purely hypothetical scenario), but Uber probably wouldn’t like it. Not only would there be a lawsuit, but his former team members could come out and say that he was wrong to talk about it, other people would be reticent to hire him for their companies, and so on and so on.
So we’ll never get the truth about what actual incidents contributed to this book, which is a real shame, because actual specific examples and actual case studies are what new managers need, much the same way doctors do residencies and operate on actual patients and see hundreds of different cases before going into practices.
However, we could have gotten at least some few details, which we didn’t.
Finally
Ok, here we finally are at the end. What I’ve found from Elegant Puzzle, and other books like it, is that management books won’t tell you how to be a manager, in the same way that the owl drawing won’t tell you to draw an owl.
There are too many assumptions, not enough details, skipped connections because of being drawn from different, various blog posts, and, mostly, these books, because of the level of abstraction, are aspirational.
What makes an actual good management book? My favorite management books have been either actual case studies, biographies, or fiction books. I’ve plugged Shoe Dog a number of times now, and I’m going to plug it again, because it reveals exactly what you don’t want in a manager. Bad Blood is also an excellent example of a good management book as an anti-pattern. Both are filled with excellent details, and neither are drawn from blog posts, but written as biographies, or by journalists keenly interested in tying a story together.
Ultimately, you’re better off finding friends who are managers and talking to them over coffee. I’d read a book on how to do that.
In the end, I admire the effort that went into producing this book, but it was, honestly, just not for me. Although it makes a beautiful conversation piece on my stained kitchen table.
What I’m reading lately:
An interview with the 30-50 feral hogs guy! Insanely wholesome and good.
A post about babies at the office
What it’s like to run a newspaper in the Arctic.
Ok, this new zine just looks super-cool.
About the Author and Newsletter
I’m a data scientist in Philadelphia. This newsletter is about issues in tech that I’m not seeing covered in the media or blogs and want to read about. Most of my free time is spent wrangling a preschooler and a newborn, reading, and writing bad tweets. I also have longer opinions on things. Find out more here or follow me on Twitter.
If you like this newsletter, forward it to friends!
