Peopleware Notes
I've finally finished reading the excellent Peopleware book, and would like to share with you some of the notes I wrote to myself while I was reading it. Here we go (erm, spoilers up ahead, I guess...).
- Projects fail because of people (politics, communication, etc.), not because of technology. And yet we spend so much of our time worrying about this software or that tool instead of dedicating our time to the most important thing: taking care of our people.
- Working overtime for long periods of time is bad, and you'll pay for it in terms of employees' satisfaction and recuperation time. In the short run it might seem like it pays off, but in the long run you'll get sad developers and low quality products.
- Developing high quality software is more important for the pride of the developers than to your customers. That is, it is important for your team's morale that you develop high quality stuff, instead of rushed, buggy and unmaintainable solutions.
- "Parkinson's law almost certainly doesn't apply to your people". This sentence took me by surprise, I must admit. Parkinson's law says that work expands to fill the time allocated for it. If you assign a task two months to complete, that's how long it will take (at least). I always believed this to be true, as I thought that people tend to let themselves "wonder about" if they feel they have the time to do so. The authors claim it is simply not true, and they show a research that backs up their case. On projects in which there was no time pressure at all (no deadline, we're done when we're done kind of thing), the productivity was a lot higher than in projects that did. And yes, it does make me wonder.
- The reason "you can't get anything around here between 9:00 and 17:00" is crappy work environments. Most workplaces suck in this regard. They are noisy, full of interruptions and they just don't allow you a moment to think. I could certainly relate to that, as I'm really a guy that needs his thinking time, and on some days it is just impossible to find 5 quiet minutes to yourself. Usually it means I will stay at the office a bit later than everyone else, so I can finally get something done. The authors go about how to build the best work environments, but I won't get in to that.
The important thing to remember is that you must allow your people to work during the standard working hours, by providing a maximum number of uninterrupted hours each day. That is, hours in which you just work, no one calls you, no one talks to you, you can get in the "zone" (or "flow" as the authors call it) and just work. Since each interruption takes you out of your zone ("Hm, where I was I before that phonecall...?") uninterrupted hours are the time in the day you make the most work progress. In my current workplace, it saddens me to say, I think that you get maybe 1/2 of uninterrupted hours during the normal work hours. The culture of our organization was not created, apparently, by managers who read Peopleware. It's too often that I hear my team complaining about not getting to code at all in certain days. It is my goal to give each of the members of my team 2 whole uninterrupted hours between 8:00 and 17:00. Ambitious, yes, but I believe this will improve our productivity more than anything else.
- The best organizations are consciously trying to be the best. This is a part of what turns a workplace to a community.
- The concept of a jelled team. The jelled team is a team of people that complete each other, that create a whole that is greater than the sum of its parts. Being in a jelled team is what will make you enjoy your work, and there's nothing better than working in a job you enjoy. It is the best thing for the organization as well, as a jelled team will perform a lot better than a one that isn't.
The authors don't tell you how to jell a team, they can't - it either happens or not. But they do tell you what will definitely ensure that your team is not jelled. Things such as defensive management (not trusting your people, trying to control their every action), bureaucracy, and phony deadlines (trying to set an early deadline just for the team to work harder) among others. I think that this chapter, called "Teamicide", is the most important in the book. I would recommend everyone to read at least it, if not the whole book, and take a good look at yourself and at your organization. Are you killing your teams?
I would like to believe that my own team is in the process of jelling. We've been together for about 9 months already, and I feel that the members do complete each other. And we're having fun, which is the most important thing. What worries me is a current organizational move into "matrix" development. That is, instead of a team of people that stay with each other, assign a specific group of people for a specific task. It might look like the most productive thing to do (make better use of people's skills), but I believe it will prevent teams from jelling, and hence will kill productivity.
- People hate change. They really really do. And yet you have to change in order to improve. There will be chaos at first, and that's OK, since that's the nature of change. Soon things will converge again, and you'll be at a better place. This really relates to my current attempt at implementing TDD at my team. Most of them are now in the stage that they hate writing unit-tests. They understand the importance of it, I think, but the change for them is really hard. It is a new skill to learn, a new way to do things, and therefore we are now at a stage of chaos. But that's an integral part of every change, says Peopleware. Expect it.
- A manager's greatest sin is wasting his people's time. Your job is to maximize their work time, so don't consume it without a good reason.
If anything, I hope I motivated you to give this book a read. I think it is a must for anyone in a management position.
And last but not least, Shana Tova everyone! May you have a year full of good surprises, wonderful, bugless code, and of course, dancing chickens. (oh, come on, who doesn't like a dancing chicken?)