Leadership Garden
I was sitting in a quarterly review when an engineering director looked at a slide saying a migration was 72 percent complete and asked, “Which of the assumptions behind this are still true?” We had spent eighteen months moving a large product to a new platform. At the time, the decision rested on a coming end-of-support date, a plan to double the engineering group, and a customer certification that appeared to require capabilities only the new platform provided.
By the day of the review, the vendor had extended support, hiring had stopped, and the certification team had found another route six months earlier. The program still had fourteen people assigned to it and a green status on the portfolio dashboard. Once the question was out in the room, however, the discussion moved away from customers and technology. We talked about the work already completed, what we had told the board, and how cancellation might land with the teams. One executive said that changing course would damage our credibility, and I wrote the sentence in the margin because it explained the meeting better than the slide did.
If you lead engineering, product, or a company, you will eventually inherit a decision like this. It may concern a platform migration, a reorganization, an acquisition, a pricing model, or a product that has never found a market. In each case, the original reasoning has weakened while the work created by the decision has become a substantial fact of organizational life. Asking whether the choice still makes sense can then sound less like routine management and more like an accusation.
Decisions become part of the organization
A decision starts as a choice among alternatives, but it quickly produces consequences that are harder to move. Budgets shift, teams form, contracts get signed, and roadmaps absorb dependencies. Someone may get promoted for leading the work while another group is asked to wait because the organization has committed elsewhere. Within a few quarters, the choice has become part of the structure surrounding it, with employees and commercial obligations that remain even if the original argument weakens.
The reasoning rarely survives that process intact. A decision document may record what was approved and who approved it, followed by a few broad paragraphs about benefits, risks, and strategic fit. “Improves scalability” tells a future reader almost nothing about the scale problem that mattered, the growth forecast used, or the evidence that would have disproved it. People who join later therefore learn the decision as a settled fact: we are moving to the new platform, centralizing this function, or building for enterprise customers. They inherit an implementation plan without the uncertainty that surrounded the original choice.
That lost uncertainty matters because markets, regulations, customer preferences, and internal constraints continue to change. A decision that made sense two years ago may have little value now without having been foolish at the time. Leaders often feel pushed toward defending it because the apparent alternative is to confess a mistake, which is both inaccurate and personally costly when the old reasoning was sound. They may be right about the quality of the decision they made and still be wrong to keep funding it today.
Why organizations keep going
The usual diagnosis is the sunk cost fallacy: we continue because we have already spent the money, time, and political capital. Barry Staw’s work on escalation of commitment showed that people often increase their support after receiving negative feedback, especially when they were responsible for the initial choice. Self-justification, loss aversion, confirmation bias, and the urge to complete what we started all contribute. Inside an organization, however, persistence can also look like evidence that a leader is steady and dependable, which gives people another reason to prefer it.
The Decision Lab describes research in which participants trusted CEOs more when those CEOs kept funding product development after learning that a competitor had a better product. I understand why. Nobody wants a leader who rewrites strategy every time a metric dips, and most worthwhile efforts pass through periods when the evidence looks bad. The difficulty is that organizations are poor at distinguishing steadiness from attachment, particularly once the person interpreting the evidence also sponsored the original choice.
A public decision changes the social cost of information. Before approval, a troubling fact helps the group choose well. After approval, it can threaten the sponsor’s judgment and undermine months of work by the team. People notice the difference, so status updates start to emphasize progress while risks become matters of execution. Another quarter, feature, customer segment, or enablement effort may be defensible on its own, but a series of those small extensions can convert evidence against the decision into a recurring request for more investment.
Stopping also creates costs that are immediate and easy to name: a write-off, a revised roadmap, a difficult board conversation, and a team that needs new work. The costs of continuing arrive gradually through missed opportunities, delayed hiring, added operational work, and capable people spending another year on a problem whose value has fallen. We rarely account for the product that was never built or the customer problem that waited because the team was occupied elsewhere. The leader proposing a stop must therefore own a visible disruption now, while the leader proposing continuation can spread the cost across several teams and future quarters.
Ordinary execution reporting reinforces the imbalance. Portfolio reviews tend to ask whether a program is on schedule, within budget, and delivering milestones, which tells you whether the team is carrying out the plan but says little about whether the plan remains worthwhile. A migration can hit every milestone after the vendor risk that justified it has vanished. A sales team can complete its hiring plan while acquisition costs ruin the business case. A reorganization can move every employee into the intended box even though it never resolves the ownership problem behind the change.
Freek Vermeulen and Niro Sivanathan describe this as escalation of commitment to a once successful strategy. Their HBR article uses HMV, whose store model had produced years of success before the market moved online. That history made contrary evidence easier to dismiss because leaders could point to a long period in which the same judgment had been correct. I have made a smaller version of this mistake myself by pushing a team harder because I trusted a pattern that worked in another company, at another scale, for a different customer. The team executed well, but my assumption did not travel with me, and extra effort merely made the mismatch more expensive.
Record what must remain true
Most decision records tell us what was approved, who owns the work, and what happens next. They are much less likely to state what must remain true for the decision to keep its authority, even though that is the part a later team will need when circumstances change. Adding the question forces broad claims into a form that people can examine. “We need a new platform for scale,” for example, becomes “The current platform will exceed its tested transaction limit within eighteen months, based on the approved growth forecast.” An enterprise strategy can specify how many qualified prospects must accept the proposed security model and price. The language is less polished, but a future reader can see what evidence supported the choice.
Mark Hollingworth’s article on revisiting strategic assumptions describes field research in which startups identified hypotheses, selected evidence thresholds, and changed course when the thresholds were not met. One company continued with its proposed business model only if four customer assumptions held, while another changed its target customer and its vehicle after testing exposed weaknesses in the original idea. The founders remained committed to building their companies. What changed was the precision with which they decided whether a particular model deserved more time.
I now want six things in a decision record:
- The outcome we want, stated in terms a customer or operator would recognize.
- The assumptions that connect the decision to that outcome.
- The evidence available when we made the choice.
- The signals that would require us to review it.
- The expected cost of continuing, changing, or stopping.
- The person who can call for a review, especially if the original sponsor disagrees.
This takes more effort than writing “approved” in a meeting note, although considerably less than funding obsolete work for several years. The record does not need to pretend that every uncertainty can be reduced to a clean metric. A qualitative assumption can be useful if people can describe the evidence that would weaken it. “Customers will tolerate the migration” is too vague, while “our ten largest customers will accept one scheduled outage and no more than two required integration changes” gives a team something it can investigate before memory reshapes the original reasoning.
Review current evidence without retrying the past
Asking “Was this a bad decision?” is a poor way to open a review because the meeting immediately becomes a trial of the original participants. People reconstruct old information, defend their intentions, and debate whether somebody should have predicted an event that looked unlikely at the time. A more useful sequence begins with the intended outcome, then examines each original assumption against current evidence before comparing the options available now.
This separates the quality of the old reasoning from the present value of the choice. A decision may have been sensible then and sensible now, sensible then but weak now, or poorly reasoned from the start and either lucky or costly in its results. The current evidence should determine what happens next, while the quality of the original process belongs in a later learning review. Keeping those conversations apart makes accountability more accurate because leaders can still answer for hidden risks and ignored evidence without being punished whenever a reasonable forecast fails. If every change of course requires a confession, most leaders will wait until the evidence becomes overwhelming.
Isabelle Royer, writing about projects that organizations could not kill, argued for an “exit champion” with enough standing to assemble the case for stopping. The original sponsor should remain involved because that person usually knows more about the decision than anyone else, but sole ownership makes an impartial review unlikely. I have found that a second credible leader can provide enough independence to test the current case without reducing the discussion to criticism from someone who lacks context.
Decide in advance what will trigger a review
Scheduled reviews help, but a calendar alone is a blunt instrument because the passage of six months does not necessarily make a decision questionable. A material change in one of its supporting conditions does. Annie Duke calls the more decisive versions of these conditions kill criteria: signals chosen while judgment is relatively clear that will cause you to modify or abandon a goal. A review trigger can be gentler. It does not dictate the outcome, but it obliges somebody to gather current evidence and recommend whether to continue, change, or stop.
The useful triggers depend on the decision. A product team might reopen its plan when adoption falls below an agreed threshold or acquisition cost changes substantially. A technical program could use a shift in vendor support, traffic forecasts, regulatory requirements, or the relative cost of migration and continued operation. After a reorganization, unchanged decision time or work continuing across the same boundaries may reveal that the structure did not address the problem it was designed to solve.
I would give material decisions both a review date and a small number of evidence-based triggers rather than an automatic expiry. Automatic expiry invites churn and encourages teams to wait out a direction they dislike, while an optional review is easily skipped when it becomes uncomfortable. Reaching a date or trigger should produce a recorded choice. If no one acts, the old decision should not renew itself by default.
Make the cost comparison honest
When a review finally happens, teams often compare the immediate cost of stopping with the total value they once expected from finishing. That comparison favors continuation because it mixes money already spent with benefits that may never arrive. Past spending can teach you about the original estimate and process, but it cannot improve the return on the next dollar. The current comparison should include:
- the remaining cost and likely value of continuing
- the switching cost and likely value of the best alternative
- the operating cost of delay
- obligations to customers, employees, and partners
- what the organization could do with the people, time, and attention released
Switching costs are real. Contracts have termination clauses, migrations leave systems in awkward intermediate states, teams lose momentum, and customers may have planned around a promise. A review that ignores those facts becomes an abstract lesson in rationality rather than a management decision. Sometimes continuing remains the best available choice because a change would now cost too much, but leaders should reach that conclusion by comparing future options from the present instead of asking past investment to justify another round.
Opportunity cost deserves similar care because an imagined alternative has no defects yet. When somebody says, “We could use the team elsewhere,” I ask for a named piece of work, an owner, and a plausible first ninety days. The alternative should face the same scrutiny as the program under review rather than benefiting from its lack of history.
The leader sets the price of changing course
Every organization says it wants people to surface bad news, but employees learn what that means by watching the first person who tries. If a director brings evidence that an executive’s decision has aged badly, the executive’s first response sets the price of candor for everyone else. Asking why the risk was not found earlier may sound like due diligence, yet it often turns the messenger into the subject before the group has considered the evidence.
I try to begin with “What changed?” and “What do you recommend now?” The first question distinguishes changed conditions from blame, while the second makes the person raising the issue responsible for a better choice rather than giving them permission to criticize from the sidelines. When revising my own decisions, I prefer a plain account of what happened: “I approved this based on the evidence we had. Two assumptions no longer hold, so I am reopening it.” That sentence names the decision maker without forcing an apology unless one is actually due.
Some leaders worry that revisiting a choice makes them look indecisive, and frequent changes without clear criteria certainly do erode trust. Teams usually react differently when they can see that the evidence crossed a threshold set in advance. Engineers know when a migration no longer solves its stated problem, product managers notice when every customer conversation requires a new justification, and frontline managers can tell when a reorganization moved names without changing decisions. They may continue doing the work, but they will no longer believe the status report if leadership refuses to acknowledge what they see.
A review needs a threshold
There is a corresponding risk in making every decision easy to reopen. Teams can spend months repeating old debates, treat ordinary execution difficulty as evidence that the choice was wrong, and pull senior leaders into matters that were already settled. New evidence should connect to an assumption that materially influenced the decision, and the person asking for a review should propose a current alternative that includes the cost of switching.
A disappointing result may not meet that standard. A product can miss its first adoption target while the customer problem remains real, and a new architecture can take longer than planned while the old system still faces a firm end-of-life date. The early months after a reorganization are often awkward because people are learning new responsibilities. Leaders still have to judge whether the team is struggling with hard execution or working from a premise that has broken, which no process can do on their behalf.
The decision owner remains responsible for the final choice, and a review does not require consensus. It requires a good-faith examination of the current evidence and a recorded conclusion. Once the group decides, the team should understand what changed, what remained true, and which future trigger would warrant another discussion so that people can commit to the work again.
A practical decision review
I use a short written review before the meeting because it prevents the loudest person in the room from defining the history. The author answers five questions:
- What outcome did we intend, and what did we decide?
- Which original assumptions still hold?
- What material evidence has changed?
- What options are available now, including the cost of switching?
- What is the recommendation, owner, and next review trigger?
The meeting can usually fit into forty-five minutes, with the first ten spent on the original objective and assumptions, the next fifteen on current evidence, and the rest on options and a decision. If people disagree about what the original assumption was, I record that as a flaw in the earlier process and work with the best evidence available instead of letting the meeting become an attempt to edit history. I also ask someone who was not involved in the original choice to read the review. They do not need veto power, only enough standing to ask the question that insiders have stopped noticing.
The final note should state whether the organization will continue, modify, or stop, along with the evidence, owner, and next trigger. The roadmap, budget, and team goals should change soon afterward. Otherwise the review becomes another document that everyone politely acknowledges and then ignores.
What happened to the migration
We did not cancel the platform migration during that quarterly review. Instead, the engineering director and a finance partner reconstructed the original case, compared the remaining work with two years of operating cost on the old platform, and spoke with both the certification team and the vendor. A week later, they recommended stopping most of the program while keeping a smaller part that still addressed a real reliability problem.
The announcement was uncomfortable. One team had just finished planning the next quarter and discarded much of its work, while the company wrote off contractor time and training. Several people said we had wasted eighteen months, and in part they were right. We had also learned enough about the new platform to make a more informed choice, and some components found uses elsewhere, but that did not make the disruption disappear.
Six months later, the board had asked its difficult questions and moved on. Most of the engineers were working on reliability and customer problems we had deferred. Looking back, I think our credibility had suffered more from continuing to report the program as healthy after its rationale had weakened than it did from changing course.
Since then, before approving a material decision, I have tried to ask what would have to change for us to revisit it. An inability to answer usually means the choice will become harder to undo than it deserves, while an answer that threatens the sponsor teaches the organization to hide evidence. Leaders who signed yesterday’s decision have an added responsibility to review it honestly today.