Delegation of control is the best way to keep software projects manageable. And that's not just because our projects behave like wild kangaroos, and wild kangaroos happen to be constructed that way. Smart managers among us simply deduce this in three easy steps.
Step 1: The Conant-Ashby Theorem "Every good regulator of a system must have a model of that system."
When we want to control something, we need a model of it. That's what this theorem says. To construct such a model (our mental representation) we use the information that the system provides. Some examples:
A pilot uses the information in a cockpit to understand what the aircraft is doing, and to control it.
A traffic controller uses information on radar screens to envision the air space around an airport and to control the traffic in it.
A project manager uses meetings, charts and reports to understand how a project is progressing, and to steer it.
A mother uses the things her child says and does to understand what it wants, and to make sure the child does what she wants.
The obvious problem here is this:
Control of a system can only be as good as the quality of the information that is available from the system.
The less information there is about a system, or the less accurate it is, the worse our ability to create a proper mental representation of it. And without a good model, the Conant-Ashby Theorem kicks in to tell us we cannot be good regulators.
Well, that's quite an open door so far, isn't it?
Step 2: The Jurgen Appelo Postulate "The more complex a system is, the less able we are to construct a proper model of it."
With complex systems the available information for a controller is either too complex to comprehend, or not enough for a model of the entire system. Just try to imagine a complete map of London that enables you to control everything in the city. Either way you have too much information to work with, or too little to be able to do your job. With complex systems, as a controller, you're doomed!
Step 3: The Law of Ken Schwaber "As complexity increases, central control breaks down."
This is what Ken Schwaber wrote in one of his Scrum books, and I’m repeating it here. It's the logical conclusion of step 1 and step 2. The more complex a system is, the less we can control it. (And software projects can be very, very complex.)
Fortunately, there's a simple solution: Delegation of Control
Traffic controllers don't manage the aircraft. They let the pilots do that.
Pilots hardly do controlling themselves. Much of it is delegated to automated systems.
Project managers delegate activities to team leaders, architects, test managers, etc.
Mothers use psychological tricks to make their children's brains manage themselves.
Delegation of control is just a way of managing complexity.
You push responsibilities down to a level where someone has information that is less voluminous and more accurate. And most important: this delegation of control includes the ability to make decisions on the lower level!
So, that's how smart managers look at this stuff. They understand that they must try to make as few decisions as possible. For better overall control, the rest of the decisions should be made by those in the subsystems.
OK, what about us simple managers? Of course, there's also a version of this story for simple managers. It's in just about every management book at Amazon. They've even invented management terms for it, so that we simple managers can understand it too…