Options Before Optimization

By the end of this lesson, you will be able to...

• Tell the difference between a real alternative and a small variation of the first idea.

• Build an option set that includes a baseline, a learning move, and different commitment levels.

• Compare alternatives against explicit constraints without pretending that every option can be reduced to one score.

Idea in one sentence: Before optimizing a favorite plan, create a small set of genuinely different ways to move, learn, wait, or accept a risk.

Core Insight

Consider the checkout team from the previous lesson. After the outage, it wants a fix before the next campaign. The first proposal arrives quickly:

Buy a larger cache cluster.

It sounds practical. More capacity might absorb the traffic that overloaded the remaining zones. The provider can deliver the machines in three days. The budget is already open because the outage was expensive.

The team starts comparing cache sizes: 2 TB, 4 TB, or 8 TB. The discussion looks quantitative, so it feels like good decision work.

But the team has optimized one idea before asking a more basic question:

What different ways could we keep checkout available when capacity, zones, and campaign traffic interact?

The larger cluster may be useful. It is not yet a decision. It is one option inside a decision space.

The Naive Design: Make the First Idea Better

Optimizing the first idea is attractive for understandable reasons.

• The problem is urgent, so generating alternatives feels slow.
• The first proposal has an owner who can explain it.
• Numbers make a narrow comparison look rigorous.
• Teams fear that too many options will create indecision.

The hidden move is premature narrowing. The team treats “How large should the cache be?” as the problem before checking whether cache size is the main lever.

This creates a false binary: buy more capacity or keep the current system. It hides other mechanisms, such as reducing duplicate work, isolating failure, protecting the critical path, or buying time to learn.

The Promise We Need to Keep

Before creating options, state the decision frame. An option is only meaningful relative to a promise and its constraints.

For the checkout team:

The frame does not solve the decision. It prevents the team from comparing options that answer different questions.

Plain meaning:

An option is a distinct way to respond to the same decision frame.

In this scenario:

“A bigger cache” changes capacity. “A zone-aware failover path” changes how the system behaves when capacity is lost. They are different options because they change different parts of the mechanism.

Technical name:

Option generation is the deliberate creation of alternative actions before selecting or optimizing one.

What Counts as a Real Option?

Real options differ in at least one important dimension:

• mechanism: what changes in the system;
• commitment: how hard the choice is to reverse;
• timing: whether we act now, learn first, or wait;
• exposure: which failure or cost the option accepts;
• promise: which user or business outcome it protects.

These are not all equally good. They are different enough to make comparison useful.

By contrast, “buy a 4 TB cache” and “buy a 6 TB cache” may be variants inside one option. Variants become useful after the team has decided that capacity is the right mechanism.

Do not confuse option generation with endless brainstorming. A small, deliberate set is enough. The purpose is to escape a narrow frame, not to list every imaginable future.

Build the Option Set

The team creates five alternatives.

Option A: Increase cache capacity

Add a larger cache cluster and keep the current failover behavior.

• Fast to procure.
• Familiar operational model.
• Higher monthly cost.
• Does not directly address correlated overload after a zone loss.

Option B: Add zone-aware failover and warm capacity

Keep capacity near its current level, but reserve warm capacity in another zone and rehearse the failover path.

• Directly addresses the incident mechanism.
• Requires infrastructure work and a failure rehearsal.
• May expose other hidden dependencies.
• Costs engineering time before the campaign.

Option C: Reduce cache pressure

Add request coalescing so identical misses share one origin request, shorten the hot-key set, and place a limit on expensive recomputation.

• Reduces duplicate work.
• May increase latency for some cold requests.
• Does not protect every path during a zone loss.
• Gives the team a measurable mechanism to test.

Option D: Protect the critical checkout path

Move recommendations and other noncritical work out of the payment path. During overload, checkout continues with a simpler experience.

• Protects the user promise that matters most.
• Creates a degraded mode that users may notice.
• Requires clear ownership of what can be dropped safely.

Option E: Run a learning experiment before a full commitment

Replay campaign traffic, inject a zone failure in a controlled environment, and run a 1% production canary with explicit stop conditions.

• Improves information before a larger change.
• Does not remove the risk by itself.
• Uses part of the two-week window.
• May be the best next move if the team cannot distinguish capacity from correlated load.

The status quo and delaying the campaign are also options, even when nobody wants to say so. Hiding them makes the cost of delay disappear. A serious decision records what happens if the team changes nothing.

A Worked Design Review

The team now compares the options against the frame, not against a favorite.

The table does not produce a magic winner. It makes the trade-offs visible.

Suppose the campaign is in two weeks and the team cannot safely rehearse failover in production. A reasonable next decision might combine E and C: run the failure replay while reducing duplicate cache work. If the replay shows that zone loss still threatens payment, D becomes the fallback boundary. A may still be added later if the measurements show a real capacity shortage.

This is not indecision. It is a sequence with different commitment levels:

1. Learn about the mechanism.
2. Reduce a known source of pressure.
3. Define a degraded mode for the critical promise.
4. Commit to more capacity only if the evidence supports it.

The team has not optimized the original suggestion. It has designed a path through uncertainty.

