It was describing a situation where a developer make a mistake - a quite usual thing to happen, which causes significant losses to the company (some aspect of the change was not considered or was impossible to consider).
If this situation occurs again and again, the organization's risk appetite is reduced, which has a tremendous effect on the culture. A self-reinforcing loop appears:
This entire problem is pretty interesting, because "significant losses" can happen almost only in the following setup :
The situation is more difficult to explain when there is a strong dependency of a higher order system on a mature component. The higher order system may assume that the dependency is stable and will not change suddenly. Problems here will appear if agile approach is used to develop the component. Agile is not only excellent at handling changes, but also welcomes them even at the late stages of development. This, however, may not be acceptable for systems with a lot of higher order systems built on the top of them.
Presented situations were the extremes of the all possible setups. The real cause of the loop is always a combination of the too strong dependency from higher order systems and too light approach to changes from the mature software:
Of course, the question appears how to distinguish between experimental and mature components. There is only one answer - to learn mapping. The concept of evolution and component maturity can be used for many other interesting purposes, not just to avoid a fear of change in the organization.