When Pressure Hits, Your Operating Model Behaves Like a Dog Chasing a Squirrel

Estimated reading time: 8 minutes

For CEOs/COOs and commerce leaders who want execution speed without chaos—this shows how to design decision governance that holds under launch pressure.

In commerce transformations, governance shows up when pressure hits: promo dates slip, inventory is wrong, an executive asks for “just one exception,” and teams start improvising. If decisions don’t have an owner, a pathway, and a feedback loop, the operating model behaves like a dog chasing a squirrel—fast, committed, and messy. The fix isn’t more meetings. It’s minimum viable decision design: name one accountable owner per recurring decision (pricing overrides, promo exceptions, fulfillment trade-offs, AI use cases); set a decision pathway with inputs and a decision SLA; and attach a “did it work?” checkpoint that updates the guardrails. Run a weekly decision docket so decisions move, not debates. Governance isn’t bureaucracy. It’s how you keep momentum without spilling the coffee.

---

The squirrel moment during a commerce launch

It’s Tuesday. Steering committee in 30 minutes.

Your promo calendar is slipping because inventory landed late.
Customer service is asking for “free expedited shipping” to avoid a blow-up on social.
Merch wants a pricing override “just for this category.”
IT says the OMS can’t support the split-ship logic the business promised.

Then someone says the line that always triggers chaos:

“Can we make an exception? Just this once.”

That’s the squirrel.

In my case, it was Romeo—the 0.2-second decision machine.
Full commitment. Zero alignment. No rollback plan.
Two minutes later: tangled leash, coffee on the ground, apology tour.

Most commerce organizations don’t fail because they lack strategy.
They fail because pressure exposes decisions that don’t have owners, pathways, and feedback loops.

What decision governance is (and what it is not)

Decision governance is the operating system that ensures decisions have a clear owner, a defined route to “done,” and a mechanism to learn and adjust.

It is not:

• A steering committee that “reviews” everything.
• A RACI poster no one uses.
• A weekly status meeting disguised as “alignment.”
• An approval culture where decisions go to the highest-paid person in the room.

If you can’t answer “who decides, by when, with what inputs, and what happens after,” you don’t have governance. You have meetings.

HBR’s classic “Who Has the D?” makes the same point in plain language: clarity on decision roles and ownership is what makes organizations more decisive and improves execution.

The failure pattern: fast movement, wrong direction

In commerce transformations, unclear decision governance produces a predictable set of symptoms:

1) Exceptions multiply

Pricing overrides. Promo deviations. Service “save” offers.
Workarounds get normalized—then baked into the operating cost.

2) The backlog thrashes

Teams build, pause, rebuild.
A “simple change” becomes a cross-functional negotiation.

3) Local optimization wins

Merch optimizes conversion.
Supply chain optimizes cost.
Customer service optimizes containment.
Everyone hits their local KPI while the end-to-end economics degrade.

4) Decisions become debates

If a topic comes back week after week, it’s not “complex.”
It’s undecided.

McKinsey’s survey work also points to the hidden cost: decision making consumes a large share of executive time, and much of it is used ineffectively—especially when roles and pathways are unclear.

Commerce transformations fail in three decision zones

If you want leverage, don’t map every decision. Map the recurring decision families that create most of the noise.

Zone A: Pricing and promotion exceptions

These decisions should not live in email threads.

Examples:

• Price overrides below margin floor
• Promo stacking rules
• Coupon eligibility exceptions
• Price-match rules and enforcement
• “One-time” deals for strategic accounts

Without guardrails, every exception becomes a precedent.

Zone B: Fulfillment and service trade-offs

This is where “customer promise” collides with operational reality.

Examples:

• Split shipments vs consolidated
• Substitutions
• Backorder policy
• Expedited shipping exceptions
• Return policy exceptions

These decisions are rarely “strategic.” They are operational policy—and they must be fast.

Zone C: Digital experience and platform change decisions

This is where product teams drown in “alignment.”

Examples:

• Release scope trade-offs
• Experience standards vs local optimization
• Product data quality thresholds (PIM/PXM rules)
• Search and merchandising rules
• AI use cases in customer-facing journeys

When this zone has no pathway, teams ship half-decisions and call it agility.

Minimum viable governance: Owner + Pathway + Feedback loop

If your governance model can’t fit on one page, it won’t survive pressure.

Here’s the minimum viable version that works in commerce.

Decision rights: define ownership, not roles

Rule: One decision = one accountable owner.

Not “Marketing + Merch + Finance.”
Not “The committee.”
One name.

This is exactly what “Who Has the D?” advocates: clarify who holds the decision and who provides input, so decisions don’t stall in ambiguity.

Practical move: build a Decision Register with 10–15 recurring decisions.
For each decision, capture:

• Decision name (e.g., “promo stacking exception”)
• Accountable owner (one person)
• Required inputs (finance, legal, ops, etc.)
• Guardrails (non-negotiables)
• SLA (48h / 5d / 2w)
• Escalation path (only when guardrails are breached)

If the owner can’t be named, you’ve found a governance hole—not a people problem.

Decision pathway: make decisions move at the right altitude

A decision pathway is the defined route a decision takes from issue → input → decision → execution.

Use three altitudes:

• Team level: decisions inside guardrails (fast, frequent)
• Domain level: cross-functional trade-offs (weekly)
• Exec level: policy changes, risk exceptions, investment calls (as needed, but decisive)

Add a simple rule:

• If it can’t move in the pathway within the SLA, it’s not a decision. It’s a debate.

McKinsey’s research argues that speed and quality are not mutually exclusive; fast decision environments are also more likely to report high-quality decisions.

Feedback loop: no checkpoint means you train chaos

Every big decision needs a “did it work?” checkpoint.

