Short review: read the book, even if it is ten years old.
The book is split up into four sections that provide an arc of discussion from the reasons we have no slack in business to the serious impact of the lack of slack to change and growth and finally into risk and risk management. Change requires that organizations have slack to devise and implement the change (with an aim to make changes that create growth). And risk management by its very nature will create slack - also known as reserves or buffers - in order to help manage the unknown. And knowledge work is notoriously difficult to pin down.
But what is slack all about? We need slack in our work as individuals and organizations. We need slack to deal with the natural variability of the work we do. No slack means no capacity for handling the variability that everyone knows exists (and that most people ignore to make things "look good"). We need slack to create the next version of the organization. We need slack to see what needs to be changed. This is completely in line with the Theory of Constraints work that I do: operationally, buffers you against variability. Slack / buffer / reserve is there to protect the system not the individual or the lone task. The system.
One section on multitasking lit me up. He talked about the "real costs of task switching." I've commented and used the idea of task-switching many times in discussions of multitasking. Generally: it costs time to switch between tasks, so time is lost as you move from one unfinished task to another. DeMarco does a nice job of enumerating the ways in which that time is lost: the simple mechanics of picking up where you left off; redoing work that you've already done; re-immersing into the problem; frustration of having to stop and start; and the loss of team connectedness and binding as people are strewn in small fractions across many tasks on many projects that are never completed. While most organizations blindly assume that the cost of task switching approaches zero, DeMarco suggests that it's probably more like 15% per additional task! (And then he admits that it isn't scientific, but he is sure it is NOT zero.)
A theme that runs through the book revolves around change management and the capacity of organizations to absorb change. Organizations with no slack, particularly amongst "middle managers" who must execute the changes, have no chance to grow. Another interesting aspect of the continual change under which we operate today is that the people throughout the organization have a lot of knowledge and domain expertise about the changes themselves. They've seen successful (and failed) changes, and they know the history. When we push them and stress them beyond their limits, they can no longer draw on this contextual knowledge to help the organization grow to its next level. And when they leave the organization, they take with them all that domain knowledge.
What about some of those myth busting comments in the book?
- Knowledge work cannot be made into factory work.
- "Hurry Up!" cultures don't work. "Hurry" makes the system go slow. Instead, slow down purposefully to make it work. Haste makes waste.
- Knowledge workers are not infinitely fungible. One engineer does not have the SAME skills as another. Assuming that they are creates all sorts of foolishness, like assigning people to projects at 15%.
- Most organizations that think they are agile aren't.
- "Aggressive schedules" are a fallacy and a failure of the team and management to acknowledge the likelihood of hitting the schedule is nearly zero.
- Claiming that people work 40 hours but forcing them to work 60 only makes sense when the measurement systems make it appear that resources are being extra productive. But it kills people.
- Fear is not a useful management tool. People are afraid enough, don't use fear and intimidation and other role power to force people to do things. Give them a safe environment, so that they can do their jobs. And maybe even improve the work as well.
- Automation makes knowledge work harder. Automation assumes repeatability and fixed processes. Knowledge work is barely repeatable processes, and fixing some elements of it with automation means that the remaining work around THAT must be adjusted to the current situation.
- Quality Assurance in most companies doesn't assure quality that customers really care about. Quality should be part of the initiation of the project, not at the end, when it is too late.
- And in case you don't know: Hurry Up culture kills quality.
- Efficiency shouldn't be your first focus. It should be effectiveness (doing the right thing). Only then you should worry about doing that thing right (efficiency).
- It's better to initiate change when things are going well. When things are going poorly, the fear level is higher and the activation energy for change is commensurately higher.
- Sticks and stones may break my bones, but names will never hurt me. Another false saying from childhood. Names do hurt because they create that environment of fear, where nothing good can get done.
- Dilbert is a jerk. Scott Adams may be brilliant, but poor old Dilbert never pushes back against pointy-haired-management idiocy and is thus part of his own problem and that of his colleagues.
- Trust is not earned. At least not in the way our parents tell us (you gain trust by demonstrating trustworthiness). You gain trust by people giving it to you, based on all sorts of factors (blind faith even). You also get it by giving it!
- Working at breakneck speed is sure to break your neck.