Governance, Decision Rights, Decision Logs, and Escalation Paths

Mission

By the end of this chapter, you can design a lightweight governance system that routes, records, and escalates material decisions through explicit authority.

• Measurable outcome: Design a lightweight governance system that routes material decisions to authorized owners, records their rationale, and escalates stalled or high-risk choices before they become schedule surprises.
• Prerequisites: Chapters 13–15; access to a real program decision or case.
• Work product: A decision taxonomy, DACI-style decision record, and escalation path for Helios Support.
• Time: 75–95 minutes.

Before you read: Predict → Commit → Connect

Predict: A weekly steering meeting has 40 attendees and no recorded decisions. Is the program highly governed or poorly governed? Explain in one sentence.

Commit: Write one current decision, its latest useful date, and the single role authorized to make it.

Connect: Recall a decision that was “socialized” repeatedly but never closed. What was missing: owner, options, evidence, threshold, or deadline?

Governance is a decision system

Governance is the system by which authority, information, decisions, and accountability move through a program. Meetings are only one possible mechanism. Good governance gets the right decision to the right owner with enough evidence at the right time, preserves traceability, and allows execution to continue within known guardrails.

Too little governance produces contradictory choices, hidden risk, and unowned exceptions. Too much central governance delays reversible decisions and teaches teams to seek permission for everything. Design governance by decision class and consequence, not prestige.

Useful decision classes include:

• Strategic: outcome, funding, major scope, market, or benefit trade-offs.
• Technical: architecture, interface, quality, security, or operability choices.
• Execution: sequencing, resource allocation, milestone, and release coordination.
• Control or risk: legal, privacy, financial, safety, or reliability acceptance.
• Change: modification to approved baselines, commitments, or configurations.
• Incident: time-sensitive containment, continuity, and customer communication.

For each class, define the accountable decider, delegates, consultation requirements, evidence standard, response time, and escalation route. Reversibility should influence altitude. A team can usually make a low-cost reversible choice locally. A difficult-to-reverse choice with cross-program or regulated impact needs broader review.

The record closes the loop. A decision is not only a conclusion; it includes the question, context, options, chosen option, rationale, owner, date, dissent or constraints, follow-up actions, and conditions that would cause reconsideration.

Clarify participation without creating a committee

DACI is one practical language:

• Driver: gets the decision prepared and moved to closure.
• Approver: the one accountable decider.
• Contributors: provide relevant expertise and evidence.
• Informed: need the result to act or remain aligned.

Local frameworks may use different names. The essential properties are one accountable decider, no ambiguity between contribution and approval, and a driver who does not confuse facilitation with authority. A TPM is often the Driver but should not be labeled Approver merely to fill a blank.

Consultation is bounded. Contributors need a clear question, options, requested input, and deadline. Consensus can be valuable when commitment and expertise are broadly distributed, but universal agreement is not a default decision rule. Record meaningful dissent and the evidence that would validate or falsify the decision.

Escalate conditions, not anxiety

Escalation is the intentional movement of a decision or unresolved condition to a level with the authority or resources to resolve it. It is not punishment, failure, or a substitute for direct collaboration.

A clean escalation includes:

1. the decision or condition;
2. observable facts and remaining uncertainty;
3. outcome, risk, and timing impact;
4. actions already attempted;
5. viable options with trade-offs;
6. a specific ask, authorized owner, and decision-by time.

Define thresholds in advance: missed latest-safe decision date, breached control, risk beyond delegated tolerance, unresolved cross-team conflict, unavailable critical resource, or incident severity. This reduces the social friction of escalating bad news.

Not every issue must climb one level at a time. An active privacy breach or safety exposure should follow the incident and control path immediately.

Recurring case: Helios Support

Helios is building an AI support assistant that retrieves customer data and can propose tool actions. Product wants automatic refunds for low-value cases. Security wants human approval for every write action. Engineering can implement either path, but the discussion repeats across three meetings.

The TPM frames the decision: “Under what conditions may Helios execute a refund without human approval in the first production release?” The product vice president is not the sole approver because privacy and financial-control authority applies. The organization names the payments risk owner as Approver, product and security as Contributors, and the TPM as Driver. Options include no autonomous writes, a capped low-risk pilot with sampled audit, or broad autonomy. The latest safe date is two weeks before final validation.

