Reading: Peopleware: Productive Projects and Team by Tom DeMarco and Timothy Lister

So last month I finished a re-read of "The Mythical Man-Month" by Fred Brooks.. and saw in the back of the book a reference to "Peopleware:..." by Tom DeMarco and Timothy Lister. I had heard of the book in the late 1990's (right before I joined Red Hat for the first time) from a fellow coder who was moving  into management and had wanted to do it right. Marshall had read the book, tried to put the ideas into place and was promptly let go by the company. [Within about 6 months, we were all let go also... for a reason given in the book..] In the years since I have seen the book brought  up several times, but I had never actually read it.

First off, the book is very ranty. Very very ranty in parts about open floor plans (and the Furniture police), open organizations, and a couple of other areas of middle management. It is not that I found their comments off the mark.. but you may have to soldier onto the next chapter through a couple of them. That said there are a lot of gems in the book which 'spoke to me'.

Parkinson's Law Doesn't Exist

Work expands to fill the time allocated to it. - C.  NorthCote Parkinson

I have had several managers quote this to teams I have been on in the last 30 years. People would bring up Parkinson's law about why we shouldn't add more time to a schedule but should cut it back. I, myself took it for certain that this was some sociological experiment which proved things about scheduling. I never realized until reading this book that a Mr. Parkinson was not a scientist, but a satirist and the things people have 'quoted' as being proven by it originally were all made up for a humorous article and books he wrote. 

In the extent that there may be places where people come up with busy work to meet a schedule... it usually is where people are not finding satisfaction in their current job. [chapter 5]

Open Floor Plans Don't Help Programmers Flow

This book was originally written in the 1980's when open floor plans were having 6 foot high cubicles versus offices with doors. Back then there was a lot of recorded data about how various 'knowledge' workers can't get into a flow state of thought because there are too many distractions. Today's open floor plans of no cubicle walls and brutalist concrete structures in order to get some sort of energy efficiency put those to shame. [This is where the rants on furniture police start and go on for quite some time.. ] The useful information I took from this is that one should measure their uninterrupted time and not their hours. Doing this can show where productivity is actually going and work out better planning on how efficient a project can meet its goals.

Hiring The Right People to Teamicide

This section of the book has a lot of useful parts, but one that stood out to me was the chapter "Happy to Be Here" with an excerpt from "Up the Organization" by Robert Townsend. It basically explains a method for dealing with an underperforming organization by moving it to a new location. The purported guaranteed results:

1. the best people will move to the new location.
2. the rest don't have to face the fact they have been fired. Instead they can say "The company moved town."
3. your competition will move in and hire these less desirables thinking they are getting a bargain.
4. the new people at your new site are infused with enthusiasm because all they know are your 'best' people. 

This was basically the strategy used by that company I worked for years before Red Hat. We were all told the company was moving town and we could reapply for our jobs at a different location. The problem they ran into is the one mentioned in the book.. most of the best people didn't go (they ended up being hired as contractors and paid 2.5x what they had been paid before so that deadlines could be met), and a lot of the people who did weren't the ones they wanted. Those of the best  people who did go left shortly after their moves. The psychological loyalty they had with the company had been broken so any problem at the new place was enough to send them packing. 

The next sections cover more about how to make a team of people "jell" which ends up being harder to describe than the ways to make a team break down. 

1.  Defensive Management
2. Bureaucracy
3. Physical Seperation
4. Fragmentation of people's time
5. Quality of reduction of the product
6. Phony deadlines
7. Clique Control
8. "Motivational" posters and awards
9. Overtime causing undertime
10. Internal team competition
11. Annual salary/merit reviews
12. Management by Objectives

I can see where some of the above are causes of team breakdowns but others seem to be a lot smaller concerns comparatively.

Making Change Possible

The chapter opens with a quote by Steve McMenamin, of the Atlantic Systems Guild (the organization the authors are members of).

People hate change... and that's because people hate change... I want you to be sure that you get my point. People really hate change. They really, really do. 

People don't react to change logically and very little 'logical argument' will help them. People react to change emotionally and the most likely result is going to be failure and ridicule from ones peers and sometimes by the people who instituted the change. The book also brings up the idea of Jerry Johnson, Menninger Foundation, that there is a continuum of ways people react to the change:

1. Blindingly Loyal (Ask no questions.)
2. Questioners
1. skeptics (show me)
2. passive (what's in it for me?)
3. opposed due to fear of change
4. opposed due to fear of loss of knowledge/power
3. Militantly Opposed (Will Undermine and Destroy).

While some people think that the second 2 sets are 'non-supporters', the Blindingly loyal are also the ones to most likely jump ship at the next newest thing. The only people who will stick it through are the various questioners if they are helped through the emotional journey through the initial Chaos and failures before the change can be truly evaluated. [The rest of the chapter goes into parts of that while referencing books like "The Prince" by Machiavelli and Virginia Satir's model of therapy change. I actually wish this chapter had been a bit more in depth but I think I will reread Managing Transitions (which was referenced in different parts of the book) instead.