For CEOs and COOs who want faster execution without the rework, conflict, and “who approved this?” loop.
Most executive teams do not lack speed. They lack decision coherence. When functions decide fast using different rules, you get conflicting priorities, rework disguised as agility, and local optimization that quietly breaks the enterprise. The fix is an operating model move, not a motivation speech. First, write 5 to 7 decision principles you will not violate (customer promises, margin floors, risk thresholds). Second, install a single decision spine for your critical decision categories: one accountable owner, one forum, one cadence, one escalation path, with clear decision SLAs. Third, build decision memory: capture the call, the rationale, and the tradeoff so you stop paying for the same debate twice. Consistency compounds faster than speed.
Table of contents
- For CEOs and COOs who want faster execution without the rework, conflict, and “who approved this?” loop.
- The steering committee ends with a familiar line: “We need faster decisions.”
- Decision coherence is not a leadership vibe. It is an operating model outcome.
- The ruthless playbook: principles, spine, memory
- A simple operating model framework you can reuse: The Decision Coherence Stack
- When this advice does NOT apply
- What to do this week (practical, non-salesy)
- Suggested internal links:
- Facts that matter
- FAQ
- Executive Takeaways
The steering committee ends with a familiar line: “We need faster decisions.”
Two weeks later, three leaders give three different answers to the same question.
Delivery teams do what they always do: they hedge, duplicate, and wait.
Decision coherence is not a leadership vibe. It is an operating model outcome.
Decision coherence means the same type of decision produces the same answer (or the same tradeoff logic) no matter which function you ask.
When coherence is missing, “speed” is a trap. Each function can be fast and still create enterprise drag because the organization is running multiple decision systems at once.
Here are the predictable symptoms:
- Conflicting priorities: roadmaps collide because each function optimizes a different goal.
- Rework disguised as agility: teams iterate because the decision changes, not because they learned.
- Local optimization: a functional win becomes an enterprise loss (customer promise, risk exposure, margin erosion).
- Trust decay: people stop believing decisions are stable, so they stop committing.
That is not a process problem. It is an operating model problem: unclear decision rights, too many forums, missing principles, and no persistence layer.
MIT CISR frames governance as specifying decision rights and accountabilities to realize value from digital investments. That is operating model territory, not culture theater.
The ruthless playbook: principles, spine, memory
If you want decision velocity without chaos, install three layers that make coherence the default.
1) Define decision principles, not just outcomes
Principles are non-negotiable rules that reduce debate in ambiguity.
Outcomes are what you want. Principles are what you refuse to violate to get there.
A practical set is 5 to 7 rules. More becomes wallpaper. Fewer leaves gaps.
Examples (adapt to your business):
- Customer promise: “No change that increases delivery time beyond X for top segments without exec approval.”
- Margin floor: “No promo that drops contribution margin below Y unless funded by a defined spend.”
- Risk threshold: “Any initiative touching regulated data requires security and legal sign-off before build.”
- Experience standard: “Checkout cannot add steps for mobile customers without quantified conversion impact.”
- Data rule: “No new customer attribute captured without a named owner and retention policy.”
Decision rule: when a proposal conflicts with a principle, you do not negotiate in the meeting. You either redesign the proposal or escalate explicitly.
This is the operating model move: you are creating reusable constraints so teams can execute without asking permission every sprint.
2) Install a single decision spine
A “decision spine” is the minimum structure that routes decisions to closure reliably:
- one accountable owner
- one forum
- one cadence
- one escalation path
If your decision cannot find its lane quickly, governance is broken.
This is consistent with the “single point of accountability” idea in classic decision-rights work like Who Has the D? (HBR, 2006).
Build the spine by decision category (not by org chart)
Start with 5 to 8 decision categories that create most rework. In commerce and digital, common categories are:
- pricing and promotion exceptions
- customer promise changes (shipping, returns, SLAs)
- product and experience standards (DXP patterns, checkout rules)
- data access and instrumentation standards
- platform and vendor choices (DXP, OMS, PXM, CDP)
- AI risk tiering and model usage rules
For each category, define:
- Accountable owner (the “D”): who closes the decision
- Forum: where it is decided (one place)
- Cadence: how often the forum meets
- Escalation path: where it goes if blocked
- Decision SLA: how fast you commit (more on this below)
If you want a ready-made starting point, RAPID is a well-known decision-rights framework used to clarify roles in decisions.
Add decision SLAs (so the spine has teeth)
Use three simple SLAs:
- Routing SLA: how fast a decision must be assigned to its lane and owner
- Decision SLA: how fast you commit to yes/no once it is “decision-ready”
- Exception SLA: how fast you handle principle violations or material risk
This is where operating models become real: cadence plus commitments, not meetings plus opinions.
3) Build decision memory (consistency that compounds)
Most enterprises have infinite “decision discussions” and almost no decision persistence.
Decision memory is a lightweight log that captures:
- the decision (what was decided)
- the rationale (why)
- the tradeoff (what you gave up)
- the guardrails (what must remain true)
- the expiry date (when it must be revisited)
- the consulted inputs (who was heard)
Why this matters: without memory, your operating model pays the cost of re-litigating the same decision every quarter, usually with a new cast of stakeholders.
Make it operational:
- Put the log where teams work (not in decks).
- Require a link to the last relevant decision in every PRD and steering pre-read.
- Review one prior decision per week in the forum to enforce reuse.
This is also why “principles” are so powerful: decision memory tells you how the principles were applied in real tradeoffs.
A simple operating model framework you can reuse: The Decision Coherence Stack
Use this as your diagnostic and build plan:
- Principles (rules you will not violate)
- Decision rights (who decides what)
- Decision spine (one owner, forum, cadence, escalation)
- Decision SLAs (routing, decision, exception)
- Decision memory (log, retrieval, reuse)
If any layer is missing, teams compensate with workarounds:
- missing principles = endless debate
- missing rights = escalation theater
- missing spine = forum shopping
- missing SLAs = decisions that never close
- missing memory = repeat arguments and trust decay
When this advice does NOT apply
There are cases where you should not force coherence too early:
- True crisis mode where speed beats standardization for a short window
- Early discovery when you are still learning the problem space
- Regulatory sign-offs that legally require specific gates (you still simplify everything around them)
- One-way doors (irreversible decisions) where you should slow down and increase rigor
The point is not “one model for everything.” The point is coherence for the decisions that drive enterprise outcomes.
What to do this week (practical, non-salesy)
A 7-day decision coherence reset:
- List the top 10 decisions that created rework in the last 60 days
- Cluster them into 3 decision categories (start small)
- Write 5 principles for those categories (one page, no debate)
- Assign one accountable owner per category
- Collapse forums until each category has one decision home
- Define routing + decision SLAs for each category
- Start the decision log and retroactively capture the last 5 decisions
If you do only one thing: stop asking for “faster decisions” and start asking “what rules make our decisions coherent by default?”
Suggested internal links:
Facts that matter
- MIT CISR describes digital governance as specifying decision rights and accountabilities to realize value from digital investments.
- HBR’s Who Has the D? (2006) argues for clear decision roles and a single point of accountability to bring decisions to closure.
- Bain’s RAPID framework is designed to clarify decision roles and accountabilities in complex decisions.
- Gartner’s guidance on modern governance emphasizes defining principles and goals and using programmatic controls (guardrails).
FAQ
What is decision coherence in plain language?
Decision coherence means your organization uses the same rules for the same type of decision, so answers do not change by function or personality. It reduces rework because teams stop designing for multiple “possible approvals.” It also increases trust because people can predict how decisions will be made, not just what today’s answer is.
How is “decision spine” different from a steering committee?
A steering committee is often a status meeting with opinions. A decision spine is an operating model mechanism: one accountable owner, one forum, one cadence, one escalation path, and explicit SLAs to close decisions. If a forum cannot reliably produce decisions, it is not part of your spine. It is overhead.
How many principles should we define?
Start with 5 to 7. Enough to cover your biggest tradeoffs, not so many that nobody can remember them. The purpose is not to be comprehensive. The purpose is to create defaults under ambiguity. If you need 20 principles, you are probably writing policy, not decision guidance.
What should go into a decision log?
Capture the decision, rationale, tradeoff, guardrails, and an expiry date. Also record who was consulted so you do not repeat stakeholder discovery every time. Keep it searchable and lightweight. The log is not governance bureaucracy. It is insurance against re-litigating, and it accelerates onboarding of new leaders and teams.
How do decision SLAs work without becoming rigid?
Use SLAs for routing and closure, not to force reckless speed. The rule is: “decision-ready items get decided fast.” If an item is not decision-ready, it should not enter the forum. That pushes rigor upstream (clear options, quantified tradeoffs) and keeps the forum focused on decisions, not discovery.
Executive Takeaways
- Speed without coherence creates enterprise rework, not outcomes.
- Decision principles are the operating system: they define defaults under ambiguity.
- A single decision spine beats many fast committees: one owner, one forum, one cadence, one escalation.
- Decision SLAs and decision memory are what make governance usable, not ceremonial.
- This week: pick 3 decision categories, write 5 principles, assign owners, and start a decision log.

Michel Paquin is a Strategy and Management Senior Lead Consultant at Valtech, based in Montreal. He helps executive teams increase decision velocity by fixing the system around decision-making: governance, operating model, and the translation layer between strategy and delivery. He writes about business decision flows, transformation, and what actually makes change stick.
* Please note that I am unable to accept mandates outside of my engagement with Valtech.


Leave a Reply