Book Review: Engineering Management for the Rest of Us

In the book Peopleware: Productive Projects and Teams, the authors Lister & DeMarco waste no time in establishing the big picture. By the 15th page of the book, they cite a Billy Joel song to remind the reader that no amount of workaholism or perfectionism is going to matter in the end. A somewhat dark yet poignant lyric sets the tone for the remainder of text: how can we make the very best of a journey whose destination we all share?

Thirty-five years after that book was written, we're still just trying to figure it out. "People" are hard – and though a software developer is unlikely to turn away from a challenge, managing people cannot be solved with the same side of the brain that writes a recursive function. The common theme among all these texts is that the "problem of people" requires nuance and adaptation, while considering for the person, the situation, and the culture of the organization. That paradox of ambiguity and ultra-specificity results in two types of books: those painting broad strokes (often in allegory) that restate themes we already know, and those delivering actionable solutions for situations most likely to occur in our world. An author definitely wants to be in the latter category; the former are simply banking on the fact they can hide they're no further along in "figuring it out" than the rest of us.

That's why I was very excited to hear about Sarah Drasner's book: Engineering Management for the Rest of Us. I've been following Sarah on Twitter for awhile now; her promulgations and confessions have always been firmly grounded in the day-to-day realities we face behind the software development curtain. A collection of her thoughts -- bound, printed and delivered to the masses – therefore made logical sense. I had high hopes the moment I read the back of the back of the book which states, "This book isn't for the 'Born Leaders.' This book is for the rest of us."

So...is it?

Engineering Management is broken out into four sections that focus on key areas where we live in software development management: the care of the people that report to you, effective communication with that team (and peers), key improvements you can make to managing projects themselves, and where best to focus your own energy. Each section takes care to outline why this area of management is important as well as what you need to do in order to be effective. There are many valuable examples across these sections; in order to stay focused, I'll point out a few that resonated with me.

Setting your own team up for success requires establishing a great deal of trust between you and those reporting to you. "Psychological Safety" is a term touted by many as necessary, yet nobody does a great job at articulating how it is attained. Drasner does a great job at giving specifics (with examples) at the many parts of this puzzle, even if it boils down to something as simple as a "team-only channel" in Slack where members can go to vent frustrations – all the more necessary given that our developers very often fit the trope of introverted, awkward, and quiet. Stereotype as it is, Drasner makes it clear this is a journey that, like a garden, takes concerted care and constant maintenance to bear fruit.

The importance of the one-on-one (1:1) meeting with direct reports is oft discussed in management circles, yet few dive into the details of what makes a 1:1 effective. It is a subject often glazed over, yet Sarah outlines (with explicit imperatives) what need to be accomplished at a 1:1 to be truly effective (hint: it's not about the manager!) I've been in 1:1s where it is clear the person I report to has no understanding of what the meeting is even meant for. Sarah's details read like a breath of fresh air.

I was particularly pickled by Sarah's use of diverse reference material. There are a wide variety of viewpoints cited in making her case. It's refreshing to see an author dedicate an equal amount of time leveraging Psychology as they do the "Agile Manifesto." So much of our industry hyper-fixates on JIRA boards, user story points, and velocity reports to extract productivity insights; by contrast, Sarah advocates an unorthodox approach – actually talking to people. More of us would do well to listen to that advice.

One thing Engineering Management does very well is provide so many specific tactics to resolve situations that arise, day-to-day. The third section of the book is packed full of step-by-step processes outlining things you're probably doing now...just not very well. You can't align a team on a goal if you can't tell the difference between an Objective and a Key Result, so Drasner makes certain to clarify. The chapters dedicated to refining scope, how that translates to actual pull requests, and how one best manages the priorities between those of Engineering and Products teams alone are worth the cost of the book.

Engineering Management reads very much like a guide, providing steps to follow and points to consider at each emerging scenario. Again, I harp on the how, because so many management books gloss over the details, freeing the author to implement something radically broken while thinking they are following the path. How does one handle technical debt? What specific elements of a migration project should be communicated? It's sections like these that lift heavy loads for developers-turned-managers.

It's difficult to find fault with this book. At first glance, I wanted to criticize its lack of attention to "managing up," a diabolical yet crucial part of managing teams. Yet as I reviewed each section, I found many nuggets of context-specific communication advice that constitutes managing up. Anyone in the middle rungs of a software organization will tell you: communicating expectations up the ladder is one of the hardest parts of the gig to get right. And because she's on top of her game, Sarah outlines the communication strategy in nearly every section dives into.

If pressed, one might argue there isn't enough attention spent on the final section, the care and nurture of one's own mental resilience and productivity. Drasner does drop hints that it is important to push yourself beyond your boundaries, as that is where growth happens. Yet our industry has fallen in love with the "hustle" culture, and this could very easily bleed into techbro-style posts of waking up at 4am in order to be successful. Perhaps a more thoughtful, introspective approach to define the difference between healthy vs unhealthy boundaries might be in order. I know (and care about) a few workaholics that would benefit immensely from this insight.

A final thought, while I'm in criticism mode: the next edition of Engineering Management ought to have an entire section dedicated to unhappy paths and what must be done when those situations unfold. If the current wave of tech layoffs in the news is any indication, there are a great deal of technical managers still operating under cold, formulaic edicts. I shouldn't have to suggest that Sarah spell things out in exquisite detail under a to-be-written chapter titled "How to Lay People Off with Dignity and Respect," but as with many unspoken rules in the tech sector, not stating something explicitly often acts as an excuse to behave badly.

The fight goes on. If you're ready to join that (engineering management) fight, and want to arm yourself with a valuable set of weapons, I highly recommend reading Engineering Management for the Rest of Us today. You can do this more thoughtfully, more effectively, and with a deeper level of human connectivity than you already are. So long as you never forget: Vienna waits for you.