Stakeholder Communication Framework

No-hello is a useful baseline: put the request in the first message.

But professional async work needs more than a clear first message.

A good message should create the next useful state.

That state is usually one of five things:

• facts
• ownership
• decision
• trigger
• action

This page is a reference model for choosing the right communication pattern before sending a message, opening a ticket, or scheduling a meeting.

Use it when a work situation is ambiguous and you need to move it toward evidence, ownership, or execution.

Core Principle

Most professional communication should not be optimized for sharing information.

It should be optimized for creating an outcome.

Before sending a message, ask:

What specific outcome am I trying to create, and what communication pattern does it require?

No-Hello, Extended

No-hello prevents empty communication.

Instead of:

Hi

Use:

Hi, can you confirm whether the Finance dashboard should use booked revenue or recognized revenue for Q3 reporting?

That is better, but it may still be incomplete.

The next level is outcome-oriented communication:

I found that the Finance dashboard currently uses booked revenue, while the Q3 operating report uses recognized revenue.

Can you confirm which definition should be canonical for executive reporting by Thursday 12:00?

If booked revenue is correct, I will update the operating report notes. If recognized revenue is correct, I will open a dashboard change request.

This message creates a clearer state:

• the fact is stated
• the decision is explicit
• the owner is implied
• the deadline is clear
• the next action is bounded

The Six Patterns

DFIR: Investigation

Use DFIR for root cause analysis, data discrepancies, bug investigation, stakeholder concerns, and executive questions about reported issues.

Outcome: shared understanding of reality before ownership, fixes, or priorities are discussed.

Good message shape:

Observation: stakeholders report that two applications show deployment metrics despite appearing to have no deployment data.

Facts: deployment records exist in the raw fact table. The records are stored under historical project names.

Interpretation: the application identity is linked by BitID, not project_name. This looks like a data lineage issue, not a dashboard calculation defect.

Recommendation: if BitID is the canonical application identifier, keep the current logic and document the behavior.

Use this when facts are still unclear.

Do not use this when the facts are already known and the real need is a decision or approval.

TRACE: Complex Technical Investigation

Use TRACE for multi-system failures, ambiguous ownership, data lineage investigations, integration issues, and telemetry problems.

Outcome: focused investigation effort and faster root cause isolation.

Good message shape:

Trace: followed the pipeline from Salesforce to Kafka to Databricks to Power BI.

Rule out: Salesforce sent the payloads, Kafka received messages, and Databricks raw tables contain the records.

Analyze: the aggregation job failed after a cluster credentials error.

Conclude: the failure point is inside the Databricks ETL layer, not the upstream systems.

Execute: re-authenticate the cluster credentials, rerun the job, and verify Power BI output.

Use this when the failure boundary is unclear.

Do not hand work to another team until the boundary is supported by evidence.

PASS: Cross-Team Handoff

Use PASS for technical handoffs, upstream data-quality issues, vendor escalations, and ownership transfer after an investigation.

Outcome: ownership transfer without ambiguity or rework.

Good message shape:

Based on the evidence below, this appears to sit with the Checkout Service team.

Proof: transaction_amount is arriving null for all checkout events.
Agreement: the checkout event contract requires transaction_amount.
Scope: all checkout events have been affected since yesterday's v2.1 deployment.
Shift ownership: can the Checkout Service team confirm ownership of the next action by Friday 12:00?

Use this when the receiving owner can see why they are the logical owner.

Do not use this as a vague escalation.

COAST: Alignment Sync

Use COAST for release readiness, cross-team status, open issue reviews, program updates, and dependency tracking.

Outcome: clarity, accountability, and momentum across multiple stakeholders.

Good message shape:

Context: Q3 dashboard release is scheduled for next Tuesday.

Open point: the Finance access matrix has not been verified.

Accountability: Sarah owns the access matrix validation.

Status: the test group exists, but Finance Lead sign-off is pending.

Trigger: Sarah follows up by Friday 12:00. If there is no response, we escalate to the release manager.

Use this when multiple people need the same view of owner, status, and trigger.

Do not use it as a substitute for a decision owner.

ADAPT: Decision and Architecture

Use ADAPT for architecture choices, platform decisions, technical strategy, major dependencies, product direction, and solution alternatives.

Outcome: a documented decision and agreed path forward.

Good message shape:

As-is: reporting data is processed through daily batch runs on a legacy server.

Dependency / problem: batch size is growing 15% month over month, and jobs are starting to run into business hours.

Alternatives: Option A scales the legacy server, which is faster but temporary. Option B migrates to Snowflake, which takes more work but gives longer-term scalability.

Path forward: recommend Option B and a two-week proof of concept.

Target outcome: reporting finishes before 07:00 daily.

Use this when the work cannot move until a path is chosen.

Do not schedule a meeting to “discuss” without naming the decision.

DRIVE: Follow-Up and Execution

Use DRIVE for open requests, approvals, access requests, stalled delivery items, and tactical unblocks.

Outcome: reduced delays and faster stakeholder response times.

Good message shape:

Desired outcome: approval for PR #402.

Reference: this is the nullable loyalty_tier_id schema update for tonight's pipeline migration.

Information: the change only adds a nullable field and does not affect existing downstream views.

Validate: all unit tests passed.

Easy response: reply Approved, or comment directly on the PR.

Use this when the work is understood and the main problem is response friction.

Do not send vague nudges like “just following up” without restating the request.

Workflow

Use the framework as a state machine, not as isolated acronyms.

Problem reported
-> DFIR: establish facts
-> TRACE: isolate the boundary if unclear
-> PASS: hand off if an external owner is supported by evidence
-> COAST: align owners, status, and triggers
-> ADAPT: frame the decision if a path must be chosen
-> DRIVE: make the response or execution step easy

Pivot Rules

1. Do not initiate PASS without evidence of a boundary breach.
2. If ownership is disputed, return to TRACE or DFIR.
3. Do not use COAST without named owners.
4. Do not escalate a problem without facts, impact, and a recommended next action.
5. Use ADAPT when the blocker is a decision.
6. Use DRIVE when the blocker is response friction.

Quick Choice

Agent Reference

When using this page as agent context, prefer this rule:

Classify the desired next state first.
Then choose the shortest message pattern that creates that state.

Do not start with a script.

Start with the operational state you need:

• facts
• owner
• decision
• trigger
• action

Then write the message.