Managing Humans

Kylar writes "For those of you who have already discovered Michael 'Rands' Lopp's blog Rands In Repose, I congratulate you, as you are clearly an intelligent audience. For those of you who haven't, or for the less discerning (or, perhaps less blog-oriented), this book provides an excellent entry into the writings of Rands. Containing edited selections from his blog as well as new material, Rands uses many anecdotes and stories to convey a startling amount of deep wisdom into the facets of the Silicon Valley programmer, and a bevy of tools that are helpful in attempting to herd, er, manage them." Read below for Tom's review. Managing Humans author Michael Lopp pages 209 publisher Apress rating 8/10 reviewer Tom Byrne ISBN 978-1590598443 summary 34 Anecdotes that give insight into silicon valley management and programmers. I've read most of this book 3 times, the first when I discovered Rands' blog, (and, like few others, captivated me enough to start at the beginning and read his entire oeuvre), Once upon purchase of the book, and again, recently over the course of a few weeks, taking the stories out of order, and enjoying each for it's viewpoint, humor, and insight. The book is broken down into 3 major sections, 34 chapters, and each chapter is a small chunk, easily readable in a few minutes. It really feels like a blog, you can dip into it for a few minutes here and there and pick up a good point or two from each entry.

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.

Comments

Completely agree

[zollman]

It's easy as a technical employee -- developer, architect, administrator -- to know your job much better than your boss. Once you've reached that point, it's equally tempting to believe you know *more* than your boss, and to question why they insist on continuing to waste your time.

This book is an excellent first step in explaining what it is managers are supposed to be doing, and what it is that management is supposed to accomplish with the standard management tricks -- meetings, one-on-ones, reviews -- that can seem like such a waste of time when all you want to do is write good code. Even if you never want to go into management yourself, but especially if you do, it's worth reading.

Plus, the book is an easy, engaging read that makes a lot of sense even the first time through.

Highly recommended.

what?

[Lord Ender]

For those of you who ... I congratulate you, as you are clearly an intelligent audience.

This reads like a really sleazy sales pitch, along the lines of "Did you know that top billionaires take my supplement to boost their brain power?"

I stopped reading right there. I think I'll apply this review directly to my forehead.

Re:what?

[ByOhTek]

Aye. I would like to thank Kylar and his spectacularly incompetent/offensive introduction in encouraging me not to read this potentially good book.

Re:what?

[MagusSlurpy]

Definitely. I read the first sentence, and thought, "Who is this Rands guy, and why should I care?" Then the next two sentences didn't tell me who he was or why I should care. So guess what?

I don't care.

Re:what?

[LateArthurDent]

For those of you who ... I congratulate you, as you are clearly an intelligent audience.

This reads like a really sleazy sales pitch, along the lines of "Did you know that top billionaires take my supplement to boost their brain power?"

Not only that, but I actually went to Rands' blog and read the latest post just to see what could be so amazing about it. In there, I found more stupid marketing / management terminology:

In a good bridge, I see the defiant end result of how some of my favorite engineering stories begin:

• âoeIâ(TM)m sure you can arrange an impressive line of people who say itâ(TM)s impossible. I take personal joy in ignoring those who say no.â
• âoeYes, halfway through this project weâ(TM)ll discover the impossible, but we know how to build through the impossible. Impossible is when we do our best work.â

Nobody "discovers the impossible" but "knows how to build through the impossible." That's not what impossible means. But it sure as hell sounds impressive, and it excites people!

The ability to deal with obstacles, even very difficult obstacles is a very marketable skill. However, when you start talking about overcoming challenges as "doing the impossible" you stop sounding like someone who is actually capable of dealing with problems and starts sounding like a moron salesman. Especially when you later say something stupid like, "Impossible is when we do our best work." It might sound great when your favorite Hollywood hero says that he "laughs in the face of danger," but in real life, when you're managing people, if you dismiss a current challenge by saying, "that's when we do our best work" you'll piss your employees off. They know it's bullshit, they know they'd do better if it was easy and they had more time. You can tell them that you have confidence they can handle the problem, but don't dismiss the problem with levity.

Hell, even in his own example of the Brooklyn Bridge, he says that when they hit the challenges during the building process, the manager got the bends, two employees died, and they decided to let one of the towers rest on compacted sand instead of bedrock. Then he says how amazing it is that it was a good decision, because it "hasn't moved" since. Might have been a good decision, but "the best" outcome obviously would have been no injuries, no deaths, and a foundation that was built exactly according to plan. Clearly, they don't do their best work under "impossible" conditions.

You want some tips on managing programmers and engineers? I don't have all the answers, but I do have one for certain: that type of marketing pitch might work when you're meeting to sell the product, but programmers and engineers aren't like most people in that regard. Exaggerations like that are just likely to piss us off, not impress or motivate us. So you post a summary like that on slashdot, and you get a bunch of angry geeks; you try to manage people like that, and you get a bunch of employees labeling you as a PHB.

Re:"People", not "humans"

[Anonymous Coward]

It's called "managing humans" because it's written by an ex-software developer who, like other software developers, was good at managing code, bits, and other impersonal things, but needed to find out how to manage humans, which was totally out of his comfort zone.

It's full of humility and is about as far from your interpretation as you can get. But then again, the author is also one of the mob behind jerkcity, so LOL DONGS.

Okay, stop.

[girlintraining]

First, labeling people and sorting them into categories is a problem. Not because it isn't useful, but because the audience here is much more likely to view those as absolutes than guidelines. Whenever people start arbitrarily dividing other people into groups, they are certain to be mislead to a degree. A person's demeanor and work habits are not necessarily a reflection on their inner nature. Assuming that one is the other is a bad plan. Use labels, prejudices, stereotypes, and categories as a starting point. But don't stay there. Just because someone is an "organic inward completionist" this week doesn't mean you might not find out later while they're on break talking about a problem they're working on that the approach they are using is radically different.

Secondly, managing people (and working with management) is a skillset that is very individualized. There is no right or wrong approach. There is only what succeeds, and what still needs work. This book is useful because it condenses experience in a format that other people can benefit from. But remember when you read the book to keep your critical thinking skill "shield" up. Take frequent breaks. Don't zombie on it for fourty pages. Especially not anything that mixes technology and people. Because it's too easy to internalize all this stuff without stopping to think: "Hey, that doesn't make sense..." And a lot of personal experience doesn't make sense. There are lessons to be learned here and there, but what your takeaway is will be different than mine, even if we are in the same situation, and have the same experiences.

Re:Okay, stop.

[digitalhermit]

For those of you who have already discovered Michael 'Rands' Lopp's blog Rands In Repose, I congratulate you, as you are clearly an intelligent audience.

hehe.. +1 if I could...

So does this mean that I am intelligent because I've read it? What if I hated it??

I'm going to do the same and categorize anyone who agrees with me as intelligent. Anyone who does not is evil.

Choose a wise leader, or rather, a leader wisely

[barocco]

"The major problem -- one of the major problems, for there are several -- one of the many major problems with governing people is that of whom you get to do it; or rather of who manages to get people to let them do it to them.

To summarize: it is a well-known fact that thoes people who must want to rule people are, ipso facto, those least suited to do it. To summarize the summary: anyone who is capable of getting themeslves made President should on no account be allowed to do the job. To summarize the summary of the summary: people are a problem."

---- Douglas Adams

Re:Buy the book, reward good writing.

[Eudial]

You wrote the book, didn't you?!

Hmmm... I just ....

[johnlcallaway]

• Treat everyone with respect in public, and don't talk shit about them behind their backs
• Find out what people are good at and don't expect them to be good at things they are not.
• Give people things they are not good at to see if they can grow, but don't get upset if they can't.
• Set, manage, and understand expectations, in all directions
• Get rid of mean people, information hoarders, and selfish people, they are always poison and can't be changed
• Give others the credit, and always take the blame. Sort out the rest out in private.
• Suggestions are better than directives, use directives sparingly.

That will be $14.95 please.....

Re:Hmmm... I just ....

[rednip]

Those are the 7 commandments of 'Treating People Right in the Workplace'...

So, he knows the real first rule of management; Present the ideas of others as if they were your own.