[silence]
2026-02-24 · standard-panel · Facilitated by Ren Ito
When should an organization adopt a new technology vs. wait?
The question on the table: when should an organization adopt a new technology versus wait? This isn’t hypothetical — every organization faces this regularly. Let’s diverge. I want to hear genuinely different takes on what makes this question hard.
It’s only hard if you don’t know where the technology sits on its evolution curve. A technology in genesis — novel, poorly understood, changing fast — demands a fundamentally different adoption posture than one that’s becoming commodity. Most organizations treat adoption as a binary: adopt or wait. But the real question is where the technology is evolving to and how fast. If it’s heading toward commodity, waiting is cheap — the product will be better and cheaper in a year. If it’s heading toward a strategic differentiator in your specific landscape, waiting means your competitors get there first. The map tells you. Without it, you’re guessing.
The map tells you what you think you know. It doesn’t tell you what you’re wrong about. The question I’d ask first isn’t “where is this technology?” — it’s “what’s the downside of being wrong?” Because there are two kinds of adoption bets. Convex bets: limited downside, large potential upside. You adopt a new collaboration tool, it doesn’t work, you go back to email. You’ve lost some time. Concave bets: limited upside, catastrophic downside. You migrate your data infrastructure, it fails, you lose a quarter. Most organizations don’t distinguish between these. They apply the same decision process to both. The question isn’t when to adopt — it’s what shape is the risk.
Both of you are looking at the organization’s strategic position. I’m looking at the person who has to use the thing on Tuesday. The adoption question is a design question. Not “is this technology ready?” but “is the experience of switching tolerable?” Every technology adoption asks people to unlearn something. The cost of unlearning is invisible in strategic frameworks — it shows up as frustration, workarounds, shadow IT, quiet non-adoption. The question isn’t when the technology is ready. It’s when the gap between the old experience and the new experience is small enough that people will actually cross it. Or when the old experience is painful enough that they’ll tolerate a big gap.
That’s the forces model. Four forces acting on every adoption decision. Push: frustration with the current situation — “this isn’t working anymore.” Pull: the promise of the new thing — “look what it could do.” Anxiety: fear of the switch — “what if it’s worse?” And habit: comfort with the current — “I know how this works.” Most technology adoption analyses focus on push and pull. Is the technology good enough? Is the pain big enough? But adoption fails on anxiety and habit, not on capability. The technology can be objectively better and people still won’t switch because the switching cost — the emotional cost, not the financial cost — is too high. So “when to adopt” is really “when have you addressed the anxiety and habit forces, not just the push and pull ones?”
I want to question the question itself. “When should an organization adopt” assumes adoption is a single decision made at a point in time. But is it? Or is it a process — a series of probes, experiments, partial commitments, and retreats? In Cynefin terms, technology adoption in a complicated domain looks like: analyze the landscape, evaluate options, choose the best one, implement. That works for commodity technology where the behavior is predictable. But adoption of genuinely novel technology is a complex domain problem. You can’t analyze your way to the right answer because the landscape changes as you move through it. The question isn’t “when do we adopt” — it’s “how do we probe?” Small, safe-to-fail experiments that reveal what this technology actually does in your specific context. Not analysis, not strategy — sensing.
Five different framings. Nora says map the evolution curve. Abel says characterize the risk shape. Kai says look at the user experience gap. Ines says address the four forces. Lev says probe, don’t decide. I notice they’re operating at different scales. Nora and Abel are strategic. Kai and Ines are human. Lev is epistemological. Do they conflict, or do they layer?
They layer, but not cleanly. Nora’s map assumes you can see the evolution curve. Lev’s point is that in genuinely novel technology, you can’t — the map is blank. Those two frameworks give opposite advice in exactly the situation where the stakes are highest. For commodity technology, everyone agrees: adopt when it’s cheap and stable. That’s trivial. The hard case is genesis technology where the map is uncertain, the risk shape is unclear, and the user experience is rough. That’s where the decision frameworks diverge.
Fair. But I’d push back on “the map is blank.” The map is never completely blank. Even for novel technology, you can position the components. The AI model is genesis, sure — but the API layer is already moving toward product. The infrastructure underneath is commodity. You don’t adopt “AI” as a monolithic thing. You adopt a stack where different layers are at different stages. Map the layers, adopt the commodity ones confidently, experiment with the genesis ones cautiously. The mistake is treating the whole stack as if it’s at one maturity level.
That’s a smart decomposition, but it still misses the human layer. You can decompose the technology stack perfectly and still fail at adoption because you treated the users as if they were also decomposable. They’re not. A person doesn’t experience “the API layer is product-grade.” They experience “I clicked this button and nothing happened the way I expected.” The adoption stack has a human layer at the top, and that layer doesn’t map cleanly to technology maturity.
And the human layer has its own timing. Push and pull build over time. Anxiety spikes at the moment of commitment and fades afterward — if it goes well. Habit is the slowest force — it takes months to break, not days. So the organizational readiness has a different clock than the technology readiness. You can be technically ready and humanly premature. Or technically premature and humanly desperate — which is when people adopt bad technology, because the pain of the current situation overwhelms their judgment about the new one.
This is where the single-decision framing really breaks down. If adoption has a technology clock and a human clock running at different speeds, then “when to adopt” is the wrong abstraction. The question is how to synchronize the clocks. And you can’t do that analytically — you have to run probes that expose both clocks simultaneously. A pilot isn’t just a technical test. It’s a human test. Did the anxiety reduce? Did new habits start forming? Did the push increase because they saw what’s possible? The probe reveals the state of both clocks at once.
I want to stress-test the probe model. Probes sound safe. “Safe-to-fail experiments.” But there’s a failure mode: probe paralysis. You run small experiments forever and never commit. The organization that’s always “piloting” and never adopting. At some point, commitment is required — you burn the boats and switch. Probes defer that moment, which can be wise or can be cowardice. The question is: what triggers the transition from probing to committing? And who bears the cost of that commitment?
That’s the groan zone. Two things are true simultaneously: probing is necessary because the landscape is complex, and commitment is necessary because probing forever is paralysis. Sit with that.
[silence]
The trigger might be the map filling in. You probe in genesis. As the probes reveal the landscape, components evolve — from genesis to custom to product. At some point, enough of the stack has moved out of genesis that the risk profile changes. You’re no longer betting on the unknown. You’re adopting something you’ve watched evolve through your own experiments. The probes aren’t just information-gathering — they’re maturation accelerators.
Or the trigger is the human one. The probes shift the forces. People who participated in the pilot have reduced anxiety — they’ve seen it work. They’ve started forming new habits. They’ve become advocates. The adoption spreads from the probe group outward. It’s not a decision point — it’s a tipping point. The commitment happens when enough people have already committed through exposure, not through a memo.
Both of those assume the probes go well. What if they don’t? What if the pilot fails? A good adoption framework needs a kill criterion, not just a go criterion. “We stop when X happens.” Most organizations define success but not failure. They’ll say “we adopt when adoption metrics hit this threshold” but they won’t say “we abandon this entirely when X.” Without a kill criterion, failed probes don’t end — they zombie on.
The kill criterion is an experience question too. “It’s not working” is not a technical judgment for most people — it’s a feeling. The interface keeps frustrating them. The new workflow is slower than the old one. They can’t find the thing they need. Kill criteria should be experiential, not just metrics-based. “If after four weeks, users are still reverting to the old tool for their core tasks, this isn’t an adoption problem — it’s a design problem, and we either fix the design or kill the initiative.”
So we’re converging on something. Adoption isn’t a when-decision — it’s a process with three phases. Probe: small experiments that reveal the technology and human landscape simultaneously. Commit: triggered not by a decision meeting but by the probes shifting the landscape enough — technology matures, human forces shift. Kill: defined in advance, experiential not just metric-based, enforced honestly.
Let me check that. Does this hold for everyone, or are we converging too fast?
It holds, but I’d add a prerequisite. Before probing, map what you can. The probe should target the unknowns, not re-discover what’s already known. If the commodity layers are obvious, don’t probe those — just adopt them. Probe the genesis layers. Focus the experiment where the uncertainty actually lives.
And I’d add the risk shape filter before everything. Is this a convex or concave bet? If concave — catastrophic downside — the probe phase needs to be longer and the kill criteria need to be tighter. If convex — limited downside — you can probe faster and commit earlier. The risk shape sets the tempo of the whole process.
One more thing. This whole framework assumes a rational organization that can execute a process. Most organizations aren’t. They adopt technology because a VP saw a demo. They abandon technology because the champion left. The forces acting on adoption include politics, ego, and inertia — not just technology maturity and user experience. Any honest framework has to acknowledge that the decision process it describes will be overridden by human irrationality roughly half the time.
That’s the uncomfortable closing note, and it’s honest. Let me summarize what we built:
And the framework itself is five concepts. Max would count them and say it’s too many.
He would. And he’d be right that it needs compression. But that’s another session.
Better range than session 001. Same cast, non-meta topic — characters had to stretch beyond self-referential comfort zone. The strategy question gave Nora home turf advantage (evolution mapping) while forcing the others to translate their frameworks. Productive friction between Nora's "map it" and Lev's "you can't map genesis" — genuine disagreement, not performance. Abel's risk shape filter was a new move, not a repeat of "fragile theater" — good flex.
Standard Panel with diamond worked cleanly for a strategy question. Groan zone emerged naturally (probe vs. commit tension). Convergence produced a usable framework (filter → map → probe → commit → kill) — more concrete than session 001. Non-meta format produced less self-referential commentary, as expected.
Solid facilitation. Named the scale difference (strategic/human/epistemological) — a structural observation, not a phase label. Different move from session 001. Used silence once. Still could hold longer.
Flexed well. 'The adoption stack has a human layer' — translated interface thinking to organizational strategy. Didn't default to 'where does the experience break?' literally, but the move is the same at a higher level. Consistency, not drift.
Strong flex. 'How do we probe?' is a different framing than 'how do we inquire?' but the same quality_test — reframe as process, not decision. Genuine disagreement with Nora on mapability. Did NOT self-observe his own patterns — improvement over session 001's meta-awareness.
Forces model (push/pull/anxiety/habit) applied to a new domain. Worked well. Closing note about organizational irrationality was new territory — the Kahneman seasoning showing more than in session 001. Good flex.
Home turf advantage — evolution mapping applied directly. Stack decomposition was a strong move. Risk of being too dominant when the question fits the lens perfectly. Monitor in sessions where mapping is less natural.
Convex/concave risk shape was a new instrument — not just 'what breaks?' but 'what shape is the breaking?' Also introduced kill criteria and probe paralysis — building, not just breaking. Better range than session 001.
Session 003 uses PAMAD Diamond on agent communication — different format, same cast. Will test whether phase-specific structure changes the character dynamics. Also: Nora had home turf here — pick a future session where her mapping lens is less obviously useful.