This book is about the sociology of projects, though it spends a lot of time about the physical environment that programmers find themselves in. For instance, there's a long section about putting together an ideal space for a small team, as well as railing about prevailing noise in the workspace and the current favorite solution, headphones and ipods:
During the 1960s, researchers...polled a group of computer science students and divided the students into two groups, those who liked to have music in the background while they worked (studied) and those who did not. Then they put half of each group together in a silent room, and the other half of each group in a different room equipped with earphones and a musical selection. Participants in both rooms were given a Fortran programming problem to work out from specification. To no one’s surprise, participants in the two rooms performed about the same in speed and accuracy of programming... The Cornell experiment, however, contained a hidden wild card. The specification required that an output data stream be formed through a series of manipulations on numbers in the input data stream... Although the specification never said it, the net effect of all the operations was that each output number was necessarily equal to its input... Of those who figured it out, the overwhelming majority came from the quiet room.In other words, you're giving up significant creativity when you choose to ask engineers to put on headphones and listen to music in order to compensate for a noisy work environment. There's an explanation about why incentives such as "best quarter ever" doesn't work:
Throughout the upper ranks of the organization, there is marvelous ingenuity at work to be sure that each manager has a strong personal incentive to accept the corporate goals. Only at the bottom, where the real work is performed, does this ingenuity fail. There we count on “professionalism” and nothing else to assure that people are all pulling in the same direction. Lots of luck.There's a long section about the importance of jelling a team, and how most managers do everything necessary in order to get the team not to jell (the authors call this "Teamicide"). What's fascinating to me is that the authors claim that they don't know how to get teams to jell, even though the book is full of examples as to how to make it happen! They do provide lots of counter-examples, however, about how certain behavior causes teams not to jell.
Finally, in the "new" segments of the book (new since 1999, so not that new), the authors discuss how upper management can encourage teamicide:
Here are some of the managerial actions that tend to produce teamicidal side effects: annual salary or merit reviews management by objectives (MBO) praise of certain workers for extraordinary accomplishment awards, prizes, bonuses tied to performance performance measurement in almost any form But hold on here, aren’t these the very things that managers spend much or even most of their time doing? Sadly, yes. And yet these actions are likely to be teamicidal.Fundamentally, introducing competition disables the coaching process, and what happens then is that people no longer feel like a team. If your promotion package has to be better than everyone else in order for you to be promoted, then your best bet is to hoard knowledge and skills, rather than spreading it around.
There's a very cogent explanation about how the weekly status meeting is essentially a ceremony meant to boost the manager's ego, rather than something that's useful for a team. There's a good explanation of how trust is built and important to individual contributors' performance, and how increased quality is important to establish esprit de corps in a team. There's a lot of railing against fragmentation of people's time.
Do I have any criticism of this book? Yes. First of all, the authors have spent their careers entirely as consultants to large organizations. Many of the issues here don't exist in startups, for instance. I've never seen a startup with a large PA system that interrupts workers, nor have I seen one with a furniture police. The flip side of that is that the authors assume basic things that all managers should know and do, but judging by the quality of the average manager in Silicon Valley companies, is almost non-existent. There's insufficient analysis as to who should be a manager and who shouldn't. There's very little help these folks can give you as to how to hire and grow a balanced team. But seriously, there's no point criticizing this book for something the authors couldn't possibly have been expected to know.
At the end of this read, I still stand by my statement that this is still by far the best management book that an engineer or technical manager can read. Many large and growing companies I know could stand to distribute this book to every new manager. Needless to say, this book is highly recommended.