Organizational Viscosity
In the classical article named “Design Principles and Design Patterns“, Bob Martin (Uncle Bob) defines Viscosity and talks about 2 types of Viscosity from a software design point of view:
Viscosity comes in two forms: viscosity of the design, and viscosity of the environment. When faced with a change, engineers usually find more than one way to make the change. Some of the ways preserve the design, others do not (i.e. they are hacks.) When the design preserving methods are harder to employ than the hacks, then the viscosity of the design is high. It is easy to do the wrong thing, but hard to do the right thing.
Viscosity of environment comes about when the development environment is slow and inefficient. For example, if compile times are very long, engineers will be tempted to make changes that don’t force large recompiles, even though those changes are not optiimal from a design point of view. If the source code control system requires hours to check in just a few files, then engineers will be tempted to make changes that require as few check-ins as possible, regardless of whether the design is preserved.
This is a great explanation of how Viscosity applies in development process. I think the same thought process can be applied to the way an organization operates.
Some organizations have really high viscosity and trying to do the right thing, which is inline with the organizational value system, becomes harder and harder (sometimes impossible). Doing the wrong thing and getting away with it, seems so much easier. Its not just easy its also always quick. It turns out that there are no real motivations for employees to do the right thing. And then the broken window syndrome sets in.
Such organizations soon become endangered species.
