Positive & negative feedback
One more point you should pay close attention to is whether the feedback mechanism in your system is actually correct.
Water is pulled by gravity. You should not expect it to flow through a pipeline if the pipeline is designed incorrectly. The system will follow its natural forces, not your intentions.
The same applies to organizational and technical systems.
If you pay a team for every urgent incident they resolve, you should not be surprised when you get too many urgent incidents.
If every failed request to a server triggers another request to the same server to investigate the failure, you can end up creating a DDoS attack generated by your own clients.
If a stock market rewards investment based on the speed at which a company’s share price is increasing, rather than on the company’s actual value, you will eventually get a speculative bubble.
In all these cases, the system is simply amplifying the signal you gave it.
So the key question is:
What value are you actually amplifying?
Check your feedback loops carefully. You may be trying to optimize one thing while your system is actually rewarding something completely different.
Removing components changes the system
Pay close attention when removing a component from a system.
When you remove a component, you are not only reducing the number of components. You are also removing the relationships, dependencies, and effects associated with it. Some information flows or artifact pipelines may disappear with it, while others may be redirected or disrupted.
These secondary effects are easy to overlook.
Some relationships will recover by themselves as the system adapts. Others will require additional time and energy to restore. And some relationships will need to be actively managed and guided by you.
Therefore, removing a component should not be viewed simply as subtracting one element from the system. You need to consider which relationships disappear with it, which ones will adapt automatically, and which ones require deliberate intervention to keep the system functioning.
Conclusions
In a complex system, the hardest part is rarely the repair itself — it is understanding what actually failed, because the system will hide the original problem behind its own workarounds. Most of what makes such a system hard to manage is invisible: the relationships between components, not the components themselves, which is why removing one element is never simply subtraction. Feedback loops decide what the system will amplify, and it will amplify what you actually reward, not what you intended. Basins of attraction decide where it will settle, so the real cost of a decision includes the cost of leaving the state you are moving into.
So be patient with your system. Be an explorer: discover it, pay attention to the relationships and the details, learn it, listen to it. A complex system will tell you how it behaves long before it tells you why — but only if you are watching.
My north star is to build feedback loops, attractors, and motivations that let the system keep forming productive relationships on its own. Design it that way, and flexibility and scalability become properties of the system rather than things you bolt on later.