Book of the Week: Peopleware
24 Dec 2015
Peopleware is a book about managing productive software teams that was written over 35 years ago. Some things never change. A lot of the challenges companies face are not technology problems, but how do you get a bunch of people together to solve accomplish a task. Things are different when you deal with knowledge workers that need the proper environment to flourish. There are parts of the book I disagree with, but I don’t have any data to suggest that they are wrong. The Seven False Hopes of Software Management
- There is some new trick you’ve missed that could send productivity soaring.
- Other managers are getting gains of 100 percent or 200 percent or more!
- Technology is moving so swiftly that you’re being passed by.
- Changing languages will give you huge gains.
- Because of the backlog, you need to double productivity immediately.
- You automate everything else; isn’t it about time you automated away your software development staff?
- Your people will work better if you put them under a lot of pressure.
People try to do a lot of things that don’t work. Technology and tricks can only help you so far. The bottleneck at the end of the day is people. The book is called Peopleware for a reason.
People under pressure don’t work better—they just work faster.
Coding War Games I think this is where the myth of the 10x engineer came into being. The authors ran a survey across different organizations in the form of Coding War Games. People were given a series of benchmark coding and testing tasks to complete in minimal time with minimal defects.
- Best people outperformed worst by 10:1
- Best performer was about 2.5 times better than median performer.
- Half the better-than-median performers were about 2:1 better.
A 10x engineer sounds a lot better than a 2.5x engineer. If you’re a 2x engineer, you are pretty awesome. The thing that correlated most with high performance was who you were paired up with. Language, experience, salary, number of errors didn’t matter unless you were coding in assembly with less than 6 months of experience. Teamicide It is hard to identify things that make a team work well together. It is easier to identify things that kill a team.
- Defensive management
- Bureaucracy
- Physical Separation
- Fragmentation of people’s time
- Quality reduction of the product
- Phony deadlines
- Clique control
Defensive management is when you do stuff to prevent the team from screwing up, because you don’t trust team. Clique control is when you break up groups of people who work well together, because people are like cogs. You can take a cog from one team and put it in another.
Deming’s point is that MBO and its ilk are managerial cop-outs. By using simplistic extrinsic motivators to goad performance, managers excuse themselves from harder matters such as investment, direct personal motivation, thoughtful team formation, staff retention, and ongoing analysis and redesign of work procedures.
I hate management by objectives (MBO) or objectives and key results (OKR) with a passion. They seem so short sighted and are focused on trying to measure something. The problem is that when you are planting a seed, whether that seed will grow into a redwood or not is not quantifiable. MBO is horrible for prioritizing investments that will lead to future gains. You can’t measure future potential in the present. I don’t think MBO are compatible with creative work since progress is not linear or measurable in an intermediate state. Purchase Peopleware on Amazon.com or check it out from your local library.