Not six months later.
Not buried in a QBR deck.

A checkpoint is a short review tied to the outcome the decision was supposed to achieve:

• Margin impact (including leakage)
• Conversion impact
• Service cost impact
• Promise adherence (delivery SLA, return cycle time)
• Exception rate after the change

If you don’t review outcomes, the org learns the wrong lesson:
“Exceptions are how we get things done.”

A simple model you can install: the weekly commerce decision docket

This is the lowest-effort mechanism I’ve seen that creates disproportionate clarity.

Weekly commerce decision docket (30 minutes):

• Pre-read only (one page per decision)
• Decisions only (no status updates)
• If it isn’t decision-ready, it doesn’t enter the docket
• Decisions recorded in the register with owner + SLA + next checkpoint

This is how you replace “alignment” with throughput.

The Squirrel Test checklist (run it in 15 minutes)

Use this when you feel pressure rising—launch week, peak season, incident, bad KPI trend.

1. Name the decision. If you can’t name it, you can’t govern it.
2. Name the owner (one person). If it’s “we,” it’s nobody.
3. Define the guardrails (3–5 rules). Margin floors, promise standards, risk thresholds.
4. Define the SLA. 48 hours / 5 days / 2 weeks.
5. List required inputs. Not attendees—inputs.
6. Choose the altitude. Team / domain / exec.
7. Define escalation. Only when guardrails are breached.
8. Define the checkpoint. What metric confirms it worked? When will you look?
9. Record it. If it’s not recorded, it didn’t happen.
10. Kill the zombie. If it’s been debated 3 times, force a decision or change the guardrail.

When this advice does NOT apply

There are real exceptions.

• True crisis mode (safety, security, legal exposure): you may need temporary command-and-control, with an explicit sunset date.
• Early discovery: when the “decision” is actually a hypothesis, use experiment governance (small bets, fast learning) rather than approval governance.
• Heavily regulated decisions: the pathway still matters, but constraints are tighter and documentation heavier.
• Very small teams: informal governance can work—until scale forces you to externalize it.

What to do this week (non-salesy, practical)

Pick one commerce domain (pricing/promo, fulfillment/service, or digital experience).

Then do this in 60–90 minutes:

1. List the top 10 recurring decisions creating noise.
2. Assign one accountable owner to each.
3. Set a default SLA for each decision family.
4. Write 3–5 guardrails for the domain (margin floors, promise rules, exception limits).
5. Start a weekly decision docket next week.
6. Add one checkpoint per big decision (2–4 weeks out).

Governance should feel like relief.
If it feels like more work, you built gates—not guardrails.

Suggested internal links:

• Governance category
• Operating Model category
• eCommerce category
• Strategy to Execution category

---

Facts that matter

• Clear decision ownership and roles improve decisiveness and organizational performance (HBR “Who Has the D?”, January 2006).
• McKinsey’s 2019 survey-based research argues that faster decision making correlates with higher reported decision quality (May 1, 2019).
• McKinsey notes that decision making consumes a large share of executive time and is often used ineffectively (Apr 30, 2019).
• A Bain survey of nearly 800 companies reported a very strong relationship between decision effectiveness and financial performance (2012; “Score your organization to improve decision effectiveness”).
• Margin leakage is commonly defined as profit reduction caused by price erosion and/or cost increases, often driven by preventable inefficiencies (NetSuite article, Feb 27, 2024).

---

FAQ

How do I know if we have a decision problem or a strategy problem?

If strategy is clear but the same topics resurface weekly, you have a decision problem. Strategy problems look like “we don’t know what we want.” Decision problems look like “we know what we want, but it never turns into a consistent call.” The giveaway is repeat debates, exception creep, and backlog thrash under pressure.

What’s the difference between guardrails and gates?

Guardrails are rules that let teams execute without asking permission (margin floors, promise standards, eligibility rules). Gates are approval steps that slow everything down. Guardrails increase autonomy and speed; gates increase escalation and politics. In commerce, guardrails keep exceptions rare—and intentional.

What decisions should be governed first in a commerce transformation?

Start with recurring decisions that create financial leakage and delivery churn: pricing overrides, promo exceptions, fulfillment trade-offs, and release scope changes. These generate the most noise because they cut across functions and collide with real-world constraints (inventory, capacity, customer promise).

Do we need a steering committee for this?

Not as the primary mechanism. Committees are often good at discussing and bad at deciding. What you need first is a decision register, decision owners, SLAs, and a weekly decision docket. Keep steering committees for policy shifts, major investments, and risk exceptions—where executive authority is actually required.

How do we keep decision governance from becoming bureaucracy?

Keep it small and measurable. Limit your decision register to the top 10–15 recurring decisions. Use one-page pre-reads. Enforce SLAs. Add checkpoints that prove whether decisions worked. If it doesn’t reduce cycle time, exceptions, or rework within 30 days, simplify it.

---

Glossary

• Decision governance: The operating system that assigns decision ownership, pathways, and feedback loops so decisions move predictably.
• Decision rights: Clear accountability for who makes a specific decision (one owner), distinct from who provides input.
• Decision pathway: The route a decision follows (altitude, required inputs, SLA, escalation) from issue to execution.
• Guardrails: A small set of non-negotiable rules that enable autonomy without constant approvals.
• Decision docket: A short, recurring forum focused only on decision-ready items, recorded with owners and deadlines.

---

Executive Takeaways

• Under pressure, unclear governance turns commerce execution into exception-driven chaos.
• Don’t “align” more—name decision owners for recurring decision families.
• Install a simple decision pathway with altitudes, inputs, and SLAs.
• Add a feedback checkpoint or you will train the organization to repeat chaos.
• A weekly decision docket beats a steering committee for day-to-day throughput.