We Implemented RACI to Speed Up Async Decisions. 3 Months Later, People Still Ask "Who Actually Decides This?"

General
1

Following up on the timezone/async discussion with a specific challenge we’re facing.

The Promise vs The Reality

The promise: RACI (Responsible, Accountable, Consulted, Informed) solves decision ambiguity in async environments. Clear roles = faster decisions.

The reality: Three months in, engineers still DM me: “Is this my call or yours?”

What We Did (By The Book)

  • Created comprehensive RACI matrix for all major decision types (architecture, product features, hiring, process changes)
  • Trained entire team on how to use it (2-hour workshop)
  • Added RACI reference to onboarding materials
  • Posted it prominently in Notion

What’s Actually Happening

Problem 1: People still seek permission when they have authority

  • Engineer owns database migration decision (they’re “Accountable”)
  • Still asks me “should I do this?” instead of just deciding

Problem 2: “Informed” becomes “Consulted” (decision drag)

  • Matrix says person is just “Informed” (FYI only)
  • They show up in the RFC thread arguing as if they have veto power
  • DRI feels pressured to wait for their approval

Problem 3: Bypassing RACI when nervous

  • When decision feels risky, people default to “let’s get everyone’s input”
  • RACI gets ignored precisely when we need it most

Root Causes I’m Seeing

Fear of being wrong: Engineers would rather slow down decision with consensus than risk solo mistake

Unclear boundaries: Where does “architecture decision” end and “implementation detail” begin?

Cultural habit: We say “empowered teams” but our muscle memory is still “ask permission”

What’s Working (Barely)

  • Weekly decision reviews: I publicly recognize good solo decisions (“Jamie decided X without asking me, and it was right”)
  • Decision apprenticeship: Shadowing me in decisions before owning similar ones
  • Celebrating smart failures: When someone decides, it’s wrong, but we learn—we highlight it positively

What’s Not Working

  • The matrix itself: Too abstract. “Responsible vs Accountable” confuses people
  • Training sessions: People nod, then forget it all when facing real decision

Questions for the Community

  1. Is RACI actually the right framework for engineering teams? Or are there better alternatives?

  2. How do you shift from consensus culture to DRI culture? This feels like a multi-year cultural transformation, not a process change.

  3. What’s worked for embedding decision clarity? I’m convinced the answer isn’t better docs—it’s something else.

The irony: We implemented RACI to speed up async decisions. But people’s discomfort with decision authority is the real bottleneck, not the lack of framework.

2

Keisha, I feel this. RACI failed at my previous company for exactly the reasons you’re describing. Here’s what I use instead.

The Problem With RACI: Too Many Roles

Responsible vs Accountable? Even after the training, people can’t keep it straight. The complexity is the problem.

What We Use: DRI + “Input Requested From”

Simpler mental model:

  • DRI (Directly Responsible Individual): One person who makes the final call
  • Input requested from: Who must be consulted (but doesn’t have veto)
  • Everyone else: Informed via decision log

That’s it. One throat to choke.

How It Works In Practice

Every project doc, every RFC, every decision: DRI name at the top.

Example: Choosing observability platform

  • DRI: Tech lead for platform team
  • Input requested from: 2 senior engineers, SRE lead
  • Deadline: Decision by Friday
  • DRI reads input, makes call, documents reasoning

If it’s the wrong decision? Post-mortem, learn, iterate. But the decision got made.

The Cultural Shift That Actually Mattered

Not the framework—the values change:

  1. “Strong opinions, loosely held” - Have a point of view, but change it when you learn more
  2. Fast decisions > perfect decisions - Velocity matters. Most decisions are reversible.
  3. Blameless post-mortems - When DRI is wrong, we learn, not punish

To Your “Fear of Being Wrong” Point

That’s the real blocker, not the framework. Framework won’t fix fear culture.

Suggestion: Start with low-stakes decisions to build confidence muscle:

  • Let team lead choose logging format (who cares if it’s not perfect?)
  • Let engineer pick monitoring dashboard layout
  • Let designer choose icon set

Build the muscle memory of: “I decided, it was fine, the world didn’t end.”

Then graduate to bigger decisions.

The Old Way vs New Way

Old: Architecture decision for new service

  • Architecture review board convenes
  • 3 weeks of meetings
  • Consensus required from 8 people
  • Decision made by exhaustion

