A dependency has failed and I need a plan B by tomorrow.

What to do when a dependency fails and you need a plan B by tomorrow

San Francisco, mid two thousand and nine. Lookery, an early advertising network built specifically for the Facebook application ecosystem, has had a fast eighteen months. Facebook is opening its platform to third-party developers. The applications that run on top of Facebook need to monetise. Lookery has built the network that does the monetising, and the team has spent the last year scaling it.

Then Facebook changes its platform policies.

Not in a way that targets Lookery specifically. A routine design and policy update from Facebook's perspective, made for reasons internal to Facebook's evolving understanding of its own platform. From inside Facebook, the change is a course correction. From inside Lookery, the change is the entire ground the company stood on shifting four feet to the left.

The founders have no Plan B. Not because they were lazy. Because the dependency that failed wasn't a technical component they could replace. It was the whole platform their company existed on. Lookery's product, team, and revenue model all assumed Facebook's platform terms would continue to be permissive. The terms changed. The product no longer works in the form the team had built.

They shut the business down within weeks of the Facebook change.

The lesson in Lookery isn't don't depend on Facebook — that's retrofitted wisdom. It's that single-source dependency on anyone else's platform creates an exposure you cannot hedge after the fact. Only before.

When a dependency fails and you need a plan B by tomorrow, the question of whether you have a plan B was answered months or years ago. What's available to you tomorrow is what you built into your operation when the dependency was still working.

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

First decide what kind of failure you are facing

"A dependency has failed and I need a plan B by tomorrow."

The feeling is stranded.

The thing you were relying on has stopped existing in the form you needed it. The deadline didn't move. And the team that's been operating on the assumption the dependency would hold is now waiting for you to tell them what happens next.

Two choices. They look like the same crisis. The first move is different.

When the failure is a chance to gain from the chaos

Choice one: the failure is an opportunity in disguise. The dependency failing is a genuine chance to change something your team has been stuck with for years. Panic is obscuring the opportunity, but the opportunity is real.

If that's the read, pick the Plan B that gains from the chaos rather than the one that just replaces the lost capability. Not the safest option. The one that would have been unthinkable a week ago and is suddenly available precisely because the old constraint is gone.

Nassim Taleb's antifragile framing is doing the work here. Crises are the only time you get to make changes that couldn't survive a normal process — because everyone, including the people who would normally veto the change, is too busy responding to the crisis to defend the status quo. Wasting a crisis by restoring the status quo ante is more expensive than the crisis itself, because you've paid the cost of disruption without earning the option of structural change.

When the team is too close to see clearly

Choice two: you are too close to the problem. The team is so deep in the context of the failed dependency that every option looks contaminated by the thing that just broke. Each plan B looks like a worse version of the dependency you just lost.

If that's the read, pull in someone from a completely different part of the business. Finance, HR, operations, a friend in a different industry. Ask them to solve it.

Matthew Syed, working on cognitive diversity in crisis, found that the value of an outsider in a problem like this is their ignorance, not their expertise. They will suggest things your team has silently ruled out for reasons that no longer apply, or for reasons that were never as solid as everyone assumed. Most of the rigidity in a team's thinking is unexamined constraint, and the outsider is the fastest way to surface which constraints are real.

Opportunity, or too-close. Same dependency failure. Two different first moves.

How to remap the terrain before you pick a route

Three tools. The discipline is to remap the strategic terrain before you pick a route through it.

Plan across several plausible futures, not the loudest one

The first is

Scenario Planning.

Scenario Planning was developed at Royal Dutch Shell by Pierre Wack and his team through the late nineteen-sixties and nineteen-seventies, in response to the strategic-planning failures of pure forecasting in volatile environments. The discipline was famously the reason Shell was structurally prepared for the nineteen seventy-three oil crisis when its competitors weren't — not because Shell's planners predicted the crisis, but because they had thought through what to do if. The contemporary practice has spread well beyond energy companies, but the lineage is Shell.

The reason Scenario Planning matters when a dependency has failed is that the failure has now created a fan of plausible futures, and the team is reacting to the most visible one rather than the most likely. The visible future is the one in front of the windscreen. The likely future may be down a different road that the panic has obscured.

The unique insight is that the point of scenarios is not to predict; it is to make sure you're not over-investing in the most visible scenario when a different one is more likely. The discipline produces options that survive multiple futures, rather than commitments that work only in one.

What you get is a small set of plausible futures the failure has now created — and, for each, a clear sense of what would be required to operate in it. The plan that emerges is the one that does best across the set, not the one that does best in the future the panic is pointing at.

So. How to run it.

Sketch. Mildly disruptive, genuinely threatening, surprisingly opportunistic. Each in two or three sentences. Mildly disruptive: we find a like-for-like replacement supplier in two weeks. Genuinely threatening: no replacement exists at the price point and the ship slips by a quarter. Surprisingly opportunistic: building the replacement in-house turns out to be cheap and gives us strategic independence we didn't have before.

Identify. For each scenario, name the specific actions and resources needed to operate in it. The list often surfaces actions that are useful across multiple scenarios — those are the no-regret moves you start on today.

Pick. Whatever's required across all three plausible futures is what you do this week, regardless of which scenario unfolds. The scenario-specific moves wait until the situation has more clearly resolved.

Watch. Each scenario has tell-tale early signals that distinguish it from the others. Knowing what to watch for compresses the time to recognise which scenario is unfolding.

The second is

Check whether the lost component is now a commodity to buy

Wardley Maps.

Simon Wardley developed Wardley Maps in the late two-thousands and has continued to refine the practice through his Medium writing and the Mapping Maturity book series. The maps trace a value chain from user need at the top to underlying components at the bottom, plotting each component on a horizontal axis from genesis — newly invented — through custom-built and product to commodity. The discipline is structural rather than analytical.