The chosen pilot is logged with a monetary cap, eligible intents, audit requirements, kill switch, and triggers for review. The program now has a decision, not a vague compromise.

Decision rights: Who owns what?

• Sponsor: owns strategic program trade-offs and residual business risk within delegated authority.
• Product: owns product value and user-experience trade-offs.
• Engineering and architecture: own technical design decisions and implementation integrity.
• Control functions: own or advise on acceptance under law, policy, security, finance, privacy, or safety mandates.
• Incident commander: owns time-sensitive incident decisions within the incident system.
• TPM: designs the decision flow, identifies the authorized owner, prepares evidence and options, logs closure, and escalates threshold breaches. The TPM does not manufacture consensus or override accountable experts.

I do

I inventory the next 30 days of decisions and classify each by consequence and reversibility. I ask, “Who has actual authority to say yes and accept the remaining risk?” Then I name one approver, the driver, necessary contributors, and a decision-by date derived from the dependency graph.

For the highest-risk choice, I prepare a one-page record with three viable options. I include “do nothing by the deadline” as a consequence, not a hidden default. After closure, I send the decision to affected owners and link it to requirements, risks, and actions.

We do

Together, repair this escalation: “Security is blocking launch and we need leadership help.”

We replace attribution with evidence: “The launch gate requires a decision on autonomous refunds. Product proposes a capped pilot; Security identifies credential-abuse and audit gaps. A no-write release delays the refund outcome but preserves the date. A capped pilot requires seven additional days for controls. We need the payments risk owner to select an option by Tuesday noon to preserve validation time.”

You do

Create a governance table for at least five decision classes. Choose one live decision and write a record with a one-sentence question, three options, evidence, trade-offs, approver, contributors, latest safe date, and revisit triggers. Draft the escalation you will use if the decision misses that date.

Pause & Recall

Without looking, define Driver, Approver, Contributors, and Informed. Name the six elements of a clean escalation. Connect to Chapter 15: how does a latest-safe decision date arise from the dependency graph?

Production lens

Measure governance by decision latency, reopened decisions, exceptions, and whether people can predict where a choice goes, not by meeting count. Audit old logs for “decisions” that lack an owner or rationale. Give recurring forums explicit inputs and outputs. Cancel a forum when its decision purpose disappears. Protect incident paths from routine approval chains, and reconcile emergency choices into the normal log afterward.

Workplace artifact: Decision record and clean escalation

# Decision record
Decision question:
Class / consequence / reversibility:
Driver:
Approver and authority:
Contributors / informed:
Decision-by date and why:
Options and trade-offs:
Evidence / uncertainty:
Decision and rationale:
Dissent / constraints:
Actions and owners:
Revisit triggers:

# Clean escalation
Facts:
Impact and timing:
What has been tried:
Options:
Specific ask / decider / deadline:

Chapter compression

Governance is a routing and accountability system for decisions. Match altitude to consequence and reversibility, name one authorized decider, record rationale and revisit conditions, and escalate observable conditions with options and a specific ask.

Retrieval deck

• Q: What is governance for? A: Routing authority, information, decisions, and accountability so work proceeds within known guardrails.
• Q: Why should a decision have one Approver? A: Shared contribution is useful, but ambiguous final accountability creates delay and reversible non-decisions.
• Q: What makes escalation clean? A: Facts, impact, prior attempts, options, and a specific ask to an authorized owner by a meaningful time.
• Q: When can normal escalation levels be bypassed? A: When immediate material harm or mandated incident/control paths require it.
• Q: Why record revisit triggers? A: A decision can be rational under current evidence yet need review when assumptions or exposure change.

Spaced review

• Now: Recreate the DACI roles and clean-escalation elements from memory.
• +1 day: Draft one complete decision record without consulting the template.
• +3 days: Check the authority and latest-safe date for three open decisions.
• +7 days: Measure the age of material open decisions and escalate one threshold breach.
• +14 days: Remove one information-only steering item and replace it with a decision package.

Sources and further study

• Atlassian Team Playbook: DACI
• Atlassian Team Playbook: Clean Escalations
• PMI: The Standard for Program Management, Fifth Edition
• NASA: Crosscutting Technical Management