in Books

Book review: Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency

Here’s a book I wish every manager would read, especially the managers in charge of my project (pure self-interest in my part, I admit it). It’s short, focused, to the point, and it drives home a very powerful message: By being constantly busy working you’re probably hurting your project and your company.

The whole book revolves around that idea, provides explanations, examples, and the consequences. It’s also a very short book, just over 200 pages of large print and easy reading (intended to be read in a two-hour flight as the author put it), which is good considering it’s aimed at busy managers. Ironically, the people who need to read the book most won’t even know it exists or won’t be able to make the time to read it. A while back, I forced a copy upon one of my managers and I said to him “Here, you must read this.” Supposedly he started reading it but never finished it. I don’t think the book really did it for him (and he still has my copy, oh well).

So how can adding time that is not set aside for specific tasks, or “slack”, in the schedule of a manager or a lead or even a senior staff member help the project? Shouldn’t everybody be grinding away with their noses down and fingers glued to their keyboards? When someone is working all the time, he’s more efficient because he gets more units of work done in a fixed amount of time. However, he can be less effective than someone with slack into his schedule.

DeMarco very effectively argues that slack allows some very important things to happen. First of all, it allows an individual (and therefore the company) to react more quickly. The manager can take an hour right away and fix something that will benefit the whole team. Otherwise, he might not get around to doing it for another week or two, or after the milestone… or ever. The second benefit is that it allows people to stop and think about what they’re doing, why they’re doing it, and how they can do it better. In other words, it allows for constant process improvement.


And if you’re starting to think of making up slack time by putting in more hours, stop right there. Go read DeMarco’s other book, Peopleware, before you get any bright ideas. The conclusion is that putting in more time beyond a certain amount doesn’t make the project go any faster (but it makes your employees unhappier and go away a lot faster!). No, we’re talking about true free time. It doesn’t mean that people are going to be twiddling their thumbs during that time though. They’ll be researching new ways of doing things, trying out new tools and techniques, reading new books (!!), learning a new language, or helping out with some emergency that came up.

Two gems from the book that are worth the price of admission by themselves:

The First Law of Bad Management (actually from another source, but mentioned in the book): If something isn’t working, do more of it.

Sounds ridiculous, doesn’t it? Yet, how many times have we seen that happening all around us? “We’re putting all this overtime and we keep missing milestones. We must put more overtime!” Next time things start heading south in your project, stop for a moment and think about this again. It won’t feel so funny anymore.

The Second Law of Bad Management: Put yourself in as your own utility infielder.

In other words, a manager shouldn’t also be doing work for the project he’s managing. Even though it feels very tempting, and there are even managers out there who pride themselves in it, it’s usually a bad idea all around. It ties up the manager’s time instead of having “slack” time to react to any unexpected events. It also means that the work done by the manager isn’t supervised by anybody other than himself. People in general, and programmers in particular, tend to be overly optimistic about their own work, so, without any external checks, that work could easily slip big time or quality can suffer. You need to have nerves of steel to tell your boss that he’s writing crappy code and he shouldn’t be doing it.

I’ve seen this situation happen several in my time in the games industry, and never with a good ending. It’s usually because managers are just programmers who have put in their years in the ranks and have been “upgraded” to a management position. They claim they’ll do 60% management and 40% programming. Buzzz! Wrong answer! Unless they’re managing only one or two more people, that’s not going to happen; they’re going to do both jobs half way and neither one well.

The other very common situation is when a team member leaves half way through the project (a topic for another article) and the manager decides he’s going do take up the job Bob was doing. Next thing you know, the manager is locked in his office doing Bob’s work (poorly since he doesn’t fully understand it and he’s out of practice) and not managing the project as he should.

Even if you’re not a manager, you can greatly benefit from reading the book. Maybe one day you’ll be in charge of other programmers, and in the meanwhile you can take a copy and give it to your boss. Tell him what you want, but make him read the book. It’s even really cheap, so you have no excuse not to buy a copy now. Just make sure you write your name in it; hopefully you will get your copy back.

  • Slack

    Nice to know that someone in the in the game industry cares about the development process and ‘peopleware’. Noel Llopis got a good blog called ‘Games from Within’.

  • The Second Law of Bad

    The Second Law of Bad Management