From Theory to Daily Practice
Cynefin is not just a framework for incident response. It shapes how you design systems, structure teams, and make investment decisions across the entire platform engineering lifecycle.
Incident Management:
The first question in any incident should not be "What's the root cause?" but "What domain are we in?" This single question determines your entire response posture:
- Clear: Follow the runbook. If no runbook exists, create one after the incident. Escalate if the runbook is missing.
- Complicated: Pull in the subject matter expert. Give them time and space to investigate. Resist the urge to "help" by guessing.
- Complex: Resist the urge to find the root cause. Instead, form hypotheses, run safe experiments, and increase observability. Accept that you may never find a single root cause — the cause may be emergent.
- Chaotic: Stop debating. Someone with authority makes a call. Act now, analyze later. The incident commander's job is to establish order, not to be right.
Automation Strategy:
Cynefin tells you what to automate and what not to:
- Clear problems should be fully automated: self-healing, auto-scaling, certificate renewal, disk cleanup.
- Complicated problems should be partially automated: automated data collection and diagnosis, with human decision-making at the conclusion.
- Complex problems should not be automated in the traditional sense — instead, automate the experimentation infrastructure: feature flags, canary pipelines, observability tooling.
- Chaotic problems need pre-built "break glass" automation: emergency rollback scripts, kill switches, network isolation policies.
Team Structure:
- Clear work can be handled by any team member following documentation. The goal is to eliminate this work through automation.
- Complicated work requires specialists or experienced engineers. Pair them with junior engineers to transfer knowledge.
- Complex work requires cross-functional collaboration — no single expert has the full picture. Diverse perspectives are a feature, not a luxury.
- Chaotic work requires a clear incident commander with authority to make unilateral decisions. Consensus-seeking during chaos is itself a failure mode.
Tooling Investment:
| Domain | Invest In |
|---|---|
| Clear | Automation, self-service portals, Infrastructure as Code, runbook automation |
| Complicated | Expertise development, runbooks, diagnostic tooling, APM platforms |
| Complex | Distributed tracing, high-cardinality metrics, feature flags, canary analysis, chaos engineering |
| Chaotic | Incident response drills, communication tools (war rooms, status pages), pre-built recovery procedures |
Shifting Problems Between Domains:
The highest-leverage activity in platform engineering is deliberately moving problems toward simpler domains:
- Every runbook you write shifts a Complicated problem toward Clear.
- Every observability improvement shifts a Complex problem toward Complicated (you can now see the cause-and-effect relationship).
- Every chaos engineering experiment shifts a potential Chaotic surprise toward a known Complex scenario.
- Every automation script shifts a Clear problem out of human hands entirely.
The goal is not to eliminate complexity — distributed systems are inherently complex and will remain so. The goal is to manage the portfolio of problems across domains deliberately, investing in the right tools and practices for each domain rather than applying a uniform approach to everything.
When asked about your approach to reliability or incident management, framing your answer around Cynefin domains demonstrates systems thinking maturity. For example: "I categorize operational work by complexity domain. Clear problems get automated away. Complicated problems get runbooks and expert escalation paths. Complex problems get observability investment and safe-to-fail experimentation. This ensures we're applying the right strategy to each type of problem rather than treating everything the same way." This answer shows you think in systems, not just in tools.
Key Point: The most common failure mode in platform engineering is applying a single strategy uniformly across all problem types. Teams that treat every incident as Complicated (assign an expert, analyze, fix) will be slow and ineffective against Complex problems. Teams that treat every incident as Complex (experiment, observe) will be dangerously slow against Chaotic situations. Cynefin's value is not in the labels — it is in the discipline of asking "which domain is this?" before choosing a strategy.