New:

  • Tech lead is DRI
  • Requests input from 2 senior engineers (async)
  • Decides in 3 days
  • If wrong: Fix it

The second one feels scary. But it’s 10x faster, and frankly, the outcomes aren’t worse.

3

Keisha, thank you for naming this. We’re seeing the exact same pattern.

My Theory: RACI Works in Low-Trust, Fails in High-Trust

Low-trust environments: People want clear rules for CYA. RACI gives them that.

High-trust environments: People want clarity to move fast, but then… they still seek permission anyway because they respect their teammates.

The Paradox

Teams with the best culture struggle most with RACI. Why? Because they genuinely want to be collaborative.

What it feels like to them:

  • RACI says “you’re just Informed”
  • They hear: “Your opinion doesn’t matter”
  • They feel excluded, not empowered

We had engineers who were marked “Informed” on decisions raise complaints: “Why wasn’t I consulted? I have context on this!”

I had to explicitly coach: Being informed ≠ being disrespected.

The Cultural Shift We Needed

Reframe the conversation:

From: “Who gets a say?”
To: “Who has the context to decide well?”

From: “I want to be involved”
To: “Do I need to be involved, or do I just want to?”

What’s Helped

  1. “Disagree and commit” as explicit practice - You can disagree with a decision and still support it
  2. Decision logs show reasoning - People feel heard even if not consulted, because they can see the DRI’s thinking
  3. Retrospectives examine decision quality - Not just outcomes, but “did we have the right DRI? Right input?”

To Michelle’s Point About Fast Decisions

Agree in principle, but in regulated fintech, some decisions must be slow (compliance review, security audit). The skill is knowing which decisions have which constraints.

We categorize:

  • Type A: Reversible, low-risk → DRI decides solo
  • Type B: Costly to reverse → DRI with required input
  • Type C: Regulatory impact → Compliance must approve (not negotiable)

The Question I’m Still Wrestling With

How do you maintain collaborative culture while still having clear DRIs?

Because the whole point of good engineering culture is that people care about the work, want to contribute ideas, feel ownership. RACI/DRI can accidentally suppress that if not handled carefully.

4

Different angle here: Maybe RACI fails because we don’t teach decision-making skills in the first place.

The Training Gap

In design, we’re explicitly taught critique frameworks—how to give feedback without undermining the designer who owns the decision.

In engineering? Most people learn decision-making by… osmosis? Trial and error?

The Skills Nobody Teaches

  • How to disagree without blocking
  • How to give input when you’re “Consulted” but not “Accountable”
  • How to accept being “Informed” without feeling excluded
  • How to distinguish between “here’s a constraint” vs “I don’t like this”

Example From My Design Team

Scenario: Design system color palette decision. I’m DRI.

Early days (before coaching):

  • Engineering: “We can’t do that” (sounds like veto)
  • Me: “Uh, okay…” (feels blocked)

After explicit coaching:

  • Engineering: “Here’s the implementation cost of each option: Option A is 2 weeks, Option B is 2 days”
  • Me: “Thanks, that helps me decide” (constraint, not veto)

The difference: DRI stayed with me. But the input shifted from blocking to informing.

How We Coached This

  1. “How to Give Input” guidelines posted in Notion

    • Start with “Here’s a constraint…” or “Here’s a risk…”
    • Avoid “We should…” or “This is wrong” (that’s DRI’s call)

  2. Model good consultation publicly

    • I’d explicitly say in threads: “I’m consulting you because [reason], but I’m the DRI”
    • Show what good input looks like

  3. Feedback on feedback (meta!)

    • After decisions, debrief: “That input was helpful because…” or “This felt like a veto when it was meant as a constraint”

To Keisha’s “Decision Apprenticeship” Idea

Yes! Pair on decisions before flying solo.

  • Shadow DRI on 2-3 similar decisions
  • Watch how they incorporate input without being paralyzed by it
  • Debrief afterward: “I heard 3 conflicting opinions. Here’s why I chose option B anyway.”

The skill is: How to listen deeply without letting every opinion have veto power.

Suggestion

RACI might work better if paired with decision-making skill development:

  • Workshop: “How to consult without controlling”
  • Case studies of good async decisions
  • Explicit teaching of “strong opinions, loosely held”

Because you’re right, Keisha—the framework isn’t the problem. The missing skill is.