I know what we're doing isn't working but I can't see the alternative.

What to do when you know it is not working but cannot see the way out

Espoo, Finland, two thousand and eight. Inside Nokia, the world's dominant mobile phone manufacturer — over forty per cent global market share, engineering operation across multiple continents, Symbian smartphone platform on hundreds of millions of devices — the senior leadership team has just watched the iPhone take a year of market share.

The iPhone launched in January two thousand and seven. By two thousand and eight, the internal documents — some of which will later be made public during litigation — show that Nokia's engineers understand the significance of the iPhone immediately. They know Symbian, Nokia's operating system, cannot compete with iOS on user experience. They say so internally. The white papers exist. The slides have been shown.

Senior leadership sees the same evidence. They reach the same conclusion. And then they make a decision that, from inside the building, looks rational.

Defend the existing platform. Protect the carrier relationships that generate revenue. Iterate on what is already working.

The problem isn't that Nokia's leadership is blind to the alternative. They can see the iPhone. They understand it. They watch it take market share quarter by quarter. What they cannot do is act. Because acting means abandoning the platform that is still generating billions of dollars in annual revenue, and no one in the company — not the board, not the bankers, not the analysts — can find a way to justify the write-down that abandoning Symbian would require.

By the time the company commits seriously to Windows Phone in two thousand and eleven — four years after the iPhone launched — the market has already moved past them. Nokia's mobile division is sold to Microsoft in two thousand and fourteen for roughly five-point-four billion euros, a fraction of what the business had been worth seven years earlier.

The Nokia case is the canonical example of the specific failure mode this scenario describes. Not the inability to see the alternative. The inability to act on the alternative when acting means admitting that the thing you are currently doing — the thing that is still paying the bills — is already dead.

The alternative was in their hand the whole time. They could describe it. They could analyse it. They could explain why it was winning. They just couldn't become it.

So let's go to the office and work through it.

Start by asking whether pride or genuine blindness has you stuck

"I know what we're doing isn't working but I can't see the alternative."

The feeling is stymied.

You can describe what's wrong. You can explain why it's wrong. You can name the trajectory. And every time the conversation reaches so what should we do instead?, the room goes quiet. The current plan, even though it is failing, is still the only plan in the room.

Two choices. They look like the same stuck situation. They have different fundamental causes.

When you are protecting the plan you made

Choice one: pride is the problem. You know the plan is failing, and some part of you is still invested in being the person who made it work. The investment is making it impossible to see past the plan, because seeing past it means admitting that the original commitment was wrong.

If that's the read, write down — in the most brutal language you can manage — the three most devastating criticisms a hostile competitor would make of your current approach. Not what a polite colleague would say. What someone who wanted you to fail would say, if they were being accurate.

Gary Klein, working on the pre-mortem technique we covered in scenario six, was specific about this. The exercise works because the ego that's protecting the plan can't also protect you from your own written criticism. The criticism usually lands hard enough to let you see the alternative that was there all along.

When you truly cannot picture an alternative

Choice two: the blindness is genuine. The plan is failing, and you've looked, and you really cannot see what else to do. You are not protecting the current plan out of pride; you genuinely cannot construct a different one.

If that's the read, bring in someone from outside your field and ask them to explain your own strategy back to you. A finance colleague explaining your product plan. A legal colleague explaining your roadmap. An operations colleague explaining your go-to-market.

The discipline traces through what's known as the Feynman Technique — Richard Feynman's habit of explaining ideas in the plainest possible language. The explanation-back is the forcing function: when a non-expert has to describe your strategy, they unconsciously strip out the jargon and the assumptions, and what you hear is the bare logical shape of what you have been doing. The gaps in that logical shape are usually the gaps you have been failing to see because the jargon was hiding them.

Pride, or genuine blindness. Same stymied position. Two different first moves.

How to break the thinking before you replace it

Three tools. The discipline is to break the thinking before you try to replace it.

Refuse the tools that produced the failing plan

The first is

Command and Control over your own metacognition.

