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.
2 comments :
I did lithography research in my early years at Bell Labs. Our group was linked to IC manufacturing groups at AT&T Microelectronics at Allentown, Orlando and Madrid and we found ourselves spending serious time trying to solve real world issues.
The Allentown location had a curious fellow named Doug. He was everywhere, but no one could figure out exactly what he did. Knowledgeable and amazingly friendly, he would wander about talking to people all day. People called him "the mayor of Allentown" and no one could figure out how he justified his paycheck.
He was fun to watch. His office was full of interesting trinkets, wonderful homemade goodies and imported beer for after hours.
After a few years I became friendly with the plant manager and asked about Doug. "oh - he's the most important person here... He keeps the process in control and is probably responsible for 10 percent of the yield"
It turns out silicon processing is very much a black art - particularly when you are pushing the design rules when the process is new (the first 6 months or so). Everything is interrelated - often in non-trivial ways that elude the process models. It is possible for a human (or a small group) to understand a machine deeply (say a stepper - which might have a few PhDs attached to it), but the overall process is far too complex.
It is very easy to locally optimize the process and create a less than optimal total process (lots of metastable states in the phase space of the system)
Doug's place was to find where the process was wandering and to bring the right people together to solve the problem smoothly without ruffling feathers (many arrogant people who *know* their piece is the only true important piece of the process) and without damaging the process and product.
The plant manager gave Doug and imported beer and chocolate budget and free reign. It was clear he felt Doug was the most important person in the operation.
Doug lacked a college education. He had some electronics training and spent time on nuclear submarines in the Navy prior to Allentown. He never took credit for anything and was always flattering everyone "so and so is sooo smart - look what they did with this other group"
The plant manager retired and Doug was fired by the new manager.
What an excellent story -- with a really awful ending. Thanks, I guess :-)
Post a Comment