Business Systems
Black Swan Events: Build a Business That Does Not Need to Predict Them
On an ordinary Tuesday, a business often looks more knowable than it is. Orders arrive, systems run, the calendar fills, and last month’s numbers can be turned into a forecast.
On an ordinary Tuesday, a business often looks more knowable than it is. Orders arrive, systems run, the calendar fills, and last month’s numbers can be turned into a forecast. Then an event exposes a dependency everyone had treated as background: a supplier stops operating, a platform changes its rules, a key person becomes unavailable, a payment provider freezes an account, a regulation changes, or a public-health emergency changes what customers can do.
The uncomfortable fact is that the next consequential disruption may not look like the last one. That is the point behind the phrase “Black Swan,” popularised by Nassim Nicholas Taleb: rare, high-impact events are often made to look more predictable in hindsight than they were beforehand. The phrase is frequently used as a dramatic label for anything surprising. Used carefully, it is a warning against overconfidence in forecasts—not a reason to give up planning.
No business can make itself safe from every shock. No article can promise resilience, protection or a positive result. But an organisation can make fewer decisions that depend on one confident prediction being right. It can reduce fragile dependencies, keep options visible, set sensible limits on loss, and build a habit of noticing when its model of reality is too neat.
The reader’s immediate decision is not “What catastrophe should I predict?” It is: where would one wrong assumption make my next month much harder than it needs to be? That question is less dramatic and far more actionable.
Start with the decision in front of you
Imagine a small service business with a full calendar. It uses one online booking tool, one payment processor, one person who knows how the work is delivered, and one marketing channel that produces most enquiries. None of those facts is automatically a problem. Specialisation can be efficient. The problem begins when the owner calls the arrangement “stable” simply because it has worked recently.
Now change one condition. The booking service has an outage. The payment processor asks for more verification. The key person has a family emergency. The marketing channel changes its ranking system. The business might continue without much difficulty—or it might discover that a routine dependency was actually a single point of failure. The value of this scenario is not that it predicts an event. It reveals the shape of a consequence.
That is a better starting point for uncertainty work. Forecasts ask what will happen and when. Preparedness asks what matters if a condition changes. Both can be useful, but they do different jobs. Weather forecasts can help plan an outdoor event; they do not settle whether the business has a backup communication method. Market research can inform a launch; it cannot guarantee that a supplier, customer or platform will behave as the spreadsheet assumes.
The Black Swan idea belongs to the second job. It cautions us about a tendency to draw a smooth line from incomplete history. We give familiar data more authority than it deserves, ignore what was not measured, and then explain a shock after it occurs as if it were obvious. Taleb’s broader work argues that forecasting errors are especially dangerous when outcomes have very unequal consequences: one large loss can dominate many small gains.
You do not need to adopt every part of Taleb’s philosophy to use this warning. Start with a plain operational question: if one assumption fails, can we still contact customers, deliver our core promise, pay essential obligations, protect data, and make a decision without panic? If the honest answer is no, the next step is not prediction. It is to inspect the dependency.
What the evidence can and cannot tell you
The term “Black Swan” comes from a historical surprise: Europeans once used the apparent absence of black swans as an example of impossibility, until Dutch explorers documented black swans in Western Australia. Taleb uses the image to discuss events that are outliers relative to ordinary expectations, have major impact, and invite retrospective explanations. His book The Black Swan is a primary source for his definition, though readers should remember it is an argument about uncertainty, not a universally accepted operating manual.
Research and public guidance on risk management support a related but more practical observation: organisations benefit from identifying objectives, uncertainties, controls and review processes. ISO 31000 describes risk management as a framework for creating and protecting value, and the U.S. National Institute of Standards and Technology provides public frameworks for managing cybersecurity risk. These sources do not promise that risk programmes prevent loss. They describe structured ways to recognise and respond to uncertainty.
Public evidence also shows why precision deserves humility. Events such as the COVID-19 pandemic had widespread effects on public life and business activity, but the impacts were uneven. Some organisations faced immediate closure; others shifted work, demand or channels; many outcomes depended on local rules, resources, sector and timing. Saying “a pandemic was a Black Swan for every business” is too simple. Saying “recent disruption proves we can predict the next one” is equally weak.
Evidence can help you map known exposures. Contracts can reveal notice periods. System records can identify who has administrative access. Finance records can show when cash is received and which commitments cannot be delayed. Customer feedback can show where a service depends on one person. Incident reports can reveal recurrent failure modes. These are concrete sources, and they should drive most preparation work.
Evidence cannot produce certainty about the unknown. A risk register can become a catalogue of familiar worries while leaving the organisation blind to interactions it has never considered. A scenario plan can be persuasive without being probable. A checklist can give a false sense that every relevant box has been ticked. That is why good uncertainty practice combines known-risk controls with humility about what is missing.
For consequential choices—insurance, credit, investment, employment, legal compliance, medical safety or emergency response—this article is not specialist advice. Use qualified professional and jurisdiction-specific guidance where required. The purpose here is narrower: help you make a first operational diagnosis of fragility before an avoidable dependency becomes an emergency.
The distinction that changes the next move
The central distinction is between predicting a shock and reducing fragility to a shock.
Predicting asks for a story about the future. It can be useful when the evidence is strong enough: a contract ends on a date, a seasonal pattern is clear, a law has been enacted with a known commencement date. But prediction becomes dangerous when it is smuggled into decisions that cannot tolerate being wrong. “This provider will always be available,” “demand will remain steady,” or “one skilled person will not leave” are not forecasts in a rigorous sense. They are dependencies wearing the costume of confidence.
Reducing fragility asks a different set of questions. What fails first? How concentrated is the dependence? How quickly would we notice? What can continue in a smaller, slower or simpler form? What would be costly or impossible to restore if we waited? The aim is not to eliminate all dependence. It is to choose dependencies whose failure you can survive and to know when you cannot.
Consider cash. A forecast may estimate income for the next quarter. Fragility analysis asks how long essential obligations can be met if receipts arrive later than expected, whether all cash is held in one place, what commitments are reversible, and who can see the current position. This does not promise solvency. It makes the downside visible early enough for a decision.
Consider technology. A forecast may assume that a software provider will keep serving a useful function. Fragility analysis asks whether data can be exported, who controls administrator access, whether recovery information is current, what happens during an outage, and which parts of the service can be performed manually for a short period. The result may be a backup, a documented procedure, a second contact or an acceptance that no practical fallback exists. Each is better than discovering the dependency while customers wait.
Consider people. A forecast may assume a key employee or contractor remains available. Fragility analysis asks whether critical knowledge is documented, whether another person can perform the minimum safe task, what authority is needed to make decisions, and how work is prioritised if capacity drops suddenly. This is not a case for treating people as replaceable. It is a way to stop a business from making one person carry an impossible hidden risk.
This distinction changes the emotional tone as well. Prediction can reward dramatic certainty. Fragility work is often mundane: export a file, review a contract, clarify a responsibility, set a limit, rehearse a customer message. Its value is not that it makes an organisation feel invulnerable. Its value is that it preserves choice under pressure.
There is an important financial version of the same distinction. A business may be profitable on paper and still be fragile if it cannot meet obligations while waiting for expected cash, if a single dispute can halt essential payments, or if it has accepted commitments that can only be honoured under unusually favourable conditions. This is not a recommendation about reserves, borrowing, investments or insurance; appropriate choices depend on facts, jurisdiction and qualified advice. It is a prompt to identify the timing and concentration assumptions that a financial forecast can hide.
Likewise, resilience should not be confused with self-sufficiency. Most organisations rely on other people and systems. The objective is not to own every dependency or to distrust partners. It is to understand which relationships are essential, communicate honestly with them, and avoid arrangements in which one routine change leaves no workable response. In many cases the best control is a better relationship, a clearer contract or a mutual understanding of what happens during a disruption.
A practical way to test your interpretation
Use a one-hour fragility review on one real part of the business. Do not begin with every imaginable disaster. Begin with a process that matters next week: taking payment, delivering work, receiving orders, maintaining customer communication, protecting a critical record, or approving expenses.
First, state the minimum service. If normal operations became impossible for seven days, what is the smallest honest version of the promise you would still try to keep? A retailer may need to tell customers what orders can still be fulfilled. A consultant may need a way to contact active clients and secure their files. A software team may need to preserve access to production systems and communicate incident status. “Keep everything running” is not a minimum service; it is a wish.
Second, draw the dependency chain in plain language. For each minimum service, list people, suppliers, software, data, permissions, premises, money and decisions it relies on. Then mark dependencies that are singular: one person with a password, one account holding essential data, one supplier with no alternative, one customer whose late payment changes everything. The map does not need to be elegant. Its purpose is to make hidden concentration discussable.
Third, ask four consequence questions for each singular dependency:
- If it fails, what is the first visible effect?
- How long before a customer, colleague or regulator notices?
- What can we do manually, more slowly or at reduced scope?
- What information or authority would we wish we had preserved?
Fourth, choose one control matched to the consequence. A control is not necessarily a second vendor. It might be documented access, a tested export, a simple communication template, a clear spending limit, a second approver, a modest reserve, a contractual review, an offline contact list or a scheduled check that an essential account is still accessible. Avoid controls that sound impressive but cannot be maintained.
Fifth, define a trigger and owner. A plan without a trigger becomes a document people discover too late. Write what causes the action (“provider outage exceeds two hours,” “cash balance reaches the agreed threshold,” “the only administrator is unavailable”) and who is authorised to act. Keep the first action small and specific: send the agreed customer update, move to the documented manual process, pause non-essential spending, call the named supplier contact.
Sixth, test one ordinary failure. Open the export. Check whether the recovery contact works. Ask a second person to locate the procedure. Draft the customer message before you need it. A test may uncover that the supposed backup is stale, inaccessible or too complex. That is useful information. It is not a reason to make a grand claim about resilience.
Finally, record what you do not know. Perhaps you cannot estimate the cost of a prolonged outage, do not know whether a contract permits a necessary change, or lack expertise about data protection. Name the uncertainty and route it to the appropriate person. The aim is not a perfect risk register. It is a clearer next decision.
Make the review proportionate
Not every dependency needs the same treatment. A missed optional newsletter can be inconvenient; a failed payroll process, inaccessible safety information or loss of a legally required record may demand a different standard. Ranking consequence is not about creating a frightening spreadsheet. It is a way to put limited attention where delay, harm or irreversible loss would matter most.
One simple approach is to describe consequence in words before assigning numbers. “Annoying but recoverable within a day,” “costly but manageable with customer communication,” “stops the minimum service,” and “may require immediate specialist or regulatory advice” are clearer than precision that no one believes. The descriptions can then guide the scale of the response. A low-consequence dependency may need only a note. A high-consequence one may need an owner, current evidence and a tested procedure.
The review should also respect the cost of controls. Maintaining two systems, holding extra stock, documenting access, or training a second person all consume time and money. A control that exhausts the team can create a new weakness. Ask whether it can be kept current during ordinary work. If not, narrow it until it can. A small backup process that is actually used is more meaningful than a comprehensive continuity plan that only exists at audit time.
Distinguish a trigger from an alarm
An alarm tells you something may be wrong. A trigger tells you it is time to take a pre-agreed action. The difference can prevent two common failures: acting impulsively on noise, or debating too long after the condition has clearly changed. For example, a single late payment may prompt a check; a stated threshold of overdue receivables may trigger a pause on discretionary spending or a conversation with a qualified adviser. The exact threshold is context-specific, but the principle is portable.
Triggers should be revisited after use. If a threshold generated panic despite being too sensitive, or failed to surface a growing problem, change it. This is not evidence that the exercise failed. It is evidence that the organisation learned something about its own timing. Preparation gets better through revision, not through pretending the first rule was timeless.
A small example, labelled as hypothetical
Imagine a hypothetical studio that receives nearly all work through one online marketplace. The owner notices that the marketplace account, portfolio images and customer conversations are central to next month’s income. The studio cannot predict whether the marketplace will change its terms. It can, however, keep a current local portfolio, maintain permission-based contact details for existing clients, understand payout timing, and avoid promising a delivery schedule it cannot meet during an account dispute.
None of these steps guarantees income or prevents a platform change. They reduce the number of essential things that disappear at once. That is a more honest objective than “making the business Black Swan-proof.”
Common mistakes that create false certainty
The first mistake is treating every surprise as a Black Swan. Some disruptions are foreseeable but neglected: a certificate expiry, a single expiring contract, a known seasonal cash gap, an unsupported system, or a person repeatedly carrying work without documentation. Calling these events unknowable can become an excuse not to do ordinary maintenance.
The second mistake is turning scenario planning into prediction theatre. Teams can spend days debating whether a particular event has a 12% or 18% chance of happening when the real issue is that either event would expose the same dependency. Use scenarios to reveal consequences and choices, not to display false numerical precision.
The third mistake is confusing redundancy with resilience. Two suppliers may share the same region, infrastructure or financial weakness. Multiple copies of a file are not useful if no one can restore them. A second person is not a fallback if they lack authority, training or time. Redundancy helps only when it changes the failure mode you care about.
The fourth is buying complexity instead of reducing fragility. A new dashboard, insurance product, consultant or software subscription may be appropriate, but none is automatically a control. Ask what failure it addresses, what it costs to maintain, and how you would know it is working. A smaller, maintained practice can be safer than an elaborate plan no one can use.
The fifth is using the language of uncertainty to avoid making decisions. “Anything can happen” is true but not useful. It can justify paralysis, hoarding resources or refusing commitments that matter to customers and staff. Responsible preparation is proportionate: protect what is difficult to replace, preserve options where the cost is reasonable, and make a decision when delay itself has a cost.
The sixth is promising immunity. Businesses are embedded in economies, communities, laws and natural systems. A disruption can hurt even a well-prepared organisation. The ethical claim is not “we are protected.” It is “we understand some dependencies, have chosen limited actions, and will update our response as evidence changes.”
The seventh is ignoring the human side of a disruption. During uncertainty, people need accurate information, a way to raise problems and permission to state what they do not know. Overconfident messaging can damage trust when circumstances change. Clear uncertainty is not panic: “Here is what we know, what we are doing now, what may change, and when we will update you” is often more useful than a promise no one can keep.
An eighth mistake is assuming that a plan is shared because it was stored somewhere. When people are busy, they search for the shortest reliable path. If an emergency procedure requires them to remember a hidden folder, interpret old terminology and obtain approval from an unavailable person, it may not exist in practical terms. Keep critical instructions short, current and reachable by the people who would use them. Test access without waiting for a crisis.
A ninth is making risk work punitive. If raising a dependency is treated as pessimism or incompetence, staff and partners learn to conceal weak signals. The organisation then receives fewer warnings and congratulates itself on calm. Leaders can change this by responding to a reported weakness with curiosity: what is the consequence, what evidence do we have, what is the smallest safe next step, and who needs to know? This is not softness. It is how information reaches a decision before it becomes damage.
Choose the smallest responsible next step
Choose one service you must be able to deliver or one obligation you must be able to meet next week. Write its minimum version. List the three dependencies whose absence would stop it. For each, identify one action that either preserves an option, shortens detection time or makes the first response clearer. Put an owner and a review date beside the action.
If the review reveals a material exposure involving money, employment, law, health, safety, data protection or contractual obligations, do not use generic online advice as a substitute for qualified guidance. Bring the specific facts to the appropriate adviser or authority. The useful result of this exercise may be the recognition that the decision needs expertise.
Do this once before expanding the work. The purpose is not to build a fear-driven operating system. It is to learn whether your normal success depends on a hidden assumption. A small correction—a second access holder, a verified export, a clearer invoice schedule, a documented handover—can make a future decision less desperate without pretending to know the future.
After the first review, set a modest rhythm rather than launching a permanent emergency programme. Revisit the chosen dependency after a supplier change, staff change, material growth, a real incident or a fixed interval that suits the work. Remove controls that no longer fit, update the facts that changed and keep the record brief enough that someone will read it. The measure of usefulness is not the size of the file. It is whether people can make a calmer, better-informed choice when normal conditions stop.
You may find that the right next action is to accept a risk. That can be a sound decision when the consequence is limited, alternatives are disproportionate and the acceptance is explicit. What matters is that acceptance is a decision with an owner, not an assumption buried in routine. Naming it makes future review possible and prevents a later shock from being explained away as something nobody could have considered.
What a useful record looks like
A useful record of this work can fit on one page. It names the minimum service, the dependency, the consequence, the first action, the owner, the evidence last checked and the next review date. It also names the limit: perhaps the business cannot guarantee delivery during a regional outage, cannot independently assess a legal obligation, or cannot prevent a supplier from changing its terms. Limits do not weaken the record. They prevent it from becoming a misleading promise.
Write the record so that a colleague unfamiliar with the project can understand it. Avoid cryptic acronyms and explanations that depend on one person’s memory. Include where critical information lives, but do not place passwords or sensitive data in a broadly shared document. Access controls, data protection requirements and incident handling should be designed with the appropriate internal owners or qualified specialists, especially where personal data or regulated activities are involved.
The record should be a prompt for action, not a substitute for judgment. In a live incident, new facts may make the planned response unsuitable. The owner needs authority to adapt, communicate the change and request help. A plan that forbids all judgment can be as brittle as no plan at all.
Learn from near-misses without inventing certainty
Not every useful lesson arrives as a crisis. A delayed invoice, a short outage, an unavailable colleague or a confusing customer question can reveal a dependency at low cost. Treat these near-misses as evidence. Ask what failed, what still worked, which improvisation helped, and whether the improvement should become ordinary practice. Avoid turning the discussion into blame or a retrospective claim that someone should have known everything.
Near-miss review also corrects a common bias: successful improvisation can make an organisation feel safer than it is. Perhaps a person solved the problem because they happened to be available, a supplier made an exception, or a customer was unusually patient. Be grateful for the recovery while distinguishing it from a dependable control. The right conclusion may be simply that the weakness remains and deserves a small follow-up.
When not to do this alone
Some exposures require more than an internal review. A suspected data breach, a safety incident, a significant legal duty, a threat to a person, or financial distress can create obligations that depend on jurisdiction and facts. In those situations, preserve relevant information, avoid unsupported public claims, and seek qualified professional or official guidance promptly. The value of a fragility review is that it can help you recognise this boundary sooner; it does not replace the expertise needed beyond it.
The same restraint applies to public communication. Do not promise continuity you have not verified, speculate about causes, or turn an uncertain event into a marketing opportunity. Say what is known, what is being done, and when a further update will be available. Honest limits preserve options better than invented certainty.
This is a form of preparation that remains valuable even when no major disruption occurs. It clarifies ownership, improves routine handovers and makes ordinary promises more credible. Those are worthwhile outcomes on their own; no catastrophe is required to justify the attention.
Black Swan language is most useful when it makes us less impressed by our stories. You cannot prepare for every event, and you should not promise that your business will survive any shock. You can decide not to make basic continuity depend on a single untested assumption. That is not prediction. It is a modest form of care for customers, colleagues and the work you have promised to do.
