Skip to main content
Steady at the Top
← All articles

How to choose early wins that help a turnaround last

Choose an early turnaround win for its customer consequence and what it proves about execution. Compare the effort, dependencies, and durability of each candidate before committing scarce capacity. A visible announcement is useful only when the operating result can be verified.

Job feedback is direct information from performing the work about how effectively that work was done. Hackman and Oldham describe this construct in their 1980 work-design chapter: Work Redesign, chapter 4: Motivation Through the Design of Work. For an early win, choose a result the operating team can inspect, such as whether a corrected handoff reaches the customer. Recognition acknowledges effort. Job feedback shows the consequence of the work itself; a board compliment cannot substitute for it.

A private moment that makes the issue visible

Composite scenario, not a client case: You cancel another evening plan to review a board deck describing momentum. The photographs show a new team meeting format. Meanwhile, an important customer is waiting for a corrected delivery date. You can feel the pressure to show movement, but the deck does not yet answer what the business can now do more dependably.

Use the research within its limits

Vroom and Jago (2007) connect leadership choices with the situation surrounding a decision: Vroom and Jago (2007): The Role of the Situation in Leadership. Use that perspective to test whether an early-win project fits current capacity and requires participation from the right functions. A fast-looking repair can still depend on authority the sponsor does not hold. The comparison below is a proposed selection method, without a claim that the research validates its ranking or guarantees recovery.

State the decision before discussing personalities

The choice is which small result deserves limited recovery capacity. Define the business consequence before choosing the most presentable project. Include the work you will delay to create capacity.

Use the customer-consequence early-win comparison

  1. List candidate outcomes. Describe a small set of customer or operating failures that could be corrected. Use results such as a reliable handoff rather than activities such as holding a workshop. Put the proposed result beside a recent failure it would change. Exclude projects whose main output is a better description of existing work.

  2. Check the customer consequence. Identify whose work improves and what evidence would demonstrate that improvement. Confirm the benefit with the people affected instead of inferring value from executive enthusiasm. Ask the receiving customer or internal recipient what would count as resolution. Agree on evidence beyond the sponsoring executive’s assessment.

  3. Expose the dependencies. Name the capacity, decisions, and system access each candidate needs. Reject a quick-looking project whose key dependency cannot be secured. Name the team that must give up capacity. Confirm its displaced commitment rather than hiding the tradeoff in a broad transformation budget.

  4. Choose a durable test. Prefer an intervention that reveals whether a necessary routine works. Identify what would continue after the CEO stops checking it personally. Include the next comparable instance after exceptional founder attention ends. Describe who will notice if the repaired handoff fails again.

  5. Show the result and limits. Report the original condition, the observed change, and the unresolved work. Give credit to contributors without presenting one repair as proof of a completed recovery. State which portion remains a pilot. A successful order can establish a useful example while leaving wider implementation and exceptions untested.

Compare outcomes rather than project names

Ask each sponsor to describe what a customer or receiving team will experience differently. Replace “launch the dashboard” with the decision the dashboard should enable. Replace “hold the workshop” with the handoff the workshop is supposed to repair. Keep the project’s activity in the plan, but evaluate its claim of value against the proposed consequence. If the sponsor cannot describe that consequence, the project is not yet ready to be called a win.

Use a common comparison sheet with a field for the current failure, the smallest useful correction, the people required, and the evidence of resolution. Add the obligation displaced by choosing the project. You are allocating limited recovery capacity, so the alternative matters. A short project that delays an essential customer repair can be a poor early choice even when its own deliverable is easy to complete.

Ask a person outside the sponsoring function to inspect the proposed outcome. For an order dispute, that person might be the recipient who currently must reconstruct missing information. Have them explain what a complete handoff contains. Avoid asking only whether they support the initiative. Support for a project does not establish that its output will solve the receiving team’s problem.

Give the quick-looking candidate a dependency test

Trace what must happen before the result becomes usable. A revised approval rule might require finance agreement, a changed system field, and training for the people receiving requests. Identify the unresolved dependency that could stop the first case. Obtain an actual commitment from its owner. Do not treat a line in the recovery presentation as permission to consume another team’s time.

Compare a broad implementation with a bounded test of the same idea. You might propose testing one type of disputed order before changing the entire intake process. Define which cases belong in the test and which do not. Make the limits explicit to customers and operators. The aim is to learn whether the necessary routine works, not to select a convenient sample that makes every case look successful.

