The Categorization Trap
Every engineer develops a default problem-solving reflex. Some reach for checklists. Others call a meeting. Others start writing code immediately. The reflex feels efficient — until it meets a problem it was never designed for.
Consider three scenarios from a typical week in operations:
- A user cannot log in because their password expired. You reset it. Done.
- A database query that ran fine for months suddenly takes 40 seconds. You need to examine query plans, index statistics, and recent schema changes. It takes a senior DBA two hours.
- A microservices deployment causes intermittent 502 errors, but only for 3% of users, only during peak hours, and only when a specific upstream service is under load. Restarting pods fixes it temporarily, but the problem returns unpredictably.
These three problems look superficially similar — they are all "production issues." But applying the same approach to all three is like using a hammer on a screw, a nail, and a live electrical wire. The first works. The second is suboptimal. The third is dangerous.
To choose the right approach, you first need to understand the nature of the problem itself. This is what complexity frameworks do: they give you a vocabulary and a decision model for matching your response strategy to the type of challenge you face.
The most widely used framework in engineering leadership and incident management is the Cynefin Framework (pronounced kuh-NEV-in, a Welsh word meaning "habitat" or "place of belonging"), developed by Dave Snowden while at IBM Global Services in 1999. It classifies problems into domains based on the relationship between cause and effect — specifically, whether that relationship is obvious, discoverable, emergent, or absent.
Key Point: Cynefin is not an academic exercise. It is a decision-making tool. The single most important output of applying it is choosing the correct action strategy — not just labeling the problem. Misclassifying a Complex problem as Complicated (and therefore assigning an "expert" to "analyze" it) is one of the most common and costly mistakes in incident response and platform engineering.