What we have come to think of as the Peopleware project began for us during the course of a long night flight over the Pacific more than thirty years ago. We were flying together from L.A. to Sydney to teach our Software Engineering Lectures series. Unable to sleep, we gabbed through the night about the deep complexities we were encountering in systems projects of our own and the ones related to us by our clients. One of us—neither one can remember which it was—reflected back over what we’d been discussing and offered this summing up: “Maybe . . . the major problems of systems work are not so much technological as sociological.”
It took a while for that to sink in because it was so contrary to what had been our thinking before. We, along with nearly everyone else involved in the high-tech endeavors, were convinced that technology was all, that whatever your problems were, there had to be a better technology solution to them. But if what you were up against was inherently sociological, better technol- ogy seemed unlikely to be much help. If a group of people who had to work together didn’t trust each other, for example, no nifty software package or gizmo was going to make a difference.
Once the idea was out in the open, we began to think up examples, and it soon became clear to both of us that the social complexities on most of the projects we’d known simply dwarfed any real technological challenges that the projects had had to deal with. And then, inevitably, we needed to face up to something far more upsetting: While we had probably known in our bones for a long time that sociology mattered more than technology, neither of us had ever managed that way. Yes, we had done things from time to time that helped teams work better together or that relaxed group tensions, but those things had never seemed like the essence of our work.
How would we have managed differently if we’d realized earlier that the human side mattered much more than the tech side? We started making lists. We had blank acetates and foil pens handy, and so we put some of the lists onto overhead slides and thought giddily of actually presenting some of these ideas to our Sydney audience. What the hell! Sydney was half a globe away from the States and Europe; if we bombed in Australia, who would ever know of it back home?
Our Sydney audience the next week was immediately engaged by the peo- pleware material, and a bit chagrined (evidently we weren’t the only ones who had been managing as if only the technology really mattered). Best of all, people chimed in with lots of examples of their own, which we cheerfully appropriated.
What separated that early out-of-town tryout from the first edition of the book in 1987 was a ton of work conducting surveys and performing empiri- cal studies to confirm what had been only suspicions about the effects of the environment (Part II of this third edition) and to validate some of our more radical suggestions about team dynamics and communication (most of the rest of the book).
Peopleware in its first two editions made us a kind of clearinghouse for ideas about the human side of technology projects, and so our thinking has had to expand to keep up. New sections in this third edition treat some pa- thologies of leadership that hadn’t been judged pathological before, an evolv- ing culture of meetings, hybrid teams made up of people from seemingly incompatible generations, and a growing awareness that, even now, some of our most common tools are more like anchors than propellers.
For this third edition, we are indebted to Wendy Eakin of Dorset House and Peter Gordon of Addison-Wesley for editing and shaping our manuscript. Thanks, too, to our long-time colleagues at The Atlantic Systems Guild—Peter Hruschka, Steve McMenamin, and James and Suzanne Robertson—for thirty years of ideas, brainstorms, debates, meals, and friendship.
