Accidental Adversaries

Description

"Accidental Adversaries" is a treacherous system archetype. Two actors, such as teams, services, or departments, start a cooperative partnership to achieve shared growth goals. At some point, Team A comes under slight pressure and takes a local action to relieve itself. That action unintentionally sabotages Team B's success. Team B, now under pressure as well, responds with its own selfish protective measures, which in turn hurt Team A badly. A destructive downward spiral begins and ends with two parties that hate each other even though they actually want the same thing.

Feedback Loops

The structure often begins with a positive reinforcing loop of shared growth. Then a local balancing loop emerges as Team A optimizes its own bottleneck. But that balancing loop has an unnoticed side branch: a delayed negative effect fires on Team B's side and cuts its performance. Team B answers with its own local balancing loop, whose side branch fires back at Team A. The result is a toxic ping-pong effect of mutual damage.

Architecture Example

Two microservices, Order and Payment, work well together as a distributed system. The Payment team runs into performance issues and tightens its scaling limits aggressively as a local optimization. When traffic spikes arrive, Payment starts throttling requests hard with rate limiting. The Order team suddenly receives a flood of timeouts. To save its own SLA, another local optimization, it builds extremely aggressive retry loops that hammer Payment without mercy. Payment collapses under the retries. Both services have effectively orchestrated a DDoS attack against each other through supposedly sensible best practices.

Organizational Example

A DevOps team and a platform engineering team both want to help developers. The platform side ships a new Kubernetes deployment feature with poor documentation so it can still hit the sprint goal. Ops gets flooded with incident tickets. To protect itself, Ops refuses to roll out further updates until strict ten-page manuals are submitted in advance. The platform team gets frustrated by the bureaucratic resistance and bypasses the Ops pipelines with shadow tooling. Trust is destroyed. Both teams start blocking each other.

Diagnostic Questions

1.Do we have teams that constantly blame one another in meetings even though management gave them the same annual target?

2.Where are we building aggressive protective mechanisms in code, like circuit breakers or rate limits against neighboring internal services, instead of sitting down with the neighboring team?

3.Are we mistaking malicious intent by individual developers for a broken incentive structure that almost forces everyone to act selfishly?

Diagram

How to Recognize the Pattern in Daily Work

Escaping this archetype requires radical de-escalation and de-siloing. It is useless when management merely shouts, "Just work together already." Both parties must understand that their seemingly logical local defenses are mathematically enlarging the overall problem. The system boundary in their heads has to expand. They can no longer look at the issue in isolation but must include the loop through the other team in their own mental model.

What Distinguishes the Pattern from Similar Dynamics

Unlike the *Escalation* archetype, where two parties are knowingly engaged in competition or an arms race from the start, *Accidental Adversaries* begin as partners. The adversarial relationship emerges unintentionally through blind local optimization without consultation.

How to Move from Pattern to Response

If you recognize this archetype, bring the actors together immediately. Let both teams draw their local problems on a whiteboard. Then connect the boxes from both teams. The breakthrough happens when both sides see how their own "solutions" are causing exactly the pain the other side is trying to escape. Then remove the local defensive measures and search for a global solution that respects both capacities, for example shared backpressure handling in code.

First Next Steps

Measure collaboration success with a combined end-to-end metric such as lead time to production, not with local team metrics like "Our service had 100% uptime, so we do not care that yours was on fire."

How to Recognize the Pattern with Confidence

When we introduced aggressive retry behavior in the API gateway, did we consider that in the worst case we might knock over our own legacy database?

Sources

Peter Senge - The Fifth Discipline, ch. 6: Archetypes

The Systems Thinker: Accidental Adversaries

Wikipedia: System Archetypes