Stakeholder Management and Alignment Questions

Direct answer

RACI assigns exactly one Accountable owner and any number of Responsible, Consulted, and Informed parties to each decision or deliverable, so that "who actually decides this" is never ambiguous; RACI answers who is accountable and consulted, DACI (Driver, Approver, Contributor, Informed) adds an explicit Driver role for who is pushing the decision forward day to day, which matters more on fast-moving product decisions than on stable operational ones.

Structured elaboration

• Responsible: does the work.
• Accountable: the single person answerable for the outcome; exactly one per decision, otherwise you've recreated the ambiguity RACI exists to remove.
• Consulted: two-way input before the decision; their view is sought, but they don't block it.
• Informed: one-way notification after the decision is made.
• Why exactly one Accountable matters: the single most common RACI failure is naming two Accountable parties "to be fair," which reproduces the exact confusion the tool is meant to solve.
• RACI vs DACI: DACI is functionally similar but names a Driver, the person coordinating the decision process itself (setting the meeting, chasing inputs, keeping momentum), which is useful when the decision needs active shepherding rather than a clean handoff. Use RACI when accountability just needs to be unambiguous; use DACI when the decision also needs someone actively pushing it forward.

Worked example

For a small lift-and-shift cloud migration involving client IT, a vendor, and a delivery team: the delivery lead is Accountable for the migration plan; delivery engineers are Responsible for execution; client IT and the vendor's technical lead are Consulted on cutover timing since it affects their systems; the client's executive sponsor is Informed once the plan is finalized, not consulted on every technical detail. Naming the delivery lead as the sole Accountable party up front prevents the common failure mode where client IT assumes it retains veto power over technical execution details it was only ever meant to be consulted on.

Trade-offs and pitfalls

RACI adds real overhead if applied to every minor decision; reserve it for decisions where ambiguity has already caused (or would cause) real friction, not as a blanket process. The chart is also only as good as the conversation that produced it: handing someone a RACI they never discussed and expecting instant buy-in is how "resistance to the overhead" starts, even when the chart itself is correct.

Direct answer

When two senior stakeholders give you contradictory direction on the same decision and both expect you to follow theirs, the right first move is not to pick a side or quietly satisfy whichever one you last spoke to, but to make the contradiction visible to both of them together and force an explicit resolution before proceeding.

Structured elaboration

1. Don't silently choose. Picking one direction without surfacing the conflict either burns the relationship with whoever you didn't follow, or produces work that gets undone when the conflict eventually surfaces anyway, at a later, more expensive point.
2. Bring the contradiction to both of them together, factually. A short message or meeting stating plainly "I've received direction X from one of you and direction Y from the other, and I need clarity on which to follow before proceeding" reframes the problem as theirs to resolve, not yours to guess at.
3. Provide the trade-off, not just the conflict. Where possible, lay out what each direction implies (cost, timeline, risk) so the conversation between them is grounded in consequences, not just preference.
4. If they can't resolve it between themselves, escalate to whoever can. A genuine stalemate between two people with equal standing over you needs a tie-breaker above both of them; naming that clearly rather than continuing to sit in the middle is the responsible move once direct resolution has been tried and failed.
5. Document the resolution. Once a direction is confirmed, write it down and share it back to both, so the same conflict doesn't quietly resurface a month later as a "misunderstanding."

Worked example

Two regional teams each push a different prioritized roadmap for the same shared platform, both expecting their preference to be honored. Rather than picking one, laying out both roadmaps side by side with their business rationale and cost of NOT doing the other, presented jointly to both regional leads, forces a real conversation about trade-offs between people who actually have standing to make that call, instead of an individual contributor guessing at organizational priorities they don't own.

Trade-offs and pitfalls

Surfacing the conflict too quickly, before doing any homework on the trade-offs, can look like you're avoiding the work of even a preliminary recommendation; where you have a well-reasoned view, offering it as input to their conversation (not as a decision you're making for them) is usually stronger than presenting a bare, unexamined conflict.

