I read this book by John Seddon several months ago so I hope I remember everything I wanted to say about it. The subtitle is “A better way to make the work work … the Toyota system for service organisations”.
It is important to know what he meant by Command & Control, as the term gets thrown around a bit, and there seems to be three main usages of the term.
The way I have always interpreted it and used it as a negative term for basically traditional management cultures that exhibit the best known aspect of Taylorism: Intelligent managers, remote from the work, do all the thinking, and decide not only what is to be done, but exactly how and dumb, replaceable workers that repeat the physical steps determined by the manager without question. In this case the managers are both issuing commands to the workers, and controlling how they do it. This seems to be how the term is used colloquially by most of the people that I hear use it, as a kind of umbrella term for all the dysfunction-exhibiting types of culture that are at the opposite end of the spectrum from what we are trying to achieve with more modern management ideas.
If you look the term up in Wikipedia, it refers to the usage of the term in the military. Here command and control are divested in separate roles. Staff of senior rank issue commands in the form of strategic objectives, while those of junior rank exhibit tactical control in order to achieve those objectives. This is more of a neutral usage of the term.
Seddon writes in the prologue a paragraph ending in “these are the principles and practices that constitute command-and-control management”. He specifically mentions the following:
Separation of decision making and work
Managers making decisions with measures like budgets, standards, and targets.
Managers learn that their jobs are to manage people and budgets
He also mentions that “our organisational norms are based on command-and-control thinking” and “The separation of decision-making from work, the cornerstone of command-and-control thinking, has its roots in Taylorism…”. So we can assume that Seddon is using the commonly accepted, popular definition of command-and-control.
He compares it directly to systems-thinking, in a table similar to the one on this blog post (where he compares it to “Vanguard’s System Thinking”).
Seddon targets his wisdom mostly towards service organisations, such as local authorities maintaining public flats, that have to react to customer requests in a timely efficient manner. He is inspired by Deming, and the work of Taiichi Ohno who invented the Toyota production system, the root of lean thinking, so I am not surprised to find a close correlation between the ideas in this book and the ideas expressed by the lean software development and Kanban communities. (Although lately it seems many in the Kanban community wish to place it as being a viable option for control cultures, probably for marketing reasons.)
In fact as I was reading the book, I was helping my employer, a typical command and control type company, work with Kanban. As I was reading this book I was thinking, man, if only our managers read this before attempting Kanban, we wouldn’t be struggling so much. As it happens Kanban requires a culture of high collaboration between workers and managers (managers who might not see themselves as part of a software development process but rather a larger business process of which software development is only a small part, so they felt that Kanban was only of limited relevance to them), a sense of ownership of the process amongst workers (completely different to the fear that most non-managers exhibited when Kanban expected them to go idle, or engage in process improvement) and a flow-based rather than batch-based process.
Note I said Kanban requires those things in order to work. Some people believe Kanban can actually cause those things to magically appear, as if a command-and-control manager would suddenly change his mindset after looking at a CFD. It is my experience that a collaborative culture, and a worker owned process is not a result of Kanban, but a prerequisite. But I digress, as usual.
The book provides a gentle introduction to lean and systems thinking in short easy to read chapters full of concrete, real-world examples rather than appeals to academic models and theory. Although many of the examples refer to things like call centers, and plumbing service providers, it is not hard to see how the principles apply to other domains, such as software development. Particularly anyone who has worked with service-orientation or Kanban in the software sector will easily be able to relate to the material. I did notice a lot of overlap with Reinertsen’s Managing the Design Factory, which is not about providing services nor developing and maintaining software, but rather product development, which just goes to show that the basic principles are fairly universal.
I really love the emphasis on learning, learning to think, learning to learn, learning to lead, developing people.
I love that Seddon is not afraid to attack typical sacred cows like targets, certifications and tools. I feel like a lot of people out there involved in process improvement lack some of Seddon’s guts. They fear criticizing obvious dysfunction, claiming it might be disrespecting whoever introduced the dysfunction in the first place, or continues to work in a way that perpetuates the dysfunction. Some people claim that because people gain a sense of self-worth from being really good at working in a dysfunctional way, it is wrong to correct that way because someone loses their self worth. It is a fallacy of course, it assumes the dysfunctions are the “fault” of individuals rather than the system, and also assumes that people would rather not learn new things and perpetuate dysfunction than help improve the system. I can’t imagine Seddon tacitly endorsing dysfunction to spare someone’s ego, and I can’t imagine ever deciding to adopt that approach either.
Heck it seems disrespectful to me to allow someone to keep working in a dysfunctional way rather than help them improve the system.
Anyway it is dinner time so I better wrap this review up.
I loved it, it was one the best books I have ever read, because it felt like it was directly speaking to many of the issues I was facing while reading it, and it helped give me both the courage and practical tips to help fight the causes of the problems we were facing. I consider this book, or perhaps a book similar to it as essential reading for any manager thinking about attempting Kanban. If you aren’t prepared to help fight against command-and-control by following the advice in this book then you will find Kanban rather uncomfortable, and could save yourself and your employees a lot of stress by reconsidering.
I would also recommend it to anyone working outside of software, who hopes to reach the same levels of effectiveness that those in the software development world have been moving towards with the ideas from the lean and agile communities.