2026-06-10
June 10, 2026 · Issue 030
Most senior TPMs treat every program like a complicated machine. Half the time, it isn't — and that's why the plan keeps breaking.
A program kickoff usually opens with the same artefacts: a charter, a milestone strawman, a RACI, a risk register, a stage-gate plan. The implicit assumption is that the work is complicated in the technical sense — knowable, decomposable, plannable by experts. For roughly half the programs senior TPMs run in 2026, that assumption is wrong.
If the program is really complex — agentic platform rollouts, post-merger integration, AI cost governance across a sprawling org — you don't have cause-and-effect to plan against. You have emergent behaviour, and your plan is a probe at best. Treating it as complicated means you ship a Gantt chart that's confidently wrong by week four.
Dave Snowden's Cynefin framework is the one diagnostic that tells you which kind of program you're in before you choose your operating model. Senior PMs at Spotify, Booking.com and parts of GDS have used it for a decade as a kickoff lens. Most enterprise TPM orgs still don't. That gap is your edge.
Cynefin (Snowden, 1999; published in HBR in 2007 with Mary Boone) is not a 2x2. It's a sense-making framework with five domains and — crucially — a centre called disorder, where you don't yet know which domain you're in. The point isn't to land somewhere on the map. The point is to stop confusing one domain for another.
The five domains, translated to the program context:
Clear (formerly Simple or Obvious). Cause and effect are known. Best practice exists. The right move is sense → categorise → respond. Example: standing up the 47th instance of a known internal service template. Risk: the complacency trap — assuming the next thing is also Clear when it's drifted into Complicated.
Complicated. Cause and effect can be analysed by experts. Good practice exists. Sense → analyse → respond. Example: a database migration with known patterns and a vendor playbook. This is where most program management training lives — and where most senior TPMs are very comfortable. The trap: treating Complex programs as Complicated, planning them up front, and watching the plan rot.
Complex. Cause and effect are only knowable in retrospect. No best or good practice — only emergent practice. Probe → sense → respond. Example: rolling out an AI assistant across a 4,000-person engineering org, where every team's adoption changes the org's centre of gravity. Here, milestone-driven plans are a category error. You run safe-to-fail experiments, watch what emerges, and amplify what works.
Chaotic. No discernible cause-and-effect. Act → sense → respond. Example: a Sev-0 incident, a sudden regulator notice. Your job is to impose stability, not to plan. Don't try to consult — act.
Disorder (the centre). You don't know which domain you're in. This is the actual starting state of most program kickoffs and almost no one names it.
Three uses for senior TPMs and tech leaders:
1. Diagnose the program in the first hour. Before scope, before milestones, hold a 60-minute Cynefin diagnostic with the eng lead, design lead and one senior IC. Ask: which workstreams are Complicated (planable) and which are Complex (probable)? You'll find programs are almost always a mix — and the mix dictates the operating model. The Complicated streams get a milestone plan. The Complex streams get a probe cadence and a "safe-to-fail" budget.
2. Pre-empt the most common senior-TPM failure. The failure is mistaking Complex for Complicated. The symptom: rolling slips with no single root cause, a RAID register full of yellows, and stakeholders losing trust because milestones keep moving. The fix isn't a better plan — it's renaming the work as Complex, replacing milestones with probes and learning gates, and updating stakeholders on what you've learned rather than what you've delivered against an obsolete plan.
3. Catch the slide into Chaos before it's an incident. Snowden's most important contribution is the cliff edge between Clear and Chaotic. When you treat something as Clear (best practice, no thinking required) and it's secretly drifted, a small failure becomes a free-fall — because no one was watching. Migrations, rollouts, "boring" rotations live here. Audit your Clear list quarterly.
A tactical note. The Cynefin diagnostic also reframes how you write status updates. For Complicated work: percent-complete, dates, risks. For Complex work: probes run, what you learned, what's next to try, current hypothesis. If you write both in the same format, your leadership reads them both as plan-vs-actuals and you lose the air cover Complex work needs.
The hardest move is admitting upfront that part of your program is genuinely Complex. Most director+ stakeholders are still uncomfortable with "I don't know yet — here's how I'll find out." Earn the right to that posture by being exquisitely clear about which streams are Complicated and well-planned. Cynefin doesn't excuse you from running the boring 70% well. It earns you space to run the interesting 30% honestly.
Try this week. In your next program kickoff, replace the "scope and milestones" slide with a single Cynefin sort: list every workstream and put each in Clear, Complicated or Complex. Force the room to argue every placement. The argument is the value — not the diagram.
What it is. A four-phase discovery-and-delivery model: Discover → Define → Develop → Deliver, organised as two diamonds — one for the problem (diverge then converge on what to solve), one for the solution (diverge then converge on how). Originated at the UK Design Council in 2005 and refined in 2019 as the "Framework for Innovation."
When to use it. Any program where the problem statement is fuzzy, contested between functions, or inherited from a slide rather than from customers. Especially useful when leadership hands you "build X" and your gut says "X isn't the real problem."
How to run it:
When NOT to use it. When the problem is genuinely Clear or Complicated (per Cynefin) and the right move is just to execute a known pattern. Don't apply Double Diamond to your 47th identical onboarding rollout — it's overhead.
Example. A staff PM at a fintech ran Double Diamond on a "build a new merchant dashboard" ask from sales. Discover phase showed merchants didn't want a dashboard; they wanted a Slack alert when a chargeback was filed. The dashboard project was killed and replaced with a two-engineer integration. That outcome is the case for putting a problem diamond in front of every program with an inherited solution.
ICONIQ State of AI in Software Engineering 2026 — Adoption is past the early-majority line; the new bottleneck is org design around agents, not model quality. Senior TPMs should read it as a program-design document, not a vendor report.
Pragmatic Engineer — Inside the AI-Native PR Review Stack — Field reports on how engineering orgs are restructuring code review with AI reviewers in the loop. Pair it with your Cynefin diagnostic: most of these rollouts are Complex, not Complicated.
LeadDev — The case against the "AI strategy" deck — Argues that a separate AI strategy doc is a sign your real strategy is too vague to absorb AI. Useful framing for tech leaders being asked for one.
"Best practice is, by definition, past practice."
— Dave Snowden
Don't miss what's next. Subscribe to Critical Path: