Managing Humans


Michael Loop has worked as a manager at various companies in silicon valley, and his stories and lessons in Managing Humans are really helpful. Here are some miscellaneous takeaways from my recent reading.

Every Company (Probably) Has Big Problems

Turns out I’ve fallen prey to the “grass is always greener” fallacy. I realize that no company is perfect, but I’ve always worked at companies that seem to have pretty big problems and I always imagine that there’s some company somewhere in Silicon Valley that — while imperfect — “has it’s shit together” on the fundamentals.

Since Loop actually worked at some pretty big companies in the Valley — e.g., Slack, Palantir, Apple, and Netscape — his experiences and commentary at a few points in Managing Humans suggest otherwise:

I hate meetings. Everyone hates them because we’ve all been to so many that have sucked unequivocally that we now walk into a conference room, sit down with our arms folded, and think, “OK, how long until this one is officially a waste of my time? How long until this one sucks?” And then it does. Time is wasted.

Turns out meetings are terrible everywhere. Somehow, even the folks in Silicon Valley haven’t figured out how to ensure that meetings don’t waste our time.

[After a non-debatable mandate was given by the VP], as predicted, the team freaked…We had a good solid week of organizational disarray and then we got back to work.

Turns out people everyone don’t like being told what to do, and that even the folks in Silicon Valley don’t trust their leadership enough to swallow a mandate without a week’s worth of “organizational disarray.”

In high tech, we’re all in an incredible fucking hurry. We’re working against an unreasonable deadline and we’re over-committed on features. As a manager, your job is that of bullshit umbrella.

Here he’s talking about how managers ought to shield their employees from the bullshit of managementese, a language that supposedly facilities communication across departments. My annotation on this comment at this point of the book was this:

Here’s another example of how Loop presumed that there’s bullshit I’m the org. It’s the backdrop of this book in a lot of ways. Another title for the book could be “Managing Bullshit”

Here’s another self-explanatory, shocking tale of political machinations in an organization:

Maybe the execs won’t fire him because of the perception he has essential knowledge, but, I guarantee, those who are dependent on his black box of knowledge are concocting a devious plan to replace him and his knowledge because they want to grow . Right this second, three guys down the hall have rewritten Fez’s code in C and they’re secretly demonstrating their work to interested parties. They are building support, they are building a revolution, and they’re not going to stop until the person who is hindering their growth is gone.

Obviously, this story didn’t happen exactly as its told, but Loop has based these stories on real life. So, at some the best companies I know about, execs are out of touch and team members are back stabbing each other. Amazing.

Here’s my favorite. Loop explains an engineer’s risk factor for being outsourced by talking about company quality along two dimensions: process and product. He actually discusses 3 of the 4 possible states: lousy process / lousy product, lousy process / good product, good process / lousy product. The last possible state — good process / good product — he merely quips, “Wow. Where do you work?” Of course, this suggests that even the “great” companies in Silicon Valley often get either process or product wrong.

How to Get out of Terrible Meetings

There’s a whole chapter on this. It was so refreshing to read someone being so candid about how much BS is typically involved with meetings.

The basic strategy he outlines is to identify what type of meeting you’re in and then to just give “the players” what they want.

In “informational meetings,” the players are listeners and the talkers. Talkers just want to convey information. This means that you need to tell people who are trying to debate the issue to schedule a follow up and make sure they don’t invite you.

In “conflict resolution meetings,” there are “pros” and “cons.” Pros are getting what they want. Cons are getting screwed. Getting out of this meeting requires that someone communicate a set of concrete steps to help the cons feel less screwed.

I don’t think this taxonomy meetings and accompanying exit strategies are exhaustive, but they’re a great start.

Why I’m Occasionally Cranky at Work

In “Incrementalists and Completionists,” Loop divies folks up into two camps. “Completionists” have vision and they have strong opinions about how to solve a problem “The Right Way™.” They are big on solving the problem completely. Incrementalists, as their name implies, are more about hacks and gerry-rigs.

Loop does a great job about going over the pros and cons of type, which was great for me to read because — for better or worse — I’m a “completionist” and “incrementalists” often annoy me. That wasn’t the best part about the chapter though. The best part for me was this passage:

With all of their strategic vision, “completionists” often lack common corporate and people sense. Yes, they have a five-year technical roadmap in their heads, but they have nary a clue how to start pushing that agenda with the 12 different people who need to get on board to make anything happen. This is why “completionists” often get incorrectly labeled as curmudgeons. Sure, they’re cranky, but it’s not cranky for crankiness’s sake, it’s because they don’t have the communication and people skills to convince the company of the truth.

I read that and thought, “Wow. That’s me.” Most of the time, thinking about how to manage people is scary and complicated for me, so I often prefer to stick to managing bits. It turns out that for “completionists” like me, this is a recipe for crankiness.


Loop’s book helped me adjust my expectations about working in software companies a little bit. Less pretentiously, the book helped me grow up a little. I recommend it.


What is an Object Graph?

comments powered by Disqus