The discipline doesn't have a single canonical lineage. It draws on the metacognition research that emerged from cognitive psychology in the nineteen-seventies — John Flavell's foundational work — and on the thinking about thinking tradition that runs through Daniel Kahneman, Amos Tversky, and the broader behavioural-economics literature. The contemporary practice is closest to deliberate-practice writing on expertise development.

The reason metacognitive command matters when you cannot see the alternative is that the tools you have been using to think about this problem have failed. They produced the plan that isn't working. Continuing to use them will, statistically, produce another version of the same plan. The discipline is to refuse to use them again until you have new ones.

The unique insight is the named refusal. This sounds abstract and is concrete. If every previous meeting has started with a spreadsheet, don't open the spreadsheet. If every previous analysis has been about feature comparison, don't compare features. If every previous decision has come out of an off-site, don't run an off-site. The constraint is the whole point. The old habits produced the old plan; blocking them is the precondition for producing a different one.

What you get when you refuse the familiar tools is space for unfamiliar thinking. Not different conclusions from the same process — different processes, which produce structurally different conclusions.

So. How to use it.

Name. Across the recent strategy work, what tools and formats have been used? Spreadsheets, frameworks, off-sites, options papers, customer interviews. Specific.

Refuse. Block their use for this stretch of work. Not forever. Just until the alternative has been generated.

Pick. Drawing instead of writing. Walking conversations instead of meetings. Story-telling instead of analysis. The unfamiliarity is the point.

Hold. First-time use of an unfamiliar tool is uncomfortable and unproductive. Second-time use is awkward but starts producing material. Third-time use is when the tool earns its place. Don't quit at the first.

Re-evaluate. The new tools should produce a different shape of analysis. If they don't — if the analysis is still pointing at the same conclusion — the tools weren't the constraint, and the work is in choice two below.

Rotate through views the inside cannot reach

The second is

Shifting Perspectives.

Shifting Perspectives as a structured discipline traces through Edward de Bono's Six Thinking Hats in nineteen eighty-five, the role-playing tradition in strategic-planning practice, and the IDEO design-thinking method's deliberate use of multiple stakeholder perspectives. The contemporary practice is multi-source, with the common thread being deliberate adoption of perspectives the team would not otherwise consider.

The reason Shifting Perspectives matters when you cannot see the alternative is that the inside view — the perspective of the team currently running the failing strategy — is the perspective that produced the failure. Looking at the same problem from inside view longer is unlikely to surface the alternative. Different perspectives expose different gaps and different possibilities.

The unique insight is that each perspective is cheap and at least one of them will tell you something the inside view couldn't. The discipline is not to pick the right perspective in advance — it is to deliberately rotate through several and gather what each produces.

What you get is a fan of partial views, none of them complete, but together producing material the inside view alone could not have produced.

So. How to use it.

The regulator's view. What would a regulator see if they investigated your current strategy? What would they flag as risk? What would they require you to change? The regulator's view often surfaces compliance and customer-protection gaps the team has rationalised away.

The non-user's view. What does someone who doesn't use your product see? Why aren't they using it? What is in their day that your product would have to fit alongside? The non-user's view exposes the assumptions about adoption the team has stopped testing.

The disruptive startup's view. What would a well-funded competitor with no legacy try, that you wouldn't, because you have legacy? The startup's view exposes the moves the team has silently ruled out.

The next CEO's view. Imagine someone with no attachment to the current plan inheriting your role next month. What would they cut? What would they accelerate? The successor's view exposes the sunk-cost commitments.

The customer's grandmother's view. What would the user's least-technical relative see if they looked at your product? The naive view exposes the complexity the team has stopped questioning.

Each perspective is fifteen minutes of deliberate role-playing. Five perspectives is a couple of hours. The output is a set of observations the inside view did not produce.

Keep generating ideas apart from judging them

The third is

Creative Problem Solving.

