Mission
- Measurable outcome: By the end, you can resolve five ambiguous decisions by assigning a decider, executor, advisers, and integration owner with at least 80% alignment from a peer review.
- Prerequisites: Chapters 1.1–1.2.
- Work product: A role-boundary and decision-rights map.
- Time: 55–70 minutes.
Before you read: Predict → Commit → Connect
At Meridian Pay, who decides whether to delay launch when reconciliation evidence is incomplete: Product, Engineering, the architect, SRE, Compliance, or the TPM? Choose one before reading. Then list what each other role contributes. Connect this to a conflict you have seen that was really an ownership gap.
Titles are weak signals; decisions are the unit of clarity
Role descriptions are centers of gravity, not universal law. Company size, product maturity, regulation, and individual scope move boundaries. A TPM who memorizes a universal RACI will eventually violate a local charter. A stronger TPM asks, for each consequential decision: Who proposes? Who provides evidence? Who decides? Who executes? Who accepts residual risk? Who integrates the consequences across teams?
The common centers of gravity are:
- Product manager: customer problem, product direction, priority, and value hypothesis, usually “what and why.”
- Engineering manager: people, team capacity, engineering environment, and delivery accountability.
- Technical lead or architect: detailed technical direction, design integrity, and engineering trade-offs.
- Project manager: coordinated delivery of a defined scope, schedule, resources, and deliverables.
- Program manager: related initiatives, governance, stakeholder alignment, and benefits.
- Scrum master: Scrum process, facilitation, coaching, and team impediments within that framework.
- Chief of staff: executive leverage, operating agenda, communications, and cross-organizational follow-through.
- TPM: integration of a complex technical outcome across systems and teams: dependencies, system-level risks, decision closure, evidence, and readiness.
Accessible diagram label: Several roles contribute distinct authority to one technical outcome while the TPM connects dependencies, commitments, evidence, and consequences.
The overlap is intentional. Product can understand architecture. An engineering manager can run a cross-team plan. A TPM can write a prototype. Capability does not automatically confer decision authority. Clarity prevents two failure modes: abdication (“not my lane”) and appropriation (“I coordinated it, therefore I decide it”).
Accessible diagram label: A launch decision combines evidence from multiple authorities; a named launch authority decides while the TPM assembles the decision and propagates consequences.
At Meridian, the right answer to the prediction is “the named launch authority,” not a universal title. In a regulated business that may be a release-governance body; elsewhere it may be an engineering or business executive. The TPM’s obligation is to ensure the authority is named before the crisis, evidence is comparable, dissent is recorded, and the decision reaches every affected plan.
Use a decision-rights record, not a role-responsibility encyclopedia. Define rights for high-consequence decisions: scope priority, architecture, security exception, launch, rollback, incident command, customer communication, and residual-risk acceptance. Revisit when the program changes.
Decision rights: Who owns what?
The TPM normally owns the decision process, not every decision. That means framing the question, identifying the deadline and decider, collecting alternatives and evidence, documenting rationale, and tracing actions. Product normally decides product priority; technical authorities decide or approve designs; engineering managers commit team capacity; domain authorities govern their risks; executives allocate investment. Exceptions are legitimate when explicit.
“Accountable” must be specific. An architect accountable for design is not automatically authorized to accept a privacy exception. A product manager accountable for customer value is not automatically authorized to accept an unbounded reliability risk.
I do
For Meridian I create one record:
Decision: permit 10% regional traffic before full historical reconciliation completes. Proposer: migration engineering. Decider: release council chair under the local policy. Required advisers: Product, ledger architect, SRE, Compliance, Operations. Evidence: live shadow reconciliation, discrepancy bounds, rollback duration, customer-impact model. TPM role: integrate evidence, force decision by the traffic-window deadline, update launch and incident plans. Residual-risk accepter: explicitly named council chair, with Compliance concurrence where required.
We do
Northstar Devices has a supplier delay. Product wants to launch in two countries with older hardware. Firmware engineering says compatibility is possible; Security says support ends in six months; Sales has announced the date. Together assign rights for product scope, compatibility design, security exception, country launch, customer communication, and integrated replanning.
Show the model answer
Model answer
Product proposes the constrained country scope and owns its value consequence. Firmware and hardware technical leads own compatibility evidence and design. Security decides or recommends the exception according to policy; do not assume it can be overruled informally. A named business/release authority decides the launch after Operations and Legal advise. Sales or Communications owns external messaging under company policy. The TPM owns the integrated option record, dependency and date consequences, evidence completeness, decision deadline, and propagation into supply, firmware, support, and rollback plans.
Scoring rubric (0–4)
- 0: Assigns every decision to the TPM or to “leadership.”
- 1: Names roles but no decisions or evidence.
- 2: Separates several decision domains but leaves launch or risk acceptance vague.
- 3: Names proposers, deciders, advisers, evidence, and TPM integration work.
- 4: Also handles policy-based concurrence, conflict, decision deadlines, and consequence propagation.
You do
Take five decisions from your program. For each, complete the artifact below. Interview Product and Engineering separately. Any disagreement is data: do not average it away. Convene a short charter discussion and resolve the two highest-risk mismatches.
Pause & Recall
From Chapter 1.2, name the four forms of technical judgment. Which one is most relevant when a design authority and Product disagree? Recall the difference between outcome ownership and output delivery from Chapter 1.1. Then state the TPM center of gravity in one sentence.
Production lens
Role confusion becomes dangerous during launches and incidents because time pressure amplifies assumptions. Publish decision rights beside readiness criteria. Ensure after-hours delegates exist. Log changes when reorganization, vendor involvement, or regulatory scope alters authority.
Workplace artifact: decision-rights map
Decision / trigger:
Why it matters and by when:
Proposer:
Decider:
Required advisers / concurrence:
Evidence providers:
Executor(s):
TPM integration responsibility:
Residual-risk accepter:
Escalation path and delegate:
Record location / communication audience:
Local-charter exception to normal role boundary:Chapter compression
Titles do not settle decisions. Product centers value and priority; engineering leadership centers people and execution; technical leads center design; domain authorities center specialized risk; project and program roles center delivery and benefits; Scrum masters center Scrum; chiefs of staff center executive leverage. The TPM centers cross-team technical integration and decision closure.
Retrieval deck
- Q: Does the TPM own every cross-team decision? A: No; the TPM normally owns the integration and decision process while named authorities decide.
- Q: Why call boundaries centers of gravity? A: Actual authority varies by company, domain, level, and charter.
- Q: What is the safest answer to “Who decides launch?” A: The authority named by the local launch policy or charter.
- Q: What is appropriation? A: Assuming coordination grants decision authority that belongs to another role.
- Q: What six questions clarify a decision? A: Who proposes, provides evidence, decides, executes, accepts risk, and integrates consequences?
Spaced review
- Now: Assign one Meridian decision using all six decision questions.
- 1 day: Reproduce the role centers without looking.
- 3 days: Distinguish facilitation ownership from decision authority in one meeting.
- 7 days: Audit one decision and separate the decision owner from the meeting owner.
- 14 days: Ask two peers to assign three rights independently and reconcile the differences.