When to Move and When to Wait

Read this alongside the First Principles AI book, the AI-Native thesis, and the full book library when you want the surrounding argument. Every leader I have worked with eventually asks the same question, usually privately, usually with some embarrassment, as if it were a question they should already know the answer to: "Are we moving too slowly, or too fast?" It is the right question and it has no general answer, because timing is not a property of the technology. It is a property of the relationship between the technology's readiness and your specific cost of waiting. This chapter is about turning that anxious feeling into a calculation you can actually run.

The wrong way to answer it is the way the feed answers it: by momentum. Everyone else is moving, so we should move; or everyone got burned, so we should wait. Momentum is a measure of what other people are doing, not of what is right for you, and other people are mostly reacting to the same momentum, so following it is following a crowd that is following itself. The right way to answer it is to weigh two asymmetric costs that are specific to your situation: the cost of moving too early against the cost of moving too late. Whichever is larger tells you which error to bias against.

The diffusion curve, and why "everyone is doing it" is the wrong signal

Everett Rogers spent his career studying how innovations spread through a population, and his Diffusion of Innovations gives us the canonical map: innovators, then early adopters, then the early majority, then the late majority, then laggards, each category adopting for different reasons and at different points on an S-curve (Everett Rogers, Diffusion of Innovations, summarized). Geoffrey Moore later added the crucial wrinkle for technology specifically: a chasm between the early adopters, who tolerate rough, unproven things for the upside, and the early majority, who require evidence and want the rough edges gone (Geoffrey Moore, Crossing the Chasm, summarized).

The practical use of this map is not to figure out which category you "should" be in, which is the way it usually gets misused. It is to recognize that the right adoption point depends on what kind of organization you are and what you are adopting for. An innovator or early adopter is buying option value and competitive differentiation, and is willing to pay for it in unreliability and wasted effort. An early-majority adopter is buying a proven thing and is right to wait until the evidence exists and the rough edges are gone. Neither is correct in general. The error is being an early-majority organization that lets hype push it into early-adopter behavior, paying early-adopter costs without having an early-adopter's appetite or upside, or being an early-adopter organization that lets cynicism keep it in late-majority caution and forfeits its actual advantage.

So the first move on any timing question is to ask honestly: for this specific capability, are we adopting for differentiation, where being early can win, or for efficiency, where being right matters more than being first? The answer is different for different capabilities in the same company, which is why "are we moving fast enough" has no single answer. You are moving fast enough on the things where early wins and waiting correctly on the things where it does not.

The asymmetry of timing errors

Strip the anxiety away and a timing decision is a bet under uncertainty with two ways to be wrong, and the two ways usually do not cost the same. That asymmetry, not the momentum, is what should decide you.

The cost of being too early. You adopt before the technology is ready and pay in unreliability, wasted integration on something that changed, vendor churn, and the team's effort spent on a thing that was not yet worth it. You also pay an opportunity cost: the attention spent here was not spent elsewhere. For a reversible, low-rung experiment, this cost is small. For an irreversible, high-rung commitment, being early can be fatal.

The cost of being too late. You wait too long and a competitor builds a durable advantage you cannot cheaply catch, or the capability becomes table stakes and you are visibly behind, or you forfeit a window where being early was genuinely worth it. For commodity efficiency gains, being late costs little, you adopt the matured version cheaply. For genuine differentiation in a winner-take-most dynamic, being late can also be fatal.

The decision falls out of comparing these two for your specific case. When the cost of being too early is small and reversible and the cost of being too late is large and irreversible, bias toward moving: the asymmetry favors action, and you should accept the risk of wasted early effort to avoid the risk of being permanently behind. When the cost of being too early is large and irreversible and the cost of being too late is small and recoverable, bias toward waiting: the asymmetry favors patience, and you should let others pay the early-adopter tax and adopt the matured, cheaper, more reliable version. The momentum of the crowd is irrelevant to both calculations.

	Cost of being late is small	Cost of being late is large
Cost of being early is small	Experiment freely, low stakes either way	Move now, the asymmetry strongly favors action
Cost of being early is large	Wait, let the technology and others mature it	The hard case, buy reversibility to shrink the early cost, then move

The hard case is the bottom-right, where both errors are expensive, and that is precisely where the reversibility ladder earns its keep: you engineer the early cost down, through abstraction, data ownership, shorter terms, and reversible rungs, until the bottom-right turns into the top-right and the asymmetry favors action again. Most of the value of being able to engineer reversibility is that it lets you act in situations that would otherwise force you to wait.

Triggers, not vibes

The Trend Triage Board told you to put a written trigger on every "watch" item. This chapter is where that pays off, because the trigger is how you convert a timing decision from a recurring anxiety into a one-time setup. Instead of asking "is it time yet" every week, which is exhausting and noisy and prone to being answered by whoever is loudest, you decide once, in calm conditions, what observable event would mean it is time, and then you wait for that event without re-litigating it.