Creative Problem Solving as a structured discipline was formalised by Alex Osborn — the Brainstorming author from scenario one — and Sidney Parnes through the nineteen-fifties and nineteen-sixties, codified through the Creative Education Foundation as the CPS process. The contemporary form has six phases — clarify, ideate, develop, implement in the most pared-down version, with deeper variants — but the structural commitment is the split between divergent thinking and convergent evaluation.

The reason Creative Problem Solving matters when you cannot see the alternative is that teams stuck in trapped thinking have usually lost the discipline of generating before evaluating. Every new idea gets evaluated as it surfaces, which means every new idea gets killed before it has a chance to breathe. The convergent evaluation has eaten the divergent generation, and the team has no idea-pool to choose from.

The unique insight is the discipline of keeping the two apart. Generate first, ruthlessly, without judgement. Evaluate second, ruthlessly, without sentiment. The two phases do not happen in the same conversation, in the same room, by the same people if possible.

What you get is a wider option set than the team would otherwise produce, and a more honest evaluation of those options than the team would otherwise apply.

So. How to run it.

Clarify. Restate the problem in plain language. Surface what the team has been assuming. Test the framing against the user.

Ideate. Pure divergent generation. No evaluation. Volume over quality. Wild ideas welcomed. Use techniques from scenario thirty-three — SCAMPER, random word association, morphological analysis. Generate fifty options.

Develop. Convergent evaluation. The team picks five or ten of the fifty that look most promising. Develop each into a more complete proposition. The development surfaces hidden costs and benefits.

Implement. Pick one or two of the developed options. Commit to them. Build.

The discipline is to never collapse the four phases into one meeting. The collapse is what produces the trapped thinking the framework is trying to break.

That's the toolkit. One more story before we close.

A precedent: building the alternative the institution refused to consider

The Nokia case showed the failure mode where the alternative is visible and the institution cannot act on it because action means a write-down nobody can justify. The story we close with is the structural inverse — the alternative is visible to one person, the institution has explicitly rejected it, and the move is to build the demonstration that makes the rejection difficult to sustain.

Philadelphia, nineteen fifty-one. Grace Hopper is working at the Eckert-Mauchly Computer Corporation — then a subsidiary of Remington Rand — in the early days of what will later be called software engineering. The company has produced UNIVAC, one of the first commercial computers. The work of programming it is done by hand, with each subroutine retrieved and linked by hand for every new program.

Hopper has been thinking about the question of whether the linking and retrieval of subroutines could be done by the computer itself. A program that writes programs. The idea, in the institutional consensus inside Remington Rand, is wrong on two grounds. Computers are arithmetic machines. They do not write programs. And Hopper's project is both technically impossible and a misuse of expensive machine time.

Hopper has documented this institutional consensus herself, in her nineteen seventy-eight ACM History of Programming Languages keynote. The consensus is named, the rejection is explicit, and the resources for the project are denied.

Hopper's response is not to argue with the consensus.

She builds the compiler anyway. In secret. Using machine time she is not formally authorised to use for this purpose. And she builds it to the point where it runs. The A-zero compiler — a functional, demonstrable running compiler — is the counterargument. The existence of a working system makes the impossible claim difficult to sustain once the demonstration can be performed, and it opens the ground on which COBOL and the whole trajectory of machine-independent programming languages will subsequently be built.

So.

Nokia at the iPhone moment had the alternative in their hand and could not act on it because acting required a write-down nobody could justify. Hopper at Remington Rand had the alternative in her hand and the institution had already rejected it before examining it closely. Two inversions of the same problem. The first failed. The second succeeded — and the difference is that Hopper treated the institution's rejection as a claim about what it would and would not fund, not as a claim about what was possible.

When you know what you're doing isn't working but you can't see the alternative, there is a version of the problem where the alternative exists and you need to discover it. There is another version, harder to name, where the alternative exists and the institution has already rejected it before examining it closely. The alternative was not difficult to see. It was difficult to get permission to see.

Hopper built the demonstration anyway. The demonstration was the argument the institution had been refusing to have.

So. Your Next Move from this playbook.

How would a competitor you secretly admire solve the problem in your next meeting — and would you be willing to copy them, or is pride going to stop you?