A Pivot Is Not Complete When the Decision Is Made

When you take the company in a new direction, the decision can feel like the change itself. The long debate is settled. You have made the call, whether that means a different customer, a different offer, a new market, or a different way of making money, and the reasoning holds up. The direction is clear enough that everyone can describe it the same way. You know what the company is trying to become.

Then, days later, the old direction is still running. The proposal that goes out still describes the former offer. The intake form still qualifies the customer you are leaving. Finance still quotes the old pricing. The team is still measured against the work you just said you were moving away from. A customer sees the new promise on your website, then meets the old company in every interaction that follows.

Nobody is ignoring the decision. You changed the company’s direction before you changed the places where that direction has to become real.

A pivot can be strategically right and operationally incomplete. The decision sets the direction. It does not, by itself, change what the company does day to day, because the old direction does not survive through anyone’s loyalty to it. It survives through defaults.

The old direction is wired into your tools: the proposal template, the pricing sheet, the CRM stages, the intake questions, the approved discount, the compensation plan, the dashboard, the standard contract. Every one of them was built to run the company as it was. Until the relevant defaults change, the easiest path through the day is the old one, because the old one is the one that already exists. A team that keeps using it is not resisting the strategy. It is using the company it was given. This is why communication alone rarely fixes the problem: you keep explaining the new direction while the working environment keeps producing the old one.

The company in the middle is a real company

Between the company you are leaving and the company you are becoming, there is a third company. Until the pivot is done, it is the only one you are actually running, and it is the one no one designed. During the transition you may have legacy customers and new customers at once, two prices, two ways of delivering, two definitions of a good week, and one team trying to work out which rule applies to which piece of work. That in-between period is not dead time before the new model starts. It is a real operating condition, with its own customers, commitments, rules, and exceptions, and it has to be designed as deliberately as the destination.

Designing it comes down to one question, asked of every part of the company the old direction still runs through: what happens to this while the change is underway?

Some things change now, because leaving them active contradicts the decision or creates real risk. Stop advertising the offer you are retiring. Stop qualifying the customers you will no longer serve. Stop letting new contracts be signed under terms you are walking away from.

Some things stay valid for now, on purpose, for a named reason: existing contracts, support for customers already on the old model, a cohort you have not migrated yet. Each needs a boundary, which cases it covers, who owns it, and the condition that ends it. “Temporarily valid” without an expiration is just the old company, still running.

Some things run in parallel, old and new at once, when continuity or comparison requires it. Parallel operation can be responsible, but it is not free; it tends to double the work rather than split it. Each parallel path needs a reason to exist, a rule for which cases use which model, one authoritative source when they disagree, and the evidence that will let one path end.

And some things stop. Stopping is more than announcing that something is over. It means closing the intake route, changing the default in the system, updating the incentive, and telling the customers and partners who were relying on it.

Move the parts in order

Sorting each part into a state is only half the work. The other half is the order, because the parts depend on each other. Change them out of order, and you only move the problem downstream. The exact order varies by pivot, but the dependency is usually the same: define the operating rules, account for what you still owe, change how new work enters, update what carries it, then test one complete path.

Start by turning the decision into operating rules. “Enter a new market” is not yet a rule, and neither is “move upmarket” or “shift to recurring revenue.” You still have to decide which customers become primary, which work you will no longer accept, what changes in the offer, which price and terms apply, what delivery must be able to do, and what can no longer be promised. Then inventory what the old direction still obligates you to: signed contracts, open proposals, renewals, scheduled work, support you still owe.

Change the whole path new work enters through next, from the intake and qualification to the offer, the pricing, the proposal, the terms, and the approval, so nothing new is shaped by the old direction from the first touch. Then move what has to carry those commitments: the delivery, the support, the systems behind them, and the measures.

The measures matter more than they look, because you cannot ask people to pursue one direction while you still reward another. You cannot move from projects to recurring revenue while judging the team by project completion, or narrow the market while celebrating every inquiry equally. People do not have to disagree with the strategy to keep reproducing the old one. They only have to remain measured by it.

Once the parts are moving, run one real case through the new company, from first inquiry to delivery and measurement, and watch where it falls back into the old one. That is not a universal order, but it is the usual shape of the dependencies, and naming it keeps each function from choosing its own.

A pivot has more than one date

Underneath all of this is a distinction most companies never make. A pivot has more than one date: the day you decide, the day a specific rule actually changes, and the day the old path stops taking new work for good. It is easy to announce the first as though it were the second, and to never set the third. The decision date is real progress, but it does not change the operating company on its own. An effective date is when the intake form actually changes, and different parts of the pivot may reach it at different times. The retirement date is when the old path can finally be closed, and it does not arrive because everyone is tired of running two models. It arrives when the evidence says the new one can carry the work: a real customer can enter the new path and reach the result, the legacy obligations have been honored or moved, the systems and metrics point at the new model, and someone can run it without heroics.

Retiring on evidence also preserves your ability to respond responsibly to what you learn. Where the old and new can safely run side by side, keep enough of the old path in place to learn before you dismantle it, because if the transition shows the new direction is not ready and you have already torn the old one down, you have nowhere to stand. But not every old path can safely stay open. Some conflict with the new model, carry legal or contractual risk, preserve the economics you are trying to escape, or keep pulling in the work you just decided to stop. Where old and new cannot coexist, you do not keep both alive. You define the cutover, the contingency if the new model stumbles, and who has the authority to pause or narrow the change. The goal is not to keep the past running. It is to avoid making an irreversible operating change before the evidence supports it.

Someone has to own the middle

Someone has to own the middle, or none of the rest holds. Everyone wants the destination; almost no one wants the middle. In a small company this is not a new hire. It is you, or a senior person you trust with the authority, who keeps the transition coherent rather than doing every task, sequences the dependencies, resolves the cases that fit neither model, and tracks whether the old defaults are actually being removed. Without that ownership, every function interprets the pivot on its own: one races ahead, another waits, a third keeps the old process because no replacement is ready. From a distance that looks like resistance. Up close it is usually an unowned transition.

The mistake I have watched companies make is not the decision. It is waiting for the decision to change the company on its own, which it never does.

So the day you choose the new direction, be honest about two things. The first is what becomes true now: what you will no longer sell, which new work enters the new model, what stays valid for now and what cannot run in parallel, who owns the transition, and which source of truth now governs. The second is what must become true before you can act as though the pivot is finished: the new path can carry a real customer, the legacy obligations have a defined treatment, the systems and measures have moved, and the evidence exists to retire the old path responsibly.

A designed transition does not make a weak strategy work. The direction can still be wrong, the timing poor, the economics thin, and no transition will fix a choice the market rejects. What a designed transition does is give the strategy a fair test: when the new model underperforms, you are reading the market, not your own unfinished operating system.

So the pivot is finished when the new direction can run without the old one propping it up, and no new work enters the old path by default. Until then, you have only made a decision about the future. You have not completed the pivot.