|summary||34 Anecdotes that give insight into silicon valley management and programmers.|
Know how many people I manage? Over a dozen, on a weekly basis. Know how many people report to me? None. So, why did I read it? Because I sit in a lot of meetings. I have to manage expectations. I have to write specs and reports for other people. Unless you work in almost complete isolation, receiving uber-detailed software specs and churning out code to match those exact specifications, the likelyhood is that you have to deal with other people. A lot. Every time you deal with someone else in a technical workplace, you run into other people. Their motives are not the same as yours, nor do they communicate the same way. In the first section of the book, "The Management Quiver", Lopp recounts 12 anecdotes, and two specific ones stood out. 'Agenda Detection' gives some points on how to figure out who the important people are in a meeting, and 3 tips on when to bail. 'Avoiding The Fez' points the spotlight on the guy who wrote that one system that no-one understands, but also calls out that too many people (and I find myself in this group) let their knowledge stagnate, instead of constantly learning and expanding.
The second section of the book, "The Process Is The Product", is, in my opinion where the book really starts to shine. "1.0" will be a familiar story for anyone who's ever tried to ship a product, as well as Rands' view on the 4 key things that it will take. "Taking Time To Think" and "The Soak" talk about absorbing ideas and planning, and he touches on ways to convey and disseminate information in "Capturing Context". This last one was another that I found informative — by getting a closer understanding of what kind of information the other party was expecting, and in what way they will be receptive to it.
In the third section, "Versions Of You", you'll see the people you work with, and Rands divides them out in lots of different ways (it struck me very much as almost a myers-briggs Nerd Scale). Are they Incrementalists or Completionist? Organic or Mechanic? Inward or Outwards? (For the record, I'm an OIC, An organic inward completionist.) And once you've identified someone, it makes communicating with them and identifying their motivations and reactions much better.
So, who should read this book? Managers. Technical Managers. Technical Peons. Programmers who are managed. Anyone who works with someone technical. Anyone named Fez. Odds are, if you're reading this review, you're in the target audience. Even when you look at a book like this and think "I don't need this, I'm not a manager." Odds are that you're being managed, and managing others, even if they don't report to you.
So, ultimately, why should you read this? I think that this book has a fair amount to offer just about anyone in a role in or dealing with technical talent. Does it answer everything? Of course not — but there are a lot of little nuggets hiding here, and above all, it is entertaining. More entertaining than The Mythical Man Month, and more applicable to my daily job than "SOA Is Dead, An Anthology".
This book has several Pros: I found it very relevant, and I was able to identify ways to improve my own communication, by understanding what the other person was expecting, and how to present it. Cons: Most of it is available free on Rands' blog.
You can purchase Managing Humans from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.