One nice benefit of not having any job lined up is that there is more time, outside of household chores and virtual schooling, to read and listen to podcasts, catching up with my backlog of to-be-consumed media. It’s delightful—at least in the short term—to reclaim a day’s hours previously devoted to work1 and reallocate the time to lessened rigor and structure, a leisurely pace less beholden to immediate business results. It’s too bad that sabbaticals are no longer common; the extended break is really meant to provide a respite and broader perspective which I can only now capture via unemployment.
Anyway, I’ve been wanting to read An Elegant Puzzle: Systems of Engineering Management for a bit now. In the vein of other books on management with an unapologetic focus on the software industry and its practices, An Elegant Puzzle lists out a number of topics, and details some of the problems and suggested solutions within, mostly guided by the author’s own experiences or those of his peers. The “systems” subtext refers to the author’s propensity to think in frameworks, both in categorizing problems as well as systematically applying solutions. It jives well with my observation that success in higher levels of management often requires constructing and fitting mental models to discrete instances.
With that context, folks suggest to treat this book more as an instruction manual, flipping to the chapter most relevant when you need that additional support. The author implicitly endorses the approach, describing his content here more as a collection of topics, a lot of which originally resided as blog posts on management. The effect is that aspects like culture and organization and hiring are compartmentalized, which makes for easy reading, but undersells the interconnected nature of many of these domains. The structure reminds me a little of the game Go: players can focus on individual parts of the board, but ultimately the game involves the entire 19×19 grid and all those initially separate parts inevitably connect to the whole.
One consideration that gnawed at me as I read through An Elegant Puzzle was that much of the problems, and therefore solutions, presented in the book were primarily informed by a set of similar companies: Digg (which ended up not really working out), Uber, and Stripe. That is, the ideas have been created and battle-tested against a set of fast-growing startups, in Silicon Valley, flush with investor capital, in the software environment of the 2010s. Granted, this overlaps with my own shift to management and the set of tools I’ve developed for myself, but I’m very cognizant of the fallacy of overindexing to a moment in time and space. It’s worth examining, and understanding, the underlying factors that inform these solutions.
In that sense, it reminds me a bit of The Manager’s Path, a book written by another engineering executive about management best practices based primarily on their own experience elevating through successful tech startups. It’s not that I think their advice is invalid—I’ve independently made many of the same conclusions—but I’m wary of creating a bubble around engineering management. That is, while software engineering as a discipline has its own quirks2, we should resist not invented here syndrome and seek to learn from good management principles, regardless of where they originate. It’s one of the reasons why I really like The Leadership Pipeline; it’s a great book for learning how managers, across all industries, hone their craft.
That caveat aside, An Elegant Puzzle is a good reference, covering a lot of the tactical aspects of engineering management. The emphasis on systems enables a powerful way of thinking, and the author makes a strong case in applying these systems across the myriad of issues that managers typically encounter. It’s highly practical, which is more than what most management books can offer.
And growing startups have a tendency to consume their fair share of those hours, despite my own efforts to take time out for non-work activities.↩
E.g., the combination of labor demand outstripping supply, and the lack of professional certifications for most aspects of software development, has led to exam-like interview processes, which in turn has created its own cottage industry of interview prepping.↩
