2026-05-27
May 27, 2026
Issue 020 — The biggest hidden risk in your portfolio isn't that any one program is off. It's that you're treating two fundamentally different kinds of problems with the same toolkit. The fix isn't more planning. It's a five-minute sort that most senior leaders never make.
Walk down the list of programs you're accountable for this quarter. For each one, ask a simple question: if we had perfect information at kickoff, could we have written a plan that would have worked? For a chunk of your portfolio, the answer is yes — these are problems where experts know the answer, the steps are knowable in advance, and the work is execution under constraint. For another chunk, the answer is no — and would always be no, no matter how many architects you put in the room. These are problems where the system pushes back, where stakeholders' positions move when you touch them, where the right answer only becomes visible after you've intervened.
Those two chunks need totally different management. You almost certainly run them the same way — same Gantt chart, same RAID log, same status template, same weekly forum, same definition of "on track." That's the misdiagnosis tax. PMI's own research keeps surfacing it: more than 70% of large transformation programs miss their original timelines, exceed budget, or fail to deliver expected value. The dominant industry response is to add more controls. But controls work on complicated problems. The work that's failing is complex — and complex problems eat controls for breakfast.
The senior TPM lever here is sense-making, not planning. Before you sequence the work, sort the work. Today's deep dive is on the most durable sense-making frame for that sort: Dave Snowden's Cynefin, which is now in its 27th year and has quietly become the most-cited decision framework in tech leadership writing from Will Larson, Charity Majors, Camille Fournier, and the LeadDev circle. The frame is older than most of your engineers. It is also still the sharpest tool available for the messiest part of your job.
Cynefin (pronounced ku-NEV-in, Welsh for "place of multiple belongings") was created by Dave Snowden in 1999 while he was at IBM Global Services, then formalized in the 2007 Harvard Business Review essay "A Leader's Framework for Decision Making" co-authored with Mary Boone. The framework sorts problems into five domains: Clear (best practice exists, sense-categorize-respond), Complicated (good practice exists, sense-analyze-respond — this is the engineer's natural habitat), Complex (no a-priori best practice, probe-sense-respond — patterns only emerge from intervention), Chaotic (no time to analyze, act-sense-respond — stabilize first), and Confused/Aporetic (you don't yet know which domain you're in — and this is the most dangerous place to be).
The single most important pattern for senior TPMs and tech leaders: most large programs are mixtures, with components scattered across at least three of these domains, but the program is managed as if it were all Complicated. The migration is Complicated. The rollout to thirty business units is Complex. The customer-impacting incident in week six is Chaotic. The same status forum cannot hold all three. The same RAID log cannot surface them. The same definition of "green" cannot fairly describe them.
Three judgment shifts follow from taking Cynefin seriously at program scope.
First, stop demanding a plan from work that lives in the Complex domain. When the cause-effect relationships only become visible after you intervene — typical of platform adoption, org redesigns, new-market launches, anything where humans' behavior is part of the system — a Gantt chart is not just unhelpful, it is actively misleading. It anchors stakeholders on a date that the system cannot honor and that no amount of project management discipline can rescue. The right move is to design safe-to-fail probes — small, parallel, reversible interventions that surface real signal. You then sense (what actually happened?) and respond (amplify what worked, dampen what didn't). This is the heart of probe-sense-respond, and it is what most senior leaders are doing implicitly when their best programs work and explicitly when their worst ones get rescued at the eleventh hour.
Second, watch the liminal zones. Snowden added "liminal Cynefin" to the framework in 2020 — the transition states between domains. The most important one for senior TPMs is the liminal zone between Complicated and Complex: the place where pilots, prototypes, and structured experiments live. Most "discovery" work in tech organizations is really liminal work — you're trying to move a problem from Complex (where you have no idea what to build) to Complicated (where you do, and now it's just execution). Naming this explicitly changes how you fund it, staff it, and judge it. Liminal work is judged on learning rate, not on burndown. If you can't tell me what hypothesis the next two weeks of work is testing, you're running a Gantt chart on a Complex problem and you're going to spend a lot of money to discover that.
Third, treat Confused/Aporetic — the center of the framework — as a managed state, not an embarrassment. This is the domain where you don't yet know which domain a problem belongs in. Snowden's term for this work is the aporetic turn: deliberately holding the ambiguity long enough to sort the parts of the problem into ordered (Clear/Complicated) versus unordered (Complex/Chaotic). Senior leaders who skip this step — usually because they're under pressure to "make a call" — end up writing project plans for problems that don't have project-plan-shaped solutions. The senior TPM move is the opposite: hold the confusion visibly for one or two weeks while you decompose the problem, and only then commit to a management approach. A two-week aporetic turn at the start of a six-quarter program is the highest-leverage time you will spend.
The hardest sell to your stakeholders is that this is not slower. Misdiagnosing a Complex problem as Complicated and planning your way through it is the actual slow path, because you will rebuild the plan three times. Cynefin shortens that loop by making the sort the first deliverable.
Try this week. Take your top three programs. For each one, decompose it into 5–10 component workstreams and put each into one of Cynefin's five domains. Look at the mix. If everything is sitting in Complicated, you have not done the sort — you've just labeled. Then look at which workstreams are currently being managed with tools that don't match their domain (Gantts on Complex work, probes on Complicated work, status meetings on Chaotic work). Pick one mismatch and re-tool next week, not next quarter. Bring the resorted picture to your staff meeting and name it as such.
What it is. A sense-making framework that sorts a problem (or a workstream within a program) into one of five domains based on the nature of the cause-effect relationship: Clear, Complicated, Complex, Chaotic, or Confused/Aporetic. Each domain has a different recommended action sequence. The point of the framework is not the labels — it's that the action sequences are not interchangeable.
When to use it. At program kickoff, before you commit to a delivery cadence or governance model. At any quarterly re-plan, especially if the previous quarter felt like it slipped for "unclear" reasons. At any post-incident review where the team is reaching for "more process" as the answer. Any time a stakeholder is asking for a date on something that demonstrably resists dates.
How to run it:
When NOT to use it. Don't use Cynefin to relabel work that's already in motion if doing so will paralyze the team — the sort is most valuable before you commit. Don't use it as a way to dodge accountability for Complex work ("it's Complex, so we can't commit to anything") — Complex work commits to a learning velocity, not a date, and that commitment is real. Don't run it as a workshop where you fill in five quadrants and walk away with a poster; the deliverable is a change in how you govern the work, not a diagram.
Example. A platform migration's "rip out the old auth library" workstream is Complicated — there's a knowable sequence. The same program's "get 40 product teams to adopt the new client" workstream is almost always Complex — adoption is emergent and depends on incentives, skin in the game, and political dynamics that don't behave like code. Running both on the same migration-team Gantt is the most common reason platform migrations slip.
Jellyfish State of Engineering Management 2026 — 64% of teams report 25%+ velocity gains from AI — Survey of 636 engineering leaders, published May 2026. Notable: Claude Code now leads adoption over Copilot, and code review (49%) has caught up with code writing (53%) as a primary use case. But only 10% of teams report strong enablement and high adoption — the gap is leadership, not tooling.
DORA 2025 State of AI-Assisted Software Development — AI is an amplifier, not a fix — 90% of developers now use AI assistance, but the report's central finding is uncomfortable: AI adoption has a negative relationship with software delivery stability unless seven specific surrounding capabilities are in place. If your foundations are weak, AI accelerates the breakage. The seven team archetypes that replace the old elite/high/medium/low framing are worth reading in full.
ICONIQ 2026 State of AI — production discipline is the new moat — High-growth companies now ship 36% of code with AI assistance (up from 29% six months ago). But the report's sharper point is that 60% of firms in production with agentic AI have no formal governance. The 2026 Gartner hype cycle now lists governance, cost-tracking, and security as standalone agentic-AI profiles — what was a pilot consideration is now a board-level line item.
"Leaders who try to impose order in a complex context will fail, but those who set the stage, step back a bit, allow patterns to emerge, and determine which ones are desirable will succeed."
— Dave Snowden & Mary Boone, Harvard Business Review, November 2007
Don't miss what's next. Subscribe to Critical Path: