A change fixes the problem it targeted and makes the overall situation worse. What second-order effects should an architect learn to anticipate?

The recurring shapes

Moving the bottleneck, not removing it. Making one service faster shifts load to the next, which was previously protected by the first's slowness. A speed improvement can cause an outage downstream, and the team that made the improvement is not the team that is paged.

Shifting the cost to a different team. A change that improves one service's latency by pushing work to its callers is a local optimum and a global regression, and it is invisible in the optimising team's metrics.

Removing a constraint that was providing safety. Rate limits, queue bounds, manual approvals and slow deployments frequently do something useful that nobody documented. Removing friction removes whatever the friction was accidentally preventing — a lesson that recurs constantly with approval processes.

Creating a new dependency while removing an old one. A cache removes database load and creates a cache dependency, a new failure mode, and an origin no longer sized for uncached traffic.

Incentive effects. Any measure that becomes a target is optimised directly: deployment frequency produces trivial deployments, code coverage produces assertion-free tests, ticket closure produces closed tickets.

Automation that erodes the skill it replaced. A manual process automated for years leaves nobody able to perform it when the automation fails — and it fails during the incident, when the skill is needed. The Southwest scheduling collapse has exactly this shape: the manual fallback existed and could not operate at the required rate.

The habits that catch them

• "Then what?", repeatedly. If this service becomes twice as fast, then what? If this queue never backs up, then what? Three iterations of that question find most second-order effects.
• Ask who else is affected, including teams not in the room — which is where the cost usually lands.
• Ask what this constraint was doing. Before removing any limit, throttle or gate, establish what it was protecting. The answer is frequently "nothing" and occasionally "everything."
• Look for feedback loops: does the change make the input to itself larger or smaller? Positive feedback is what turns an incident into an outage.
• Ask what people will do differently. Systems include people, and their behaviour adapts to changes in the system faster than the system does.
• Consider the failure case of the improvement, not just its success case.

The practical guard

Change one thing, observe, then change the next. Simultaneous changes make second-order effects unattributable, which is why "we improved five things and something got worse" is such a common and irresolvable situation.

And instrument the thing you expect to be affected next, before making the change — so the second-order effect is observed rather than discovered.