A quick disclaimer: Jack Danger, the author of Executive Engineering, is a friend and former colleague. We worked together as fellow engineers and engineering managers at Square, and our paths have crossed serendipitously in subsequent years as we travel in the same circles within the tech industry—really the startup ecosystem—in the Bay Area. The impressions here are from a pre-publish copy that Jack generously sent over, but I’ve purchased my own physical copy for reference and to fill up the bookshelf.
Basically, Jack’s a great dude, but our friendship does not influence my thoughts on his book.
Executive Engineering: Practical Engineering Theory for Software Leaders is a manual written for engineering managers/executives, by an engineering executive, about how to operate as, uh, an engineering manager/executive. It reminds me a bit of another book written by and for engineering managers, An Elegant Puzzle, in that it provides operational advice garnered from years of experience across a breadth of organizations. In fact, I’d apply a similar critique: the experience and therefore applicability of this advice is scoped to a particular moment in space and time—the roaring 2010s of Silicon Valley tech—and it’s unclear how much and which parts still resonate here and now1.
The book introduces a lot of concepts, strategies, and tactics that feel familiar. As it turns out, when you are in the business of building and selling software, the organizational structures, processes and dynamics fall into predictable patterns, like the cited “EPD” triumvirate of Engineering-Product-Design, or the analogy of technical debt as financial debt, complete with interest calculations. It’s not completely clear to me why all these disparate organizations end up with the same mental models—if it’s simply Silicon Valley cargo culting through generations of startups, or if it’s actually a reflection of how to develop software with groups of humans.
By a third of the way into the book, Jack advances his central thesis: Technical Coherence2, as it pertains to engineering organizations. I won’t spoil the meat of the theory, but it attempts to explain the common, bimodal configuration of Product and Infrastructure/Platform teams: how it comes to be, where the friction points tend to exist, and why it’s often suboptimal in throughput and delivering business value. I’ve seen this pattern enough—both from personal experience, but also in many conversations with other CTOs and VPs—that I’m well-convinced of the problems described.
Presentation-wise, Executive Engineering is an easy read. The chapters are fairly short, and there are plenty of explanatory diagrams sown throughout the prose to visualize the patterns described and the frameworks applied. There’s also an analogy to flight and airplane engineering that runs throughout the book—hence the diagram of an aircraft on the cover. In the final chapters, there’s a quick-fire collection of tips and tricks that read as mini-blog posts, with the caveat that the conclusions are largely anecdotal, but perhaps useful to those managers who are looking for advice on everything from work chat etiquette to meeting documentation.
I agree with a lot of the observations and ideas in Executive Engineering. Having worked for the same company, not to mention within the same small metropolis with an over-concentration in the same industry, that we would come to similar conclusions on effective management isn’t a huge surprise. The central theory of Technical Coherence, I think, is a good one; it’s an apt diagnosis of a common problem in engineering organizations, and I’m now curious to hear whether some of the solutions described here have the intended consequences.
