Execution Risk

Execution Risk is the probability that the work you authorized does not produce the Revenue, Cost Reduction, or Profit improvement you expected when you allocated resources to it.

Every build can fail to deliver. The critical insight for operators: Execution Risk is not independent across builds when those builds share inputs. Two builds that rely on the same team, the same infrastructure, or the same vendor have linked failure modes. A single disruption - a key engineer leaving, an operational crisis consuming all capacity, a vendor contract falling through - can cause both builds to fail simultaneously.

What does 'linked failure modes' mean precisely? It means the outcome of one build gives you information about the outcome of the other. If Build A fails because the shared team lost capacity, Build B is likely to fail for the same reason. The failures are not independent events - they are driven by the same underlying cause.

This follows the same intuition as diversification in Markowitz Portfolio Theory: two things that fail together provide no risk reduction, even if they look like separate bets. The analogy is directional rather than exact - more on this in the Connections section.

Operators care because linked failure modes create a counterintuitive risk structure that project plans do not capture.

Here is the key insight: linking failure modes does not change your Expected Value. E[A + B] = E[A] + E[B] regardless of whether the outcomes are linked or independent. If Build A has a 70% chance of delivering $500K and Build B has a 70% chance of delivering $500K, your combined Expected Value is $700K whether the builds share a team or not.

What changes is the spread of outcomes - specifically, the Tail Risk.

With independent failure modes, you get a range of outcomes: both succeed (49%), one succeeds and one fails (42%), both fail (9%). Most of the probability sits in partial success.

With fully linked failure modes and equal success probabilities, the middle outcomes vanish. You get: both succeed (70%) or both fail (30%). No partial outcomes.

The probability of catastrophic failure jumps from 9% to 30%. The partial-success scenarios that would have cushioned a bad quarter disappear entirely.

The Operating Statement does not care about your Expected Value. It records the single outcome that actually happened. If linked failure modes take out two builds instead of one, you just have a bigger miss. And if your Budget cannot absorb that miss, the plan was unacceptable from the start.

Linked failure modes come from shared inputs. The main sources:

1. 1)Shared Labor - The most common. One team splitting time across two builds means the same Bottleneck (people) constrains both. If that team loses capacity - a key engineer leaving, an illness, a reassignment - both builds slow or stop.

2. 2)Shared critical path - Two builds that depend on the same infrastructure migration, the same vendor delivery, or the same regulatory approval. If the dependency slips, both slip.

3. 3)Capacity loss from splitting focus - Even without a disruption, splitting a team across two builds introduces overhead. Each build moves slower than if the team were focused on one, which increases the probability both miss their milestones.

How to estimate the degree of linkage:

Use Sensitivity Analysis across three scenarios:

• •Independent (best case): P(both fail) = P(A fails) x P(B fails). Use this when builds have completely separate teams and no shared dependencies.
• •Fully linked (worst case): P(both fail) = the lower of the two individual failure probabilities. Why the lower? Both builds can only fail together as often as the less-failure-prone build fails. If Build A fails 25% of the time and Build B only fails 20% of the time, both cannot fail together more than 20% of the time - there are not enough Build B failures to pair with all of Build A's failures.
• •Your best estimate: Somewhere between the two extremes, based on how much of the failure mode surface is shared.

A starting heuristic for your best estimate: look at the fraction of total Labor hours from shared people. If 40% of Labor is shared, place your P(both fail) estimate roughly 40% of the distance from the independent case to the fully linked case.

Critical caveat: This heuristic measures capacity overlap, not knowledge overlap. A single person who holds all the Tribal Knowledge for both builds can create near-total linkage even at a small fraction of total Labor hours. The hook at the top of this lesson is exactly this case - one tech lead leaving linked two projects that shared a third of their team by Labor hours but nearly all of their critical knowledge. Weight your estimate toward the knowledge risk, not just the hours ratio.

Reducing linkage between failure modes:

• •Sequence instead of parallelize. Run Build A to completion, then Build B. You lose calendar time but the builds have independent failure modes. This is an investment sequencing decision.
• •Staff independently. If you can afford it, put separate teams on each build. The builds now have independent Execution Risk.
• •Isolate the shared dependency. If both builds need a database migration, finish the migration first as its own phase with its own milestones and Exit Criteria before either build begins.

Explicitly model linked Execution Risk when:

• •You are allocating the same team to multiple builds in the same Time Horizon. Before committing, ask: if this team loses 30% of its capacity, what happens to each build?

• •Your plan depends on two or more bets paying off in the same quarter. If your Budget assumes $1M in combined Revenue from two new features and both features share a team, run Sensitivity Analysis on the scenario where both miss simultaneously. The probability of that scenario is higher than the product of individual failure rates when the failure modes are linked.

• •You are presenting a plan to a CFO or board. Decision-makers with capital discipline will ask about downside scenarios. Showing that you have modeled linked failure modes - and mitigated them through sequencing or independent staffing - separates a credible plan from a wish list.

• •You are doing Sensitivity Analysis on a resource allocation plan. Vary not just the success probability of each build, but the probability that multiple builds fail together. If the linked-failure scenario produces an unacceptable P&L outcome, restructure the plan before you start.

Execution Risk builds directly on your two prerequisites. Execution taught you that the only work that counts is work that changes the P&L. Execution Risk quantifies how likely your planned Execution is to actually produce that change. Resource allocation taught you to distribute finite inputs where they create the most marginal value. Execution Risk adds a crucial constraint: when you allocate the same input (especially Labor) to multiple builds, you do not just split capacity - you create linked failure modes that can wipe out the value of both allocations simultaneously.

Downstream, this connects to Portfolio Construction and Capital Allocation decisions. Markowitz Portfolio Theory provides a useful but imprecise analogy. Markowitz concerns Return Distribution, Volatility, and how investments move together across continuous outcomes. Execution Risk works with binary outcomes (succeed or fail) and shared causes. The structural lesson transfers: diversification only reduces risk when the underlying bets can move independently. But the mechanics differ, so treat this as intuition, not a formal mapping. The operating implication is the same either way: Operators who understand linked failure modes make better resource allocation decisions. They sequence when they cannot staff independently, they isolate shared dependencies into phases with their own milestones and Exit Criteria, and they present honest Tail Risk scenarios instead of treating every build as an independent bet.