How to run a project
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 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.
Any regular get-together meeting is somewhat suspect to have a ceremonial purpose rather than a focused goal of consensus.
But organizations have a need of ceremony. It's perfectly reasonable to call a meeting with a purpose that is strictly ceremonial, particularly at project milestones, when new people come on board, or for celebrating good work by the group. Such meetings do not waste anyone's time. They fulfill real needs for appreciation. They confirm group membership -- its importance and its value.
Modern office politics makes a great class distinction in the matter of allocating windows. Most participants emerge as losers in the window sweepstakes. People who wouldn't think of living in a home without windows end up spending most of their daylight time in windowless workspace.
We are trained to accept windowless office space as inevitable. The company would love for every one of us to have a window, we hear, but that just isn't realistic. Sure it is. There is a perfect proof that sufficient windows can be built into a space without excessive cost. The existence proof is the hotel, any hotel. You can't even imagine being shown a hotel room with no window. You wouldn't stand for it. (And this is for a space you're only going to sleep in.)
Women's dormitory at Swarthmore College; everyone has windows.
The purpose of a team is not goal attainment but goal alignment.
A few very characteristic signs indicate that a jelled team has occurred. The most important of these is low turnover during projects and in the middle of well-defined tasks. The team members aren't going anywhere till the work is done. Things that matter enormously prior to jell (money, status, position for advancement) matter less or not at all after jell. People certainly aren't about to leave their team for a rinky-dink consideration like a little more salary.
There is a sense of eliteness on a good team. Team members feel they're part of something unique. They feel they're better than the run of the mill. They have a cocky, SWAT Team attitude that may be faintly annoying to people who aren't part of the group.
In my two years at Bell Labs, we worked in two-person offices. They were spacious, quiet, and the phones could be diverted. I shared my office with Wendl Thomis who went on to build a small empire as an electronic toy maker. In those days, he was working on the ESS fault dictionary. The dictionary scheme relied upon the notion of n-space proximity, a concept that was hairy enough to challenge even Wendl's powers of concentration. One afternoon, I was bent over a program listing while Wendl was staring into space, his feet propped up on the desk. Our boss came in and asked, "Wendl! What are you doing?" Wendl said, "I'm thinking." And the boss said, "Can't you do that at home?"
Organizations also have some need for closure. Closure for the organization is the successful finish of the work as assigned, plus perhaps an occasional confirmation along the way that everything is on target (maybe a milestone achieved or a significant partial delivery completed). How much confirmation corporations require is a function of how much money is at risk. Frequently, closure only at the end of a four-year effort is adequate for the needs of the organization.
The problem here is that organizations have far less need for closure than do the people who work for them. The prospect of four years of work without any satisfying "thunk" leaves everyone in the group thinking, "I could be dead before this thing is ever done." Particularly when the team is coming together, frequently closure is important. Team members need to get into the habit of succeeding together and liking it. This is part of the mechanism by which the team builds momentum.
Lost production due to change of personnel.
Productivity took a hit when Louise left, even passing below zero for a while as others scurried to make up for the loss of a well-integrated team member. Then, eventually, it worked its way up to where it was before.
The shaded area on the graph represents the lost production (work that didn't get done) caused by Louise's departure. Or, viewed differently, it is the investment that the company is now making to get Ralph up to where Louise was after the company's past investments in her skills and capabilities.
Once a team begins to jell, the probability of success goes up dramatically. The team can become almost unstoppable, a juggernaut for success. Managing these juggernaut teams is a real pleasure. You spend most of your time just getting obstacles out of their way, clearing the path so that bystanders don't get trampled underfoot: "Here they come, folks. Stand back and hold onto your hats." They don't need to be managed in the traditional sense, and they certainly don't need to be motivated. They've got momentum.
Have you ever been in an organization that simply glowed with health? People were at ease, having a good time and enjoying interactions with their peers. There was no defensiveness, no sense that single individuals were trying to succeed in spite of the efforts of those around them. The work was a joint product. Everybody was proud of its quality.
Presented below is an admittedly simplistic list o the elements of a chemistry-building strategy for healthy organization:
-Make a cult of quality.
-Provide lots of satisfying closure.
-Build a sense of eliteness.
-Allow and encourage heterogeneity.
-Preserve and protect successful teams.
-Provide strategic but not tactical direction.
When you first start measuring the E-Factor, don't be surprised if it hovers around zero. People may even laugh at you for trying to record uninterrupted hours: "There is no such thing as an uninterrupted hour in this madhouse." Don't despair. Remember that you're not just collecting data, you're helping to change people's attitudes. By regularly noting uninterrupted hours, you are giving official sanction to the notion that people ought to have at least some interruption-free time. That makes it permissible to hide out, to ignore the phone, or to close the door (if, sigh, there is a door).
At one of our client sites, there was a nearly organic phenomenon of red bandannas on dowels suddenly sprouting from the desks after a few weeks of E-Factor data collection. No one in power had ever suggested that device as an official Do Not Disturb signal; it just happened by consensus. But everyone soon learned its significance and respected it.
When you observe a well-knit team in action, you'll see a basic hygienic act of peer-coaching that is going on all the time. Team members sit down in pairs to transfer knowledge. When this happens, there is always one learner and one teacher. Their roles tend to switch back and forth over time with, perhaps, A coaching B about TCP/IP and then B coaching A about implementation of queues. When it works well, the participants are barely even aware of it. They may not even identify it as coaching; to them it may just seem like work.
Whether it is named or not, coaching is an important factor in successful team interaction. It provides coordination as well as personal growth to the participants. It also feels good. We tend to look back on significant coaching we've received as a near religious experience. We feel a huge debt to those who have coached us in the past, a debt that we cheerfully discharge by coaching others.
Learning is limited by an organization's ability to keep its people.
The most likely learning center for any sizable organization is the white space that lies between and among middle managers. If this white space becomes a vital channel of communication, if middle managers can act together as the redesigners of the organization, sharing a common stake in the result, then the benefits of learning are likely to be realized. If, on the other hand, the white space is empty of communication and common purpose, learning comes to a standstill. Organizations in which middle managers are isolated, embattled, and fearful are nonstarters in this respect.
Learning happens in the white space.
The proper curve of hiring for a project. Looks odd (so many at the end), but may be the ideal.
If you have ever undertaken a major development effort, you almost certainly know the wisdom of the adage, "Build one to throw away." It's only after you're finished that you know how the thing really should have been done. You seldom get to go back and do it again right, of course, but it would be nice.
This same idea can be applied to whole careers. Between the two of us, we've spent nearly thirty years managing projects or consulting on project management. Most of what we've learned, we've learned from doing it wrong the first time. We've never had the luxury of managing any of those projects over again to do it entirely right. Instead, we've written this book.