Peopleware

Kevin Kelly's excellent Cool Tools email reminded me of the classic Peopleware, by Tom DeMarco and Tim Lister. I think my copy is at the office (a foolish place for it), so I have to quote from Kevin today.

Hard-won wisdom fills this small book: How to create a team, place, or company that is productive. First published 20 years ago, and updated once since then, copies of it have quietly served as a guru for many start ups and successful projects in Silicon Valley. Neither academic nor faddish, two veteran consultant authors offer real intelligence. This book has totally informed how I do projects. I learned about the myth of overtime, the need for closure and ceremonies, how teams jell, and why everyone should and can have a window. I first read it decades ago and re-read it every time I embark on anything involving more than one person and several years of my life. Unlike a lot of management lore, it is aimed at the project level (where I want to be) rather than the large organization. The message in the book touts productivity, without ever mentioning the dreary idea of time management. It's more about optimizing people, and thus the title, Peopleware.

I've posted before about teamwork and invisible work, and Peopleware is all over this stuff. Here's an anecdote Kelly cites from the book:

I was teaching an in-house design course some years ago, when one of the upper managers buttonholed me to request that I assess some of the people in the course (his project staff). He was particularly curious about one woman. It was obvious he had his doubts about her: "I don't quite see what she adds to a project -- she's not a great developer or tester or much of anything." With a little investigation, I turned up this intriguing fact: During her twelve years at the company, the woman in question had never worked on a project that had been anything other than a huge success. It wasn't obvious what she was adding, but projects always succeeded when she was around. After watching her in class for a week and talking to some of her co-workers, I came to the conclusion that she was a superb catalyst. Teams naturally jelled better when she was there. She helped people communicate with each other and get along. Projects were more fun when she was part of them. When I tried to explain this idea to the manager, I struck out. He just didn't recognize the role of catalyst as essential to a project.

Which reminds me of the need for root cause analysis of successes. At one of my previous companies, we had a big focus on root cause analysis of problems in order to avoid making them again. In itself this was laudable, but there wasn't quite the same focus on root cause analysis of success. Unless you want it to be accidental, lack of root cause analysis of success might prevent repeat performance of success by not recreating the same conditions that led to it in the first place. Not understanding the role of team members and not understanding how to diagnose team success, except in terms of org charts and job titles, can contribute to this management misstep.

I've concluded over the past few years (and it's the subject of an article I'm supposed to be writing), that project level management requires an anthropological mindset. If you aren't interested in the news from the field, and in forming conclusions from raw data from people doing the actual work, you are more likely to form erroneous or overly "easy" conclusions; you have to instead rely on standard management book guidance and act on previously filtered information that's highly likely to be biased or dangerously incomplete. Sure, every modern anthropologist admits her own biases play a role in terms of what she sees and hears. But wouldn't you, as a manager with sufficient time, rather be filtering the raw data rather than taking in someone else's biased filter? A few design and project train wrecks can be avoided by talking to the right people at the right point, when there's time to be an influence for the good.