Check: The team changes the cache from 4 TB to 6 TB and then to 8 TB without testing failover. How many fundamentally different options has it reviewed?

Think first, then reveal.

Answer: Probably one: increase cache capacity. The sizes are variants of one mechanism. They do not test whether failure isolation, duplicate work, degraded mode, or better information would address the real pressure.

Separate Generating From Selecting

Option generation and option selection need different moments.

During generation, ask:

• What mechanism could change the outcome?
• What would we do if we could not use the first proposal?
• Can we learn before committing?
• What would “do nothing” or “delay” look like?

During selection, ask:

• Which options satisfy the non-negotiable constraints?
• Which option protects the most important promise?
• What cost or risk are we accepting?
• What evidence would change the ranking?

If the team scores while it is still generating, the first attractive option receives an unfair advantage. Every new idea is compared with a polished favorite rather than with an equally clear alternative.

This separation also protects dissent. A person can propose a strange option without having to defend it as the final answer immediately.

What This Changes

Before this lesson, the team might ask:

How do we optimize the larger cache?

After this lesson, it can ask:

Which options change capacity, failure behavior, pressure, user experience, or our information—and which sequence fits the deadline and the promise?

The question becomes easier to review later. If the chosen path fails, the team can identify whether it selected the wrong mechanism, underestimated a cost, executed poorly, or learned too little before committing.

Check: A team has one week, a strict safety constraint, and no reliable way to test a new vendor. Which option category deserves explicit attention?

Think first, then reveal.

Answer: A learning option and a reversible fallback deserve attention. The team should not treat “choose vendor X” and “choose vendor Y” as the only choices if a small parallel test, a staged migration, or a delay is possible.

Trade-offs and Limits

The central trade-off is between option breadth and decision speed. More alternatives can expose a better mechanism, but they also cost attention, analysis, and coordination.

Option generation helps when the first frame is narrow, the stakes are meaningful, or the choice is hard to reverse. It costs time when the decision is cheap and reversible. A five-minute choice does not need a twenty-page option catalogue.

More options can also create avoidance. A team may keep generating alternatives because committing feels uncomfortable. The signal is that new options no longer change the decision frame or reveal a meaningful mechanism.

Option generation does not remove uncertainty. It does not prove that the best option is present. It does not settle values or probabilities; later lessons make those dimensions more explicit. It gives the team a fairer set of actions to compare.

Use a stopping rule:

Stop generating when the set contains a baseline, a meaningful change to the mechanism, a way to learn, and the main reversible or protective alternative—and when new ideas are only cosmetic variations.

Common Confusions

Confusion: More options always mean better decisions

Why it is tempting: missing an alternative feels dangerous.

Better model: a small, mechanism-diverse set is useful. A large list can hide the constraints and delay action.

Confusion: A pilot is not an option because it is not the final solution

Why it is tempting: people treat “option” as a permanent commitment.

Better model: learning, mitigation, delay, and commitment can all be options when they answer the same decision frame.

Confusion: Two numbers are two strategies

Why it is tempting: numerical differences look precise.

Better model: 4 TB and 6 TB may be parameter choices within one capacity strategy. A real alternative changes the mechanism, exposure, timing, or promise.

Confusion: Choosing a baseline means doing nothing thoughtlessly

Why it is tempting: teams prefer active plans.

Better model: the baseline makes the cost of changing visible. “Do nothing” is still an action with risks, benefits, and a time horizon.

Practice: Create Options for a Data Migration

A team must move an event store to reduce cost. The current store is reliable but expensive. A cheaper store passes functional tests, but its recovery time under a regional outage is unknown. The migration deadline is six weeks. The team first proposes a full cutover next Friday.

Create a decision frame with one promise and three constraints. Then produce at least five options, including:

• the baseline;
• a direct commitment;
• a reversible or parallel path;
• a learning experiment;
• a way to protect the critical user or business promise if the migration fails.

For each option, name its mechanism, commitment level, main trade-off, and the evidence that would change your ranking.

A good answer should show genuine differences in mechanism or timing. It should not be five versions of “migrate more carefully.”

Connection to the Next Lesson

Once a team has real alternatives, it faces a new problem: how confident should it be about each option's risks? The next lesson, Probability as Calibrated Belief, turns vague language such as “likely” or “low risk” into explicit estimates and update triggers.

Resources

• [BOOK] Thinking, Fast and Slow — Focus: how anchoring and premature closure distort judgment.
• [BOOK] How to Decide — Focus: separating option generation from decision evaluation and using decision trees without false certainty.
• [ARTICLE] Stanford Encyclopedia of Philosophy: Decision Theory — Focus: how acts, outcomes, preferences, and uncertain states enter a decision problem.

Key Takeaways

• An option is a distinct way to respond to one decision frame, not merely a new number inside the first idea.
• A useful option set includes a baseline, a meaningful mechanism change, a learning move, and a reversible or protective path.
• Generate before selecting so the first proposal does not receive an unfair advantage.
• The central trade-off is between option breadth and decision speed; use a stopping rule to avoid both premature narrowing and endless brainstorming.
• Options make uncertainty easier to act on, but they do not replace evidence, calibrated belief, or explicit values.