Managing Humans - Review in Repose

One of the side-effects of having surgery earlier this week is that I've had time on my hands to get some reading done. I can't lift anything heavy yet and I'm having to take some pain meds... so my options are pretty much limited to reading, watching television, playing some Xbox, and using the computer. Even that last one can be dicey as I don't want to be anywhere near important code while taking these prescriptions. 

managinghumanscover On the reading front, I started reading "Managing Humans" by Michael Lopp (also known via his nom de blog, Rands) the other day and am nearly done with it now. The subtitle of the book is "Biting and Humorous Tales of a Software Engineering Manager", which I think provides a good idea of the book's overall "vibe".

I know I've mentioned his site, Rands in Repose, a few times in previous posts and it's one of the top feeds in my subscriptions. He writes from plenty of real-world experience on managing developers, development projects, and most importantly, managing organizations on behalf of those developers and development projects.

His is one of those sites that you go to as soon as you see a new post has arrived. The writing and insights are just that good... so when I learned he was publishing a book, I knew that it'd be a must-read.

A lot of the material in the book comes from his blog, though it's been re-worked to some degree to flow better in book form. The humor, edginess, and "bite," however, all remain intact. This is NOT your typical management advice book -- it's focused squarely at people who manage development teams that are building software products.

The book is broken into three sections --

  • The Management Quiver, where each chapter discusses tools (or "arrows in your quiver") for surviving the manager-employee relationship (from either direction). Detecting agendas, handling someone in the middle of a freak-out, and saying "no".
  • The Process is the Product, where processes and approaches for getting a product out are discussed. Status reports to monitor progress, capturing the context for work being done, and the all-important version 1.0.
  • Versions of You, which contains chapters that discuss the various personality types that are common in a software team. The Organics, the Incrementalists, and the Free Electrons. If you've been a developer (or managed developers) for any period of time, you can't read through these chapters without laughing out loud at the way he describes these familiar personalities.

The chapter on saying "no" is particularly hilarious, as it describes the process by which a manager becomes a manager -- essentially, pixies arrive and provide you with an elegant top hat that has the words "I'm The Boss" emblazoned on the front. Of course, the key thing that you don't immediately recognize as a new manager is that the back of the hat reads, "For Now." And so begins the lesson about a manager NOT being infallible and truly needing a team to push back for the improvement of the process/product/company. Team members forget the "For Now" part and let the title and position of "The Boss" get in the way of fighting for good ideas.

Saying no forces an idea to defend itself with facts. It forces a manager under the influence of his top hat to stop and think. Yes, I know that top hat can be intimidating, and yeah, I know he's the guy who signs the checks, but each time you allow your manager to charge forward with unchecked blind enthusiasm, you only reinforce his perception that he's never wrong. That's a ticket straight to Crazy Town.

As the subtitle suggests, the book is aimed squarely at software engineering managers. But one of the things I really like about his style is the dual angles for the advice he provides. While he's suggesting an approach for handling a problematic situation with your manager (the President, CEO, CTO, whatever), he's also providing advice on how to not be that problematic manager as you manage your own team.

The book does so well with this multi-angle approach, that I'd also recommend it for people other than engineering managers, including developers of all levels and non-technical folks who regularly work with a development team.