According to Wikipedia, inversion of control (IoC) is an object-oriented programming practice whereby the object coupling is bound at run time by an “assembler” object and are typically not knowable at compile time using static analysis. The binding process is achieved through dependency injection. In practice, Inversion of Control is a style of software construction where reusable code controls the execution of problem-specific code. It carries the strong connotation that the reusable code and the problem-specific code are developed independently, which often results in a single integrated application. Inversion of Control as a design guideline serves the following purposes:
1. There is a decoupling of the execution of a certain task from implementation.
2. Every module can focus on what it is designed for.
3. Modules make no assumptions about what other systems do but rely on their contracts.
4. Replacing modules have no side effect on other modules.
Technologists might come to think that an organization and the humans within it operates under the IoC system engineering principle. But then they’d be wrong.
They may believe that:
1. What we want executed is decoupled from implementation – that we can precisely and completely specify the dependencies that will guide implementation. We can specify what must be done to the point where all the implementer must do is think solely about what we have disclosed to them to conduct the matter at hand. No other thought required. There are those who tell and those who do.
2. Every person can focus on what it has been designed (certified) for.
3. That specialization within IT has gotten to the point where individual staff members rely on contracts (e.g. specifications, documentation, job practices) to do implementation. They make no assumptions about other staff members actions. This would give the illusion of being able to focus on “their” work, but also mandates that someone tells them precisely what to assume and thereby relieves them of any extraneous thought or musings about the task at hand. A perfectly efficient system.
4. People, due to specialization, are replaceable modules and their replacement has no side effect on other modules – sorry, people – nor does it effect the outcomes that we intend to achieve.
Yes, it would be wrong if we thought the system engineering definition for IoC applied to people and to the organizations to which we contribute.
The first misstep, in thinking that an organization could operate as if IoC were true for people, would be believing that those who ‘tell’ could capture all the assumptions to the point where no thought is required at implementation – by those who ‘do’. This false notion is founded on the premise that control and certainty can be achieved. This arrogant belief ignores the fundamental human condition that we will ignore elements due to our own self-interests and due to our displeasure with cognitive dissonance. We can’t help but to miss (more strongly – ignore) assumptions.
The next misstep would be in seeing the chain of idea, specification, implementation (or strategy, planning, execution) as a three-step process within an organization or within a single human’s mind. All one needs to do to see the brokenness of this concept is to examine your own idea flow. The imprecise nature of thought is a symphony of brain cells and firing synapse. Our ideas, our specifications (e.g. concepts, mindsets, beliefs, mental models), and our implementation (e.g. experiences, trial/error) have a lively interplay. It is in no way precise. We lie to ourselves if we believe that organizational interplay is less chaotic, unplanned, and that it does not benefit from the multitude of thought.
We are individually and organizationally a symphony of synaptic firing. Organizationally the role of the synapse is social interaction for sharing, making a contribution, and illustrating new perspectives. The interplay co-creates everything.
A third misstep would be believing that replacing one person with another person or contracted activity does not affect the outcome. For this misstep I’d like to focus on the outcome. A caution is that the outcome that you think you want today may not be the outcome you want tomorrow, however you may not be in the position to recognize that change and instead the implementer is. The correctness of what we think we want as the outcome may be negated by the experiences of the implementer. The implementer within the call center may see that treating customers like nameless widgets no longer works, but the correctness of the call center’s efficiency may still work for those directing the call center. IoC as an organizational construct reinforces status quo. Replacing the implementer may obscure an insight about the outcome forever.
With that I call upon us to embrace an alternate definition for inversion of control as it applies to organizations and people. This version of IoC posits that the inverse of control is influence, and that instead of precisely defining execution we instead enable choice and contribution. This inversion of control would recognize the uniqueness of human thought and contribution. It would put humans in a more revered perspective than the technologies that are intended to replace them or the rigid practices which blunt their contribution.