Distinguish a small scope from a trivial consequence. Correcting a narrow failure can matter when it removes a recurring obstacle for the people affected. Conversely, a highly visible launch may contribute little to the recovery outcome. Ask the sponsor to explain the relationship rather than relying on the project’s size, publicity, or proximity to the CEO.

Write the acceptance evidence before the announcement

For a hypothetical order-handoff repair, the acceptance note could require a complete intake record, a named decision owner, and a customer answer based on confirmed capacity. Ask the receiving team to show those elements in the next eligible case. Record a missing element as a failure to investigate. Completion of the new form alone would not establish that anyone used its information to make the decision.

Inspect the exception path as well. A process can handle the ordinary case while leaving an unusual request circulating between managers. Decide where that request goes and who can choose among the tradeoffs. Do not remove difficult cases from the count after results appear. If the scope changes, show the old and new boundaries so reviewers can understand what the test established.

Capture the work before extraordinary support is withdrawn. Identify the founder calls, extra staffing, or manual corrections that contributed to the result. Some may be justified during recovery. The question is whether the proposed routine depends on keeping them. Decide which support becomes part of the operating model and which needs a replacement. Keep that cost visible when comparing the win with other uses of capacity.

Tell the board what improved and what remains open

Report the failure the project addressed, the evidence of a changed result, and the limits of the test. Show the observed customer consequence beside the completed activity. If the first order passed but subsequent cases remain untested, say that. The report should let the board distinguish a useful pilot from a repaired company-wide process.

Describe a failure discovered during the test without treating it as a communications problem. It may identify a missing approval right or an exception the original proposal ignored. Assign that finding to the appropriate owner and revise the implementation plan. Avoid protecting the early-win label by moving the unresolved case into another category. The recovery benefits from a clear finding even when the original claim must be narrowed.

Keep recognition specific to the contribution. Explain who corrected the intake, resolved the dependency, or maintained service during the test. Do not require the team to endorse a larger success story to receive credit for that work. A precise account can acknowledge progress and preserve the customer’s unresolved concern at the same time.

At the next recovery review, ask whether the new routine survived an ordinary working period. Examine a reopened case and a clean handoff. If personal intervention remains necessary, decide whether to redesign the routine or continue its support explicitly. Keep the early win because it creates an operating capability you need, not because removing it from a green dashboard would be embarrassing.

Put the boundary into words

Our first win must matter to a customer and demonstrate a repeatable way of working. Show the capacity it needs, the work it displaces, and the evidence that will tell us whether it lasts.

Work through a bounded example

Hypothetical application: The team compares a refreshed reporting dashboard with a repair to disputed-order handoffs. The handoff repair requires fewer system changes and has a visible customer consequence. The CEO chooses it, names an operating owner, and checks whether the next comparable order follows the new routine without personal intervention.

Check the failure mode before scaling

Avoid selecting only the easiest measure to move. A reduction in open tickets can reflect premature closure rather than resolution. Inspect a sample of the work and the customer consequence before celebrating the indicator.

When customer harm or another immediate exposure needs containment, authorize that work through the responsible operating adviser. Do not postpone it while polishing the early-win comparison. Keep the containment decision distinct from a claim of durable improvement. If a temporary extra shift resolves the backlog, explain the additional capacity before presenting the result as proof that the normal handoff now works.

Review the work, then revise the arrangement

Review the result after the initial attention has passed. Ask whether customers experienced the improvement, whether ownership stayed clear, and what the test taught you about the larger recovery.

Use Edmondson’s 1999 work on interpersonal risk as a reason to ask who can report that the celebrated win did not hold: Edmondson (1999): Psychological Safety and Learning Behavior in Work Teams. A customer-service employee should be able to identify a reopened case without having to attack the recovery team’s credibility. Investigate the case before defending the announcement. That reporting arrangement is a recommendation; this article does not measure the team’s psychological safety.

Connect this decision to the next one

An early win belongs inside the returning-founder recovery plan. Test familiar but unhelpful projects against the founder legacy discussion. Compare the chosen project’s resource demand with the turnaround pace and capacity guide. Once the result is demonstrated, use visible progress to explain the contribution without declaring the recovery finished.

Sources

Steady at the Top