The reason Wardley Maps matter when a dependency has failed is that the map will often tell you the dependency you have been treating as a custom integration has, in fact, become a commodity you can simply buy from another supplier. The map exposes the evolution axis the team has been ignoring.

The unique insight is that most teams over-invest in building things that the market has quietly commoditised underneath them. The dependency that just failed may not need to be rebuilt. It may need to be purchased, from any of three or four suppliers who have been doing the same thing as a commodity service while the team built their own version of it.

What you get is a different question to ask in the crisis. Not how do we rebuild the failed dependency? but what stage of evolution is this component actually in, and is there a commodity supplier we should just buy from? The answer often saves weeks of unnecessary rebuilding.

So. How to use it.

Map. User need at the top. Components below, each leaning on the one underneath. Two or three layers is usually enough; you don't need a complete enterprise architecture for a Plan-B-by-tomorrow conversation.

Place. Genesis, custom-built, product, commodity. Be honest. Most teams discover their failed dependency is further to the right of the evolution axis than they had been treating it.

Look. If the failed component is in the product or commodity zone, there are suppliers. Identify them. The plan B is a procurement question, not an engineering question.

Replan. With the commodity options on the table, the rebuild often becomes unnecessary. The team's energy can move to the components that are genuinely earlier in their evolution and still need attention.

Break a stuck contradiction with proven patterns

The third is

TRIZ.

TRIZ — Teoriya Resheniya Izobretatelskikh Zadatch, the Theory of Inventive Problem Solving — was developed by Genrich Altshuller in the Soviet Union from the nineteen-forties onwards, after Altshuller analysed several hundred thousand patents to surface the recurring patterns of inventive problem-solving. The framework has spread into Western engineering and innovation practice through the nineteen-nineties and two-thousands, particularly via the forty Inventive Principles and the contradiction matrix that map technical contradictions to the principles that historically resolved them.

The reason TRIZ matters in a dependency-failure situation is that some failures create a genuine contradiction — an apparent need to have two things that exclude each other. The team needs the capability the failed dependency provided, and they cannot afford the cost of providing it themselves. Normal logic is stuck. TRIZ exists specifically for problems where obvious solutions have been exhausted.

The unique insight is that recurring inventive solutions follow patterns, and those patterns can be looked up rather than reinvented from scratch. The forty principles are crude in isolation — segmentation, asymmetry, dynamics, preliminary action — and powerful in aggregate, because they prompt the team to consider categories of solution they would not otherwise have surfaced.

What you get is a structured way to break out of stuck thinking when the obvious solutions are exhausted. The framework forces consideration of inversion, decomposition, and substitution moves the team would not normally try in panic.

So. How to use it as a fast diagnostic.

Name. What two things does the team need that appear to exclude each other? We need the capability of the failed supplier; we can't afford to build it ourselves; we don't have a like-for-like alternative.

Reach. Not all forty. Pick the ones whose names sound most relevant to the contradiction. Segmentation: can we get part of the capability from one source and part from another? Substitution: is there a different mechanism that produces the same outcome? Preliminary action: can we do something now that converts the future cost into a smaller present one?

Generate. Each principle is a prompt; you produce three or four options against it. Most are wrong; one or two are surprisingly viable.

Prototype. TRIZ outputs candidate solutions, not finished plans. The viable candidates need rapid prototyping to confirm they actually work in the team's context.

The framework is not a panacea. It is an unstuck-the-thinking tool, useful exactly when normal logic has been exhausted and panic is doing the team's reasoning.

A precedent: the entity that said no was not the whole market

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

The Lookery story we opened with showed a team whose dependency failed and who genuinely had no plan B — because the dependency was the whole platform. The story we close with is from a different century and a different scale, and it inverts the assumption that the entity that says no is the whole market.

Royaumont, France, December nineteen fourteen. The Scottish Women's Hospital opens its doors as a fully equipped one-hundred-bed all-female hospital unit, supporting the French Army through what will become five years of front-line medical work.

This is the second decision in the story. The first was made four months earlier, in a different country, by an institution that never expected to hear from the doctor who had asked.

August nineteen fourteen. Dr Elsie Inglis, fifty years old, a senior consultant in Edinburgh with thirty years of medical practice, offers the British War Office two fully equipped all-female hospital units of one hundred beds each, funded by the National Union of Women's Suffrage Societies. The reply is unambiguous. My good lady, go home and sit still.

The British dependency has failed the same day she has made the offer. There is no internal process by which the War Office's answer will be reversed on any reasonable timescale. The decision Inglis has to make, that month, is the decision the scenario plays out across.

She does not stay home. Within months, she has written letters to the ambassadors of the Allied nations — France, Belgium, Serbia, Russia — offering the same units on the same terms. France, Belgium, Serbia, and Russia accept what Britain has refused.

Royaumont opens in December nineteen fourteen. By the end of the war the Scottish Women's Hospitals have raised the equivalent of fifty million pounds in today's money and deployed fourteen hospital units across France, Belgium, Serbia, Russia, Romania, Corsica, Salonika, Malta, and Greece. The British medical establishment's refusal does not stop the hospitals from existing. It only determines which front they deploy on.

When a dependency fails and you need a plan B by tomorrow, the instinct is to treat the dependency's refusal as decisive. Inglis's move was to treat it as local. Britain was one potential buyer of the capability she had already built. There were several others, and the decision that took her from stalled to deployed was simply to ask them.

Plan B doesn't always require new capability. Sometimes it only requires that you notice the entity that said no was not, as you had been assuming, the whole market.

So. Your Next Move from this playbook.

What's the one external change that would invalidate your current strategy in six months — and what are you doing today as if it couldn't happen?