MURK Framework
A naming tool for transformation resistance. Transformation rarely fails for one big reason — it stalls in a fog of small, unnamed frictions. MURK gives those frictions names so a team can point at them and act.
The Four Signals
Each MURK signal has a distinct character, a distinct cause, and a distinct resolution path. Naming which one you're dealing with is the first step toward addressing it.
Misalignment
Stated strategy and actual execution point in different directions. Teams optimise for goals no one set on purpose. Metrics measure the wrong thing. Work gets done that no one asked for; work that matters gets skipped.
Underuse
Capability already exists but sits idle — a tool, a person, a team, a process nobody routes work through. Often the result of poor onboarding, unclear ownership, or a system designed without accounting for how people actually work.
Redundancy
The same effort happens in two places, or oversight stacks on oversight without adding real safety. Redundancy wastes time and creates confusion about which version is authoritative — while giving a false sense of security.
Knots
Tangles where change gets stuck — a dependency, an approval, a single overloaded person everything routes through. Knots are often invisible until something urgent needs to move fast, at which point they become the only thing anyone can see.
Examples in Practice
The unintended metric
A team measures response time, so they close tickets fast — even when the problem isn't solved. The metric optimises for speed; the goal was resolution. Nobody set out to do this.
The invisible expert
A subject matter expert sits three seats away from the team that keeps making the same mistake. Nobody asks them. Their expertise was never surfaced to the people who needed it.
The triple sign-off
A document requires three approvals. All three approvers review the same thing, make the same call, and sign off within minutes of each other. One review would reach the same outcome with a third of the delay.
The single dependency
Every decision above a certain value requires sign-off from one person. That person has fifty decisions in their queue. Nothing moves until it does — and nothing on their end signals urgency until everything becomes urgent at once.
The inherited priority
A project was flagged as high priority in Q1. It's now Q3, the business context has changed, but the priority flag hasn't. Teams are still working on it at the expense of things that now matter more.
The upstream blocker
Work cannot start until a dependency is resolved by another team. That team is waiting on a third team. Nobody has mapped the dependency chain, so everyone waits for someone else to move first.
Running a MURK Session
MURK works best as a facilitated team exercise — typically 60–90 minutes — before a DIVE sprint or at the start of a transformation initiative. The goal is to surface known friction before work begins, so the team can address it deliberately rather than working around it.
MURK Diagnostic Session — Facilitation Guide
Set the scope: Define the workflow or system you are diagnosing. Be specific — "the intake process" or "how we approve vendor contracts," not "everything."
Surface friction: Ask each person: "Where does this feel slow, stuck, duplicated, or pointless?" Capture without filtering. Five minutes of silent writing works better than open discussion.
Sort into MURK categories: Place each friction into M, U, R, or K. Some will fit more than one — that's useful information. A friction that is both Misalignment and a Knot is especially worth examining.
Prioritise: Which MURK signal is causing the most drag? Rank by impact, not by how easy it is to fix. Easy fixes that don't address real friction are activity, not progress.
Name the next action: For each top-priority MURK signal, identify: who owns addressing it, what the first concrete step is, and what "resolved" looks like.
What MURK Is Not
MURK is a diagnostic tool for
- Naming structural friction before a transformation sprint
- Making hidden blockers visible and discussable
- Prioritising which friction to address first
- Creating shared vocabulary across a team
- Surfacing systemic patterns, not individual incidents
MURK is not designed to
- Assign blame or evaluate individual performance
- Replace root cause analysis for critical failures
- Design the solution (that is DIVE's job)
- Audit whether a system is healthy over time (that is REEF's job)
- Produce exhaustive documentation
MURK in the Framework Family
MURK is the first tool to reach for — name the friction before you design the solution. Then DIVE moves things forward, and REEF keeps the result healthy.
The Three Frameworks
Use MURK to name what is slowing things down, DIVE to design and ship the forward move, and REEF to keep the result healthy after it scales. DIVE is the engine; REEF is the maintenance; MURK is the diagnostic lens.
See DIVE Framework