First, I’d validate the new priority with leadership so I understand what changed and why. Then I’d compare it against the current plan and identify which work still supports the new goal, which work should pause, and which work should stop entirely.

Next steps:

• Reframe the plan around the new business objective
• Call out schedule, scope, and staffing impacts clearly
• Align with managers and key partners before announcing broadly
• Communicate to the team in a direct but calm way

I’d be explicit that the change is a business decision, not a judgment on the team’s work. That helps protect morale. I’d also acknowledge the effort already invested and explain what is being preserved, so people don’t feel like their work was wasted.

Finally, I’d reset expectations with stakeholders and set a short checkpoint to reduce confusion. The main goal is to move quickly, but with enough context that the team can reorient without losing confidence.

Worked example
Say a team is three weeks into building an internal analytics dashboard when leadership announces the company is deprioritizing internal tooling in favor of a customer-facing reporting feature. I'd first confirm with the sponsor that the dashboard is genuinely deprioritized rather than just delayed, then compare the two plans: the dashboard's data-pipeline work turns out to be directly reusable for the new feature, so that portion continues, while the dashboard-specific UI work pauses. In the team update I'd say something like: "Leadership has shifted priority to the customer-facing reporting feature this quarter. The pipeline work you've already built carries over directly, so that effort isn't wasted, but we're pausing the dashboard UI until the new feature ships. This is a business-priority change, not a reflection on the work." That gives the team a concrete before-and-after instead of an abstract instruction to "reframe the plan."

I’d start by aligning everyone on the outcome, not the function-specific asks.

Step 1: Clarify the shared goal
I’d bring product, design, data, and engineering into one working session and define the business outcome, success metrics, and deadline constraints.

Step 2: Map dependencies and capacity
I’d list the critical dependencies, identify who owns each one, and make capacity visible by function. That exposes where the real bottlenecks are.

Step 3: Sequence the plan
I’d build the plan around the critical path: what must happen first, what can run in parallel, and what can be deferred. If capacity is tight, I’d use a simple trade-off framework: highest business value, lowest risk, and strongest dependency unlocks first.

Step 4: Create commitment
I’d confirm decision rights, document what each team is committing to, and define checkpoints where we can re-plan if assumptions change.

The goal is not to make everyone equally happy; it’s to make the trade-offs explicit so each group can commit to a plan they helped shape.

Worked example
Say the initiative is a checkout redesign that needs a payments-data migration (data team), a new UI (product design and frontend), and an updated fraud-detection model (data science). In the working session, the shared goal turns out to be reducing checkout abandonment by a set amount before the next major sales event, which becomes the deadline constraint. Mapping dependencies shows the new UI can't ship until the data migration completes, and the fraud model needs at least two weeks of production traffic on the new UI before it can be retrained safely, so the data migration is the critical-path item. Applying the trade-off framework, the data migration (highest dependency-unlock value) is sequenced first, the UI ships second, and the fraud-model update is explicitly deferred to just after the sales event rather than rushed; each team commits to that sequence in writing, with a checkpoint two weeks before launch to re-plan if the migration slips.

I push back by anchoring on the business outcome, not by saying no reflexively.

How I handle it:

1. I first clarify what problem the stakeholder is trying to solve.
2. I compare the request against the current roadmap and explain the trade-off in plain language.
3. I show the impact on timing, quality, or other committed work if we take it now.
4. I offer options: replace something else, phase it into a later release, or test it in a smaller pilot.

Example phrasing:
“Your request is valid, but if we add it this sprint, we’ll delay the launch item we already committed to. We can either swap scope, defer this to the next cycle, or find a thinner version that gets you part of the value sooner.”

How I preserve the relationship:
I stay consistent, transparent, and respectful. I acknowledge the stakeholder’s urgency, follow up with written decisions, and keep them updated so they feel heard even when the answer is no. That usually builds trust, because they see I’m protecting the broader business, not just the team’s convenience.