Notes on “Peopleware”

Notes on “Peopleware”

Peoplware is a popular book about management for software projects, though I imagine it is applicable to nearly every project. The core idea is that managers are managers of people, not technology, yet most people don’t manage that way.  Most software projects that go wrong go wrong because of problems with people, not problems with the underlying technology.

Against “Hours Worked” as the Key Productivity Metric

Managers brag about how much unpaid overtime they can extract from their employees and see this as a sign of productivity. This is naive. (I call this “shark productivity” and have argued against it before.)

Lack of confidence, lack of competence, and lack of affiliation help explain poor performance, not lack of overly long schedules. Schedule pressure only makes these issues worse.

Measuring Productivity

Measuring productivity is important. When the authors set out to benchmark productivity by having hundreds of workers complete the same program and then check for speed and accuracy, they found a 10x difference in productivity between companies. (Though, interestingly enough, the differences within companies were usually pretty small.)

Productivity is more than just number of code lines written or hours worked. In fact, a highly productive developer could be writing very little code, if they’re focused on writing high quality code, removing bad lines of code, teaching other people how to write code, facilitating code, helping the team bond, etc.

Capturing all of this is very difficult. The authors suggest that one potentially useful measure is the amount of interruption free hours spent in a flow state (called flow hours, similar in concept to the “deep work hours” recommended by Cal Newport).  1-3 hours a day may be normal, and the reason why people don’t get more done is far more likely the fault of the organization rather than the fault of the individual.

Another metric, called the “E Factor” is the total number of flow hours divided by the total number of hours worked.

The authors recommend that productivity measures only be collected to benefit the employees, not used to negatively affect them in performance reviews. The reason for this is that it is hard to collect productivity metrics without the cooperation of the workers and that people won’t be responsive to the metrics if they’re used negatively.

The authors also suggest that people should have some way to protect flow hours, like a do not disturb sign. The organization and team should do what they can to improve the E Factor.

Distracting Environments as an Underrated Cost

Why is the E Factor so low? The authors spend a lot of time railing against negative work environments as the key reason. The popular “open office” can be a hotbed of distracting conversations and chatter that ruins focus.

They found in their studies that whether or not a worker had a distraction-less environment correlated strongly with performance on a coding task. They note, however, that this could just be because high performers are more likely to seek out or believe they have a distraction-less environment, rather than a distraction-less environment causing high performance.

Email, IM, phone, etc.

Another source of interruption is constant communication. Ideally people should be allowed to take long breaks from the expectation of regular communication.

All communication should pass the need to know test. Is the email you’re about to send only being sent to people who need to know? If not, don’t send it. Did you need to know what you just heard? If not, push back and try to change the culture toward less communication.

Meetings

Meetings can be a source of disruption, so they should be minimized if possible.

A good meeting has an agenda distributed in advance and a strong commitment to not talking about anything off meeting. Meetings should have a definitive goal and the meeting ends when the goal is accomplished instead of just when the clock is out.

Good meetings should also avoid having people there who aren’t relevant. A common reason that these people waste their time in these meetings is they feel the need to attend defensively to prevent something bad from happening (e.g., an off-agenda decision to change what they’re working on). A good meeting culture can prevent that.

Employee Turnover as a Underrated Cost

Employee turnover, and efforts to reduce it, are important for productivity, but neglected. Surprisingly, many managers do not know their turnover rate or the cost of losing a person. However, if a lost person requires two months to find a replacement + six months of less productivity, that’s ~5 months of lost work (counting the six months as averaging 50%). At $60/hr and 40hrs/wk, that’s over $50K!

Employee turnover also has large costs on culture and can beget more turnover, which is even more disastrous.

Working people too hard is a key cause of turnover, which further weakens the argument for “total hours worked”.

Lower retention by building a culture that people are expected to stay - through offering training for all employees and re-training to new positions for employees who want to do something new.

Getting a “Jelled” Team

A good thing for boosting both productivity and reducing employee turnover is creating a team that is “jelled”, where the whole is greater than the sum of the individuals.

Teams that have jelled are usually more successful. Jelled teams are teams that have bonded and feel like a team.

Getting a jelled team is more about growing than building - even if everything goes right it still might not happen. But you can kill a team by...

  1. trying to protect too much from team incompetence with burdensome rules
  2. having too much bureaucracy and paperwork
  3. too much physical separation of team members
  4. having people on too many projects at once
  5. having people work on projects that are of compromised quality
  6. impossible and/or phony deadlines.

You can potentially grow a team through...

  1. creating a cult of quality and eliteness
  2. fostering closure / feeling of completion
  3. getting people to experience shared success
  4. providing for heterogeneity, allowing team members to feel like individuals, and encouraging people to express themselves
  5. Offering formal and informal opportunities for team members to teach each other
  6. Team bonding events, especially ones with a little bit of “chaos” that go out of the norm.