Technology planning often treats every decision as if it deserves the same process: gather a large group, request more analysis, compare long lists, and wait for full agreement. That feels careful, but it can slow everyday improvements while doing little to protect the few choices that could genuinely constrain the business for years.
A better question is not simply, “Which option is best?” Ask, “If this is wrong, how hard will it be to change?” When reversal is cheap, a measured experiment can be safer and more informative than a long debate. Lock-in, data exposure, or costly migration deserve more deliberate review.
This distinction gives business leaders a practical way to balance momentum with caution. It does not mean moving fast everywhere. It means matching the weight of the decision process to the cost of being wrong.
Start by asking how costly a wrong call would be
Amazon founder Jeff Bezos described consequential, nearly irreversible choices as “one-way doors” and more changeable choices as “two-way doors” in his 2015 letter to shareholders. The letter warns against applying a heavyweight process to every decision, including those that can be reversed. The original filing is available at https://www.sec.gov/Archives/edgar/data/1018724/000119312516530910/d168744dex991.htm.
That is a useful starting point for an IT portfolio, not a slogan. Reversibility is not the same as importance: a sign-in change may be easy to roll back but affect many employees, while a reporting-tool pilot can become hard to exit if teams build workflows around it. The test is whether the organization can detect a problem, contain effects, and restore the prior state at reasonable cost.
For each proposed decision, ask three questions:
- What becomes difficult to undo? Consider migration effort, contract terms, custom integrations, data portability, training, and dependencies that accumulate over time.
- How quickly would we know it is not working? A reversible change with weak monitoring may still cause damage before anyone notices.
- What is the blast radius? Estimate which users, processes, records, and customer commitments could be affected before a rollback takes effect.
These questions make risk concrete. They also reveal where a seemingly large initiative can be divided into smaller choices with separate owners and checkpoints.
Make reversibility a design requirement
Reversibility should be planned before a pilot begins, not improvised after users depend on the new service. Write down the current state, the change being tested, the group affected, the success measure, and the condition that would trigger a pause or rollback. Name a decision owner who can act when a guardrail is crossed.
For a software trial, use a limited group, keep the existing workflow available for a defined period, and test data export before importing many records. For infrastructure, back up configurations, validate recovery, and change one location or service at a time. For an AI feature, limit data access, require review for consequential outputs, and define what the pilot cannot do.
Not every decision can be made fully reversible. A long-term contract, a platform migration, or a change to a customer-facing process may have real switching costs. Even then, teams can often preserve options: negotiate a shorter initial term, keep interfaces portable, retain an exportable copy of critical data, or sequence migration in stages. These safeguards may add effort up front, but they keep the business from confusing “we can technically change it” with “we can change it affordably.”
Research on irreversible investment explains why waiting for information can be valuable when a commitment is hard to undo and uncertainty may resolve. Ben Bernanke’s NBER working paper, “Irreversibility, Uncertainty, and Cyclical Investment,” discusses this trade-off: https://www.nber.org/system/files/working_papers/w0502/w0502.pdf. A small pilot can provide useful information before a larger commitment.
Use small experiments to reduce uncertainty
An experiment is not a miniature deployment without a plan. It is a bounded decision designed to answer a specific question. “Will this make work better?” is too broad. “Can the finance team close the monthly report two days sooner without increasing correction rates?” is testable. Choose an outcome measure, a safety measure, a time window, and a person responsible for reviewing the result.
Keep the test small enough to avoid disrupting essential work but representative enough to matter. A few enthusiastic volunteers may not reveal how a tool fits the workflow, while a company-wide launch hides the signal inside a large change. Select participants who encounter different parts of the process, then document what would justify expanding, changing, or stopping.
Use a decision note to record the hypothesis, alternatives considered, assumptions, owner, review date, and rollback method. This creates a lightweight record without turning every trial into a formal procurement project. It also guards against “pilot forever,” where a trial continues because nobody has set an end date or the authority to make a decision.
Amazon’s 2016 shareholder letter makes a related point: when teams can course-correct quickly, an imperfect decision may cost less than delay. That is not a reason to accept unmeasured risk; it is a reason to build feedback and recovery into the process. The letter is at https://www.aboutamazon.com/news/company-news/2016-letter-to-shareholders.
Reserve slow decisions for real lock-in
Some technology decisions deserve more time because they alter the business’s future options. Examples include replacing a core platform, moving a high-value dataset into a service with unclear export paths, making a major identity or network architecture change, signing a multi-year agreement with significant exit costs, or allowing a vendor to become a critical operational dependency.
For these decisions, the goal is not endless consensus. It is to make the important uncertainties visible before commitment. Compare the total cost of ownership and exit cost, examine the data and integration paths, involve the teams that will operate the result, review security and privacy obligations, and define what evidence would change the recommendation. A short pre-mortem—imagining that the decision failed and asking why—often exposes assumptions that a feature checklist misses.
Do not mistake a large price tag for irreversibility, or a small purchase for harmlessness. A modest cloud application can create durable data dependencies, while costly hardware may be redeployed. Review contracts, technical dependencies, sensitive information, critical workflows, and recovery options. Where consequences are high, make approval authority explicit and require appropriate security or compliance review.
Then set a checkpoint after approval. A strategic choice is not protected from new evidence simply because executives agreed to it. If assumptions change, leaders should be able to adjust the plan without treating a course correction as failure.
Turn the framework into an operating habit
Put reversibility into the normal technology review. For each significant initiative, classify the next decision as easy to reverse, costly to reverse, or effectively irreversible. The classification can change as more users, data, integrations, or contractual obligations accumulate, so revisit it at milestones rather than relying on the original label.
Match the process accordingly. Delegate low-consequence experiments to the people closest to the work, with documented limits and fast feedback. For costly commitments, ask for a written comparison of options, transition and exit costs, security impact, and key assumptions. For decisions that could create serious business exposure, require the right mix of operational, financial, legal, and security input before approval.
Finally, measure whether the framework is improving decisions, not how many decisions it labels. Look for shorter time from proposal to learning, fewer pilots without an outcome, clearer ownership, and fewer surprises during renewals or migrations. If an experiment misses its target but is stopped early with a clear lesson, that can be a better outcome than a slow, expensive commitment made with false certainty.
Strong IT leadership is not about choosing quickly or cautiously by default. It is about designing choices so the business can move quickly where it can recover, and deliberate carefully where it cannot. Make the path back visible before walking forward, and technology investments become easier to test, govern, and scale with confidence.
