In a previous blog article, I mentioned how I was getting back to my programming roots and reading The Principles of Product Development FLOW: Second Generation Lean Product Development by Donald G. Reinertsen. I am in the process of reviewing each chapter. I have already posted my reviews of:
- Chapter 1. "The Principles of Flow"
- Chapter 2. "The Economic View"
- Chapter 3. "Managing Queues"
- Chapter 4. "Exploiting Variability"
- Chapter 5. "Reducing Batch Size"
- Chapter 6. "Applying WIP Constraints"
- Chapter 7. "Controlling Flow Under Uncertainty"
- Chapter 8. "Using Fast Feedback"
Here is my review of "Chapter 9: Achieving Decentralized Control." As the chapter title suggests, when organizing a company or department, there is a choice between centralized and decentralized control, and the author makes the case for decentralized control.
The chapter highlights the differences:
| Aspect | Centralized Control | Decentralized Control |
|---|---|---|
| Decision Making | Occurs with consistency across projects. | Can vary from project to project. |
| Timeliness | Project may wait for an available slot in an overall organizational schedule. | Can be immediate based on the needs of the project. |
| Appropriateness | "...works well for problems that are infrequent, large, or those with scale economies." [page 265] | "...works well for problems and opportunities that are perishable." [page 265] |
One of the benefits of decentralized control is quicker decision making. There is a passage in the chapter that captures my essence:
The Marine Corps does not view initiative as one of many virtues that could be present in a leader. They view it as the most critical quality. They are very sensitive to the risk created by stifling initiative. As a result, they consider inaction and lack of decisiveness to be much more dangerous than making a bad decision. An imperfect decision executed rapidly is far better than a perfect decision that is executed late. [page 263]
The author points out that one way to accelerate decision making is have it happen as close to the project as possible. This is done by involving fewer and fewer layers of management. "We need to avoid overloading the limited bandwidth at high management levels by ensuring the majority of decisions can be made at low levels of the organization." [page 261]
When I developed software for GTE, we had a functional organization. As the name suggests, the company was divided into departments based on the functions they performed as part of developing hardware and software for the telecommunications industry. For example, later in my career, I was the software development manager for the operating system group. The operating system was part of all of the various phone switch-related projects. My job was to balance the needs of the various projects and ensure that all projects had the right amount of resources, met their schedules, and attained the level of quality expected. From a project perspective, with regard to operating system development, GTE had centralized control.
At Autodesk, with regard to product development, we have a mix of organization types. Departments like Legal, HR, and Finance are core to the company and represent centralized control. In contrast, product development is grouped by the project they are working on. For example, we have teams dedicated to AutoCAD releases, Inventor releases, Revit releases, Fusion 360 deployments, 3ds Max releases, and Maya releases. This decentralized control approach has been in place for years.; however, as we forward, we see a need to make our products interoperate more closely and have a more consistent user experience. As such, we're taking a more holistic approach to how we develop software. So there are aspects of centralized control that can also apply to organizations with decentralized control.
Control is alive in the lab.
Subscribe
Facebook
Twitter
LinkedIn
Instagram