Most organisations respond to delivery problems in the same way: they improve the process. More steps are added, new checks appear, handoffs are formalised and expectations are documented. Each change is reasonable. Each change is well intentioned. And yet, in many teams, delivery becomes slower, coordination heavier and risk harder to see. This is not because process improvement is wrong. It is because complex systems do not respond linearly to control. Why more structure does not always mean more stability Why more structure does not always mean more stability Processes are usually introduced after something goes wrong. An incident happens, a release fails, a dependency breaks under load. The organisation looks for gaps: a missing review, an unclear responsibility, a step that was skipped. The solution often feels obvious. Add a rule. Add a checkpoint. Add approval. I have seen this pattern repeatedly in regulated environments where failure is expensive. Each incident triggered a new layer of process. Over time, the system became more structured, but also harder to reason about. The original problem disappeared, yet new failure modes emerged elsewhere, often far from the change that introduced them. In isolation, these decisions made sense. But systems do not experience process changes in isolation. They experience them as accumulated friction. How teams adapt to heavy process How teams adapt to heavy process When processes become heavier, people rarely stop delivering. Instead, they adapt. In one organisation, review cycles were extended to reduce risk. Releases continued, but engineers started batching work to avoid repeated context switching. Feedback arrived later. Small issues grew larger before being noticed. The system still “worked”, but responsiveness quietly declined. In another case, strict ownership rules improved accountability on paper, while informal coordination increased in practice. Decisions moved to private conversations and ad-hoc agreements, because formal paths were too slow for day-to-day delivery. None of this was malicious. It was normal system behaviour under constraint. The illusion of control The illusion of control Highly structured systems often feel controlled. Dashboards show compliance. Checklists are completed. Audits pass. From a management perspective, everything appears stable. But control and understanding are not the same thing. I have worked in environments where every release followed the defined process perfectly, yet incidents still clustered around the same areas. The system complied, but the behaviour beneath it was drifting. Pressure was being absorbed by people rather than by design. Risk did not disappear. It relocated. Where risk hides after process changes Where risk hides after process changes After heavy process changes, risk often moves into places that are harder to measure. It accumulates between approvals, between teams, and between responsibility boundaries. Work waits longer than expected. Context degrades during handoffs. Decisions are delayed until timing, rather than quality, drives outcomes. In practice, teams compensate. Senior contributors step in more often. Knowledge concentrates. Informal dependencies grow. Success becomes increasingly dependent on who is available, rather than on how the system is designed. This is usually invisible until something breaks. When improvement increases fragility When improvement increases fragility One of the most counterintuitive patterns in complex systems is that improving local efficiency can reduce global stability. A faster review stage can overload downstream teams. A stricter gate can delay feedback until change becomes expensive. A well-defined ownership model can discourage cross-functional responsibility. I have seen teams celebrate improved metrics immediately after a process change, only to face more severe incidents months later. The system looked healthier in snapshots, but its ability to absorb variation had quietly weakened. Shifting the focus from process to behaviour Shifting the focus from process to behaviour Processes describe how work should move. Behaviour shows how work actually moves. To understand whether a change improves or harms a system, teams need to observe patterns over time. How long does work wait between steps? Where do decisions slow down under pressure? Which paths do people bypass to keep delivery moving? Where does informal coordination replace formal flow? These signals rarely appear in reports. They emerge only when delivery is observed across cycles, not events. Designing for adaptability, not control Designing for adaptability, not control Healthy systems are not defined by perfect compliance. They are defined by their ability to adapt without accumulating hidden risk. This requires faster feedback, clearer signals of delay and pressure, and fewer brittle handoffs. Processes should support these outcomes, not replace them. Closing reflection Closing reflection The most fragile systems I have worked with were not chaotic. They were disciplined, busy and outwardly stable. Their weakness was not lack of effort or skill. It was the slow drift caused by normal work done under constant pressure. Learning to see that drift — before it becomes visible through failure — is one of the most valuable capabilities an organisation can develop. Over time, observing these patterns became the basis for how I analyse delivery systems today. Rather than evaluating isolated changes or individual actions, I focus on how coordination, flow and feedback evolve under constraint, long before incidents force attention. Not to eliminate risk entirely. But to understand it while there is still room to act.

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

When Improving Processes Makes System Worse

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

When Delivery Fails Quietly: Why Most Risks Accumulate Long Before Incidents

3 Non-Monetary Ways To Incentivise Your Developer Team

5 Metrics Engineering Managers Can Extract from Pull Requests

7 Proven Practices to Boost Development Speed and Project Quality

Build Products, Not Projects

Craft Culture by Celebrating Deployments

When Delivery Fails Quietly: Why Most Risks Accumulate Long Before Incidents

3 Non-Monetary Ways To Incentivise Your Developer Team

5 Metrics Engineering Managers Can Extract from Pull Requests

7 Proven Practices to Boost Development Speed and Project Quality

Build Products, Not Projects

Craft Culture by Celebrating Deployments

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps