/thinking-systems

---
name: thinking-systems
description: Use when debugging across services/an incident where a fix in one place breaks another, or behavior is emergent and no single component explains it. Maps the system and traces causes.
---

# Systems Thinking

## Overview
Systems thinking views a problem as part of an interconnected whole rather than isolated components. It focuses on relationships, feedback loops, delays, and emergent properties—behaviors that arise from interactions and can't be predicted from parts alone. Its proven payoff is cross-service/incident debugging, where "obvious" single-component fixes fail.

**Core Principle:** The behavior of a system cannot be understood by analyzing components in isolation. Look at connections, feedback, and emergence.

## When to Use
- Debugging issues that span multiple services/components
- A fix in one place breaks something in another
- Behavior is emergent—no single component is at fault, but the whole misbehaves
- Analyzing incidents and outages with non-obvious causes
- Performance issues where the slow part isn't the actual cause

```
Problem spans multiple components?        → yes → APPLY SYSTEMS THINKING
Fix in one place caused issue in another? → yes → APPLY SYSTEMS THINKING
Behavior seems "emergent" or unexpected?  → yes → APPLY SYSTEMS THINKING
```

## When NOT to Use
- A single-component, linear bug (one service, clear stack trace) → just trace and fix it; the systems overhead buys nothing.