A good trigger is specific, observable, and tied to evidence rather than sentiment. "When end-to-end agent reliability on a public benchmark close to our workflow crosses 90 percent" is a good trigger. "When a direct competitor ships this in production and it sticks for a quarter" is a good trigger. "When the cost per useful outcome on our replay drops below our threshold" is a good trigger. "When it feels like the right time" is not a trigger, it is the absence of one, and it is how the feed gets back in. The discipline is that between setting the trigger and the trigger firing, the trend has no claim on your attention beyond the scheduled review, no matter how loud it gets. You already decided. You are waiting for the event, not the noise.

Belief updating without thrashing

Underneath the timing question is an epistemics question: how do you change your mind as evidence arrives without changing it every time the wind blows? Too rigid and you ignore real signal; too loose and you thrash, which is just churn wearing the costume of open-mindedness. The healthy middle is to update your beliefs in proportion to the strength of the new evidence, which sounds obvious and is violated constantly, because the hype cycle delivers evidence whose vividness is wildly out of proportion to its strength.

A viral demo is vivid and weak. It updates your beliefs strongly on the emotional register and should update them only slightly on the evidential one, because, as we have established, a demo proves a capability can happen once under ideal conditions and almost nothing about deployment. A replay result on your own data is undramatic and strong, a number in a spreadsheet, and it should update your beliefs substantially, because it is evidence about exactly the thing you care about. The error the hype cycle induces is to invert these: to update hard on the vivid weak evidence and barely at all on the dull strong evidence. Correcting that inversion is most of the skill.

A simple practice enforces it. When new information arrives, before reacting, ask two questions: how strong is this evidence, really, on the scale from a clip to a controlled measurement on my data, and how surprising is it given what I already believed. Strong and surprising evidence earns a real update and possibly a trigger firing. Weak evidence, however vivid, earns a note on the board and nothing more. Strong but unsurprising evidence, confirmation of what your own tests already showed, earns increased confidence but no new action. This sounds clinical, and in the moment it is exactly the clinical detachment you want, because the alternative is updating on adrenaline, which is how an org ends up thrashing. Belief updating done right looks boring from the outside, a slow accumulation of confidence as evidence compounds, punctuated by the occasional decisive move when a trigger genuinely fires. Boring is the goal. Thrashing is exciting and expensive.

A worked timing decision, labeled hypothetical

Let me run one through the machinery, composite and labeled hypothetical. The capability: a class of model has gotten good enough that a competitor has started using it for a customer-facing feature you also could build. The anxious question: are we behind?

First, what are we adopting for? For this feature, differentiation, the early window might actually matter, customers notice who has it first. So the cost of being late is meaningfully large here, not small. Second, the asymmetry. Cost of being too early: we build on a capability that is improving fast, so some rework is likely, call it a quarter of one team, reversible if we use an abstraction layer. Cost of being too late: the competitor establishes the feature as theirs in customers' minds, a brand association that is expensive to dislodge, and that is closer to irreversible. So we are in the top-right of the matrix, both costs real but the late cost more permanent: the asymmetry favors moving. Third, we engineer the early cost down, abstraction layer over the model so we can swap it, data and prompts kept ours, a reversible opt-in rung rather than a core-workflow commitment, so the rework risk shrinks. Fourth, we move, but on the reversible rung, not the irreversible one, which is the synthesis of "move fast" and "do not bet the company." We are early and reversible at the same time, which the matrix says is exactly right when late is the more permanent error.

Notice what did not enter the decision: how many other companies were doing it, how it felt, how loud the discourse was. What entered was what we were adopting for, the two asymmetric costs, and whether we could engineer the early cost down. That is timing as a calculation, and it gives a different and better answer than timing as a vibe.

Summary

Timing is not a feeling about momentum, it is a comparison of two asymmetric costs specific to you: the cost of being too early against the cost of being too late. The diffusion curve reminds you that the right adoption point depends on whether you are adopting for differentiation or efficiency, and that the error is letting hype or cynicism push you off your natural position. Bias toward action when early is cheap and reversible and late is expensive and permanent; bias toward patience when the reverse holds; and in the hard case where both are expensive, engineer the early cost down with the reversibility ladder until the asymmetry favors action. Convert recurring timing anxiety into one-time written triggers tied to evidence, and update your beliefs in proportion to evidence strength, not evidence vividness, so that you move decisively when a trigger fires and stay boringly still when it does not.

Key Takeaways

• Timing is a property of the relationship between the technology's readiness and your specific cost of waiting, not a property of the technology or of crowd momentum.
• The diffusion curve's use is to ask whether you are adopting for differentiation, where early can win, or efficiency, where right beats first. The answer differs per capability within the same company.
• A timing decision is a bet with two asymmetric ways to be wrong. Compare the cost of being too early against the cost of being too late, and bias against the larger one.
• When early is cheap and reversible and late is expensive and permanent, move. When the reverse holds, wait. The crowd's momentum is irrelevant to both.
• In the hard case where both errors are expensive, use the reversibility ladder to engineer the early cost down until the asymmetry favors action. That is most of the value of engineered reversibility.
• Convert recurring timing anxiety into one-time written triggers, specific, observable, and evidence-based. Between setting a trigger and its firing, the trend has no claim on your attention beyond the scheduled review.
• Update beliefs in proportion to evidence strength, not vividness. A viral demo is vivid and weak; a replay result is dull and strong. The hype cycle inverts these, and correcting the inversion is most of the skill.