Why you need a reusable ontology of failure
The goal is not merely to have categories, but to have a small, reusable ontology of failure and improvement that can be applied to anything: a production outage at 2am, a fight with your spouse, a stalled volunteer programme, or a spiritual drought.
Most people carry an implicit and therefore inconsistent theory of problems. Asked why the deployment failed, they blame the engineer. Asked why the marriage struggled, they blame miscommunication. Asked why the volunteer programme collapsed, they blame lack of resources. Each domain gets its own private vocabulary, and nothing transfers.
The Universal Problem Taxonomy solves this by giving you six stable buckets that work across every domain of human life. The abstraction is high enough to be universal, but low enough to generate concrete interventions.
When something goes wrong, the first question is always:
Is this primarily a Human, Process, System, Resource, Relationship, or Environment problem?
That single question — applied consistently — produces more useful diagnoses than most formal post-mortems or relationship counselling sessions.
The Three-Step Shortcut
Under stress, you cannot run a twenty-category analysis. Keep this sequence. It takes under two minutes and produces actionable output every time.
Diagnosis Protocol
Which of the six categories is the main driver of this failure? Pick one. Resist the temptation to say "it's everything" — that is the same as saying nothing.
Each bucket contains 3–6 named subtypes. Pick the one that best characterises this instance. One only. Precision at this step is what separates useful diagnosis from vague hand-waving.
Example: "Human → Motivation Gap" is more actionable than just "Human."
Not the most satisfying. Not the most obvious. The one most likely to prevent this from happening again. This question keeps you from turning categorisation into an intellectual hobby.
Example: For a Skill Gap, "more practice with feedback" reduces recurrence far more than "document the process."
1. Human Problems
The individual is the primary bottleneck. There are six distinct ways a person can fail a task — and the intervention differs sharply between them.
Knowledge Gap
The person doesn't know what they need to know. This is the most straightforward human failure — and the easiest to fix if caught early.
- New engineer doesn't understand Kubernetes networking
- Child doesn't know the household rule that was assumed obvious
- Volunteer doesn't understand the vision behind the project
- Person unaware of a relevant fiqh ruling
- Training, documentation, onboarding
- Mentorship and accessible reference material
- Never assume — make explicit what you consider obvious
Skill Gap
Knows what to do but cannot execute reliably. Competence requires more than knowledge — it requires embodied, practised ability. This gap is often misdiagnosed as laziness.
- Knows Git concepts but cannot resolve a complex merge conflict
- Knows anger is harmful but cannot regulate it in the moment
- Understands public speaking principles but freezes under pressure
- Knows Arabic grammar rules but cannot produce fluent sentences
- Deliberate practice with feedback loops
- Coaching and scenario simulation
- Lower-stakes reps before high-stakes moments
Judgment Gap
Incorrect decisions despite sufficient knowledge and skill. This is the most dangerous gap because it is hardest to detect — the person appears competent but makes consistently wrong calls.
- Poor prioritisation — correct work, wrong order
- Wrong diagnosis of a technical or relational problem
- Misreading social cues, tone, or intent
- Overconfidence causing avoidance of necessary checks
- Engineer rolls back when the correct action is a hotfix forward
- Decision frameworks and pre-mortems
- Structured reflection after consequential decisions
- Exposure to experienced mentors with different pattern libraries
Attention Gap
Important signals were present but not registered. Modern environments produce far more signals than humans can track. This gap is structural, not moral — but the consequences are real.
- Monitoring alert dismissed during a busy sprint
- Forgot spouse's request made two weeks ago
- Missed risk indicator buried in a weekly report
- Deadline not noted because it was communicated verbally
- Checklists and external memory systems
- Reduce cognitive load — fewer open loops
- Structured review cadences (weekly review, morning intention)
Motivation Gap
Knows and can do, but won't — or consistently delays. Unlike laziness (which is often a misdiagnosis), genuine motivation gaps have identifiable psychological roots: misalignment, meaninglessness, fear, or spiritual stagnation.
- Procrastination on tasks that feel meaningless
- Lack of ownership on a project assigned without context
- Avoidance of a difficult conversation with no felt urgency
- Spiritual laziness — knowing the practice but not starting
- Connect the task to a larger meaning or purpose
- Accountability structures with real social stakes
- Reduce activation cost — make the first step trivially easy
Emotional Regulation Gap
Emotions overwhelm or hijack execution. The person's capacity is theoretically present, but emotional hijacking prevents deployment. This is the most overlooked of the six — especially in high-achievement cultures that pathologise emotional acknowledgment.
- Panic during a production outage leads to compounding mistakes
- Anger during a conflict destroys the repair attempt
- Anxiety causes paralysis on a high-stakes decision
- Fear of failure prevents shipping the nearly-ready product
- Emotional awareness practices (naming states in real time)
- Pre-loaded protocols for high-stress scenarios
- Spiritual practices that build equanimity as a baseline state
2. Process Problems
The structure for getting things done is missing, ambiguous, ignored, or over-engineered. Process problems are often mistaken for human problems — "the person failed" when actually "the system had no guardrail."
Missing Process
No structure exists where one is needed. Absence of process is not freedom — it is unstructured risk exposure. Things work when conditions are ideal and break catastrophically when they're not.
- No deployment checklist — each engineer does it differently
- No onboarding process — new hires find their own way
- No family budget review — money decisions made ad hoc
- No incident response runbook — each outage improvised
- Create a minimal viable process first
- Document what the best performers already do implicitly
Unclear Process
A process exists but is ambiguous, inconsistently interpreted, or has unclear ownership. Multiple interpretations of the same process are as damaging as no process.
- Nobody knows who owns the final deployment approval
- Instructions say "review before merging" — but review means different things
- Household division of labour was "agreed" but never specified
- Specify ownership explicitly (RACI if necessary)
- Make the ambiguous step concrete — define done
Process Not Followed
The process exists and is clear, but was bypassed. This is usually a symptom of another problem (process too slow, low trust in the process, time pressure, or individual judgment gap) rather than simple defiance.
- Code pushed directly to production, bypassing code review
- Safety checklist skipped because "we've done this a hundred times"
- Communication step in a family disagreement protocol skipped in anger
- Diagnose why it was skipped before prescribing enforcement
- Automate what can be automated — reduce bypass opportunity
- Rebuild trust in the process by demonstrating its value
Process Too Complex
The process is so burdensome that compliance itself becomes the bottleneck. This is common in mature organisations and over-engineered families. Complexity accumulates silently — no single addition seems unreasonable, but the whole becomes unusable.
- 20-step deployment pipeline where 12 steps add no safety
- Approval chain requiring 5 sign-offs for a $200 decision
- Family rules that have accumulated into an unenforceable rulebook
- Audit: for each step, ask "what failure does this prevent?"
- Remove steps that protect against failures that never occur
3. System Problems
The structure itself produces failure — reliably and repeatedly, regardless of which humans occupy the roles. Blame the system, not the person.
System problems are the most important to identify correctly because they resist all human-level interventions. If the incentive structure rewards speed over quality, you can train engineers in quality practices all day — the system will win. The intervention must operate at the system level.
Design Flaw
The architecture of the system has a structural weakness that makes failure highly probable or inevitable. This includes technical architecture, organisational structure, and relationship structures.
- Single point of failure in a critical infrastructure component
- Organisational design that routes all decisions through one person
- A family structure where one parent is always the enforcer and one the refuge — no integrated authority
- A service mesh with no circuit breakers
- Redesign the architecture — no patch will hold
- Introduce redundancy and distributed decision rights
Feedback Loop Failure
The system produces no signal when it is degrading. Problems grow invisibly until they reach crisis threshold. Fast feedback is the immune system of any healthy system.
- No monitoring — first sign of the outage is a customer call
- No performance review — employee's trajectory unknown until it's too late
- No regular check-ins in a relationship — small resentments compound unaddressed
- No muhasebe (self-accounting) practice — spiritual decay undetected
- Install leading indicators, not just lagging ones
- Build regular reflection into the cadence — daily, weekly, quarterly
Misaligned Incentives
The reward structure optimises for the wrong outcome. People behave rationally given the incentives they face — if the incentives produce bad behaviour, change the incentives.
- Engineers rewarded for velocity, not reliability — technical debt accumulates
- Social praise for surface piety rather than depth — performance replaces sincerity
- Parental attention goes to distressed behaviour — child learns distress is the access code
- Business metric rewards ticket close rate — root causes get papered over
- Map what is actually being rewarded, not what you intend to reward
- Redesign the reward structure — and monitor for unintended new misalignments
Capacity Mismatch
Demand exceeds the system's designed capacity. This produces chronic degradation — not a single catastrophic failure but a grinding erosion of quality, morale, and margin.
- Team chronically at 120% capacity — every sprint cuts corners
- Parent exhausted from dual career and full-time caregiving — no reserve for repair
- Server undersized for actual traffic — constant throttling
- Volunteer programme with more commitments than volunteers
- Increase capacity or reduce demand — doing both is ideal
- Do not try to solve a capacity problem with motivation interventions
4. Resource Problems
Insufficient inputs. The work cannot be done at the required level regardless of human capability, because the raw materials are not there. Unlike human or process problems, resource problems are often genuinely outside the individual's control.
Time
Unrealistic deadlines, chronic overcommitment, or insufficient calendar protection for deep work.
Money
Budget constraints, underfunded initiatives, or financial pressure that forecloses necessary options.
Tools
Outdated software, broken equipment, or missing infrastructure that creates unnecessary friction in every step.
Information
Missing requirements, incomplete context, or withheld data that makes correct decisions structurally impossible.
People
Understaffed team, insufficient expertise on the bench, or lack of volunteers for a programme's scope.
Energy
Physical or emotional depletion that degrades every other resource. Often the unacknowledged root cause.
Diagnostic caution
A genuine resource problem requires a supply intervention (more time, budget, people). A motivation gap masquerading as a resource problem requires meaning and accountability. Misdiagnosing one as the other is common — and expensive. Ask: if we doubled the resource, would the outcome change? If yes, it's probably a resource problem. If not, look at motivation or system.
5. Relationship Problems
Trust and coordination failures between two or more people. These problems travel with particular diagnostic invisibility — they present as process failures, resource failures, or human failures, while the root is actually relational.
Trust Deficit
One or both parties withhold full engagement because they expect bad faith, incompetence, or betrayal. Trust is the invisible infrastructure of all cooperation — when it degrades, everything slows and distorts.
- Team withholds concerns from leadership — they expect dismissal
- Spouse assumes bad intentions behind an innocent question
- Engineer doesn't flag a risk because "it'll just get ignored"
- Community member disengages without saying why
- Repair through demonstrated reliability over repeated cycles
- Increase transparency — explain decisions, especially unpopular ones
- Never punish vulnerability — the first time someone shares a concern
Expectation Mismatch
Different parties operate under different assumptions about roles, standards, or what success looks like. Neither party is failing — they are executing their mental model faithfully. The models just don't match.
- Two engineers have different definitions of "done" for a ticket
- Partners have different assumptions about who handles what at home
- Manager expects initiative; employee expects direction
- Volunteer expects recognition; organiser expects self-sufficiency
- Surface implicit expectations and make them explicit agreements
- Revisit agreements as circumstances change
Communication Failure
Important information was not transmitted accurately. This is the most commonly cited relationship problem — and often a symptom rather than the root cause. Ask why the communication failed before treating it as a standalone problem.
- Critical architecture decision communicated in a Slack thread nobody reads
- Concern mentioned once in passing, expected to be acted on
- Emotional subtext in a message interpreted as its opposite
- Important request made during an argument — timing guaranteed it wouldn't land
- Match channel to importance — critical things need synchronous loops
- Close communication loops: sender confirms receipt and understanding
Value Conflict
Two parties hold genuinely different values that produce incompatible priorities. This is the hardest relationship problem to resolve — because neither party is wrong by their own lights. It requires either alignment, negotiated co-existence, or, in the limit case, separation.
- Engineering: efficiency vs. resilience — speed vs. correctness
- Family: autonomy vs. order — child's freedom vs. parent's structure
- Organisational: innovation vs. stability — change vs. preservation
- Spiritual community: compassion vs. boundaries — inclusion vs. integrity
- Name the value conflict explicitly — most conflicts are never named
- Agree on which value takes precedence in which contexts
- Do not try to win the argument — try to produce a workable arrangement
6. Environment Problems
Forces outside the system's direct control. The critical task here is not to solve the environment — it is to correctly distinguish environmental problems from addressable ones, and to build systems robust enough to absorb the variation that cannot be prevented.
Random Variation
Normal statistical noise in the environment. Not every deviation is a signal requiring intervention — treating noise as signal is one of the most common managerial errors.
- Weather causing supply chain delay
- Illness disrupting a meeting's outcome
- Market fluctuation unrelated to business fundamentals
- A child's off day that doesn't reflect a pattern
- Build slack and buffers — not tighter controls
- Distinguish one-time variation from trend before acting
External Constraint
Regulatory, legal, economic, or political forces that constrain what the system can do. These are real constraints — but they are often treated as more absolute than they actually are.
- Compliance requirements adding overhead to deployment
- Economic conditions limiting hiring
- Vendor limitations blocking a desired architecture
- Legal constraints on a service's geographic expansion
- Distinguish "cannot" from "would be costly to" — often the latter
- Work within constraints rather than pretending they don't exist
Black Swan Event
A rare, high-impact event outside the range of normal expectation. The appropriate response is not prevention (which is impossible) but resilience: designing systems that can survive and recover.
- Pandemic disrupting every assumption about work and service
- Major cloud provider outage taking down dependent services
- Natural disaster affecting an entire community's capacity
- Sudden loss that restructures a family's functioning
- Invest in resilience — redundancy, diversification, recovery plans
- Run scenario exercises before the event, not postmortems after
Chronic Ambient Pressure
A sustained environmental condition — economic, social, political, or cultural — that degrades performance over time without a single identifiable cause. Often invisible because it is constant.
- Years of political persecution affecting a community's psychology
- Sustained economic insecurity shaping family risk tolerance
- Toxic industry culture normalising unhealthy practices
- Chronic loneliness affecting spiritual engagement
- Name the ambient condition — most people haven't articulated it
- Create protected environments that temporarily lift the pressure
Quick Reference Summary
The full taxonomy at a glance. Use this as a scanning layer before applying the three-step protocol.
| Bucket | Subtype | Signature Question | Primary Intervention |
|---|---|---|---|
| Human | Knowledge Gap | Do they know what to do? | Training, documentation |
| Skill Gap | Can they do it reliably? | Deliberate practice + feedback | |
| Judgment Gap | Are their decisions correct? | Decision frameworks, mentorship | |
| Attention Gap | Did they register the signal? | Checklists, reduced cognitive load | |
| Motivation Gap | Are they engaged? | Meaning alignment, accountability | |
| Emotional Regulation Gap | Are emotions interfering? | Awareness practices, protocols | |
| Process | Missing Process | Is there a process at all? | Create minimal viable process |
| Unclear Process | Is ownership clear? | Specify, define done | |
| Not Followed | Why was it bypassed? | Diagnose cause, then automate | |
| Too Complex | Is compliance the bottleneck? | Audit and remove steps | |
| System | Design Flaw | Does the structure produce failure? | Redesign architecture |
| Feedback Loop Failure | Does decay go undetected? | Install leading indicators | |
| Misaligned Incentives | What behaviour is rewarded? | Redesign reward structure | |
| Capacity Mismatch | Is demand exceeding capacity? | Add capacity or cut demand | |
| Resource | Time / Money / Tools / Info / People / Energy | Would doubling the resource change the outcome? | Supply the missing input |
| Relationship | Trust Deficit | Is full engagement being withheld? | Reliability, transparency |
| Expectation Mismatch | Do the mental models match? | Explicit agreements | |
| Communication Failure | Was the signal transmitted accurately? | Channel + loop closure | |
| Value Conflict | Are the values incompatible? | Name it, negotiate precedence | |
| Environment | Random / Constraint / Black Swan / Ambient | Is this inside or outside our control? | Build resilience, not tighter control |
Used consistently, this taxonomy does something more valuable than any individual diagnosis: it builds a shared vocabulary across all the domains of your life. The same word — feedback loop failure — can describe a missing monitoring alert, a marriage with no regular check-ins, and a spiritual life with no muhasebe practice. When the vocabulary unifies, so does the pattern-recognition.
The purpose was never to explain the world perfectly. It was to get from incident to intervention, with just enough abstraction to gain leverage — but not so much that action is delayed.
No subtypes found
Try a different search term, or clear the filters to see everything.