Strategy to Execution, part 5

Every strategy dies at the same boundary. Not in the boardroom, and not in the first weeks of execution. It dies at the seams, where one team's responsibility ends and another's begins.

In my experience, when you dig into an execution failure, you usually find the same thing: nobody was quite sure who owned it. This article gives you a framework to fix that, the Role-Clarity Triplet, and a mapping session you can run in 90 minutes.

The problem: everyone approved it, nobody decided it

You have seen these:

• The product launch that stalled while sales and delivery each assumed the other was handling stakeholder communication.
• The change initiative that lost momentum because everyone approved it but nobody decided it.
• The outage where three people issued contradictory instructions at the same time.

Role ambiguity rarely looks dramatic. It rarely shows up in post-mortems. It is just friction: persistent, expensive and preventable.

Why RACI alone is not enough

When organisations think about role clarity, most reach for a RACI matrix. It maps who is Responsible, Accountable, Consulted and Informed for each deliverable. If you are not using it, start there.

But on its own, RACI solves the wrong problem. It answers who is involved. It does not answer who decides, or who is on the hook for the outcome.

That is where most RACI implementations break down. A beautifully built matrix can still leave a team paralysed when a decision is needed, because it tells you who does the work, not who makes the call. Rogers and Blenko at Bain made decision roles the core of their work for exactly this reason: unclear decision rights create bottlenecks (Rogers & Blenko, HBR 2006).

The framework: the Role-Clarity Triplet

The Triplet combines three tools into one session.

1. RACI: who is involved

• Responsible does the work.
• Accountable owns the outcome. One person per deliverable, always.
• Consulted gives input before decisions are made.
• Informed is kept up to date.

The most common failure: several people listed as Accountable for the same deliverable. If two people are accountable, the accountability cancels out. One name. One A.

2. RAPID: who decides

RAPID was developed by Bain & Company for decision clarity (Rogers & Blenko, HBR 2006; republished by Bain):

• Recommend proposes options with analysis.
• Agree must sign off before the decision is made.
• Perform carries it out.
• Input provides data or perspective.
• Decide makes the final call. One person, always.

The most common failure: the D sits too high. When directors decide what team leads should own, you get bottlenecks, slow decisions and a team that stops thinking for itself. Push the D as low as it can responsibly go.

3. DRI: who owns it

The Directly Responsible Individual is the simplest of the three. GitLab's handbook credits Apple with the term and describes the DRI as the one person ultimately accountable for the success or failure of a project (GitLab Handbook). Not a team. Not a committee. One person who can answer "how is this going?" at any moment.

The DRI does not have to do all the work. They make sure it gets done, raise blockers early and own the result.

The most common failure: assigning the DRI to a team. "The delivery team owns this" sounds collaborative. It is diffusion of responsibility in a team-player costume.

The 90-minute mapping session

Run it with the five to eight people whose work meets on one initiative, project type or recurring process. One whiteboard or shared doc.

1. List the deliverables (15 min). Write down 8 to 12 key deliverables or decisions. Be specific: "go/no-go decision made," not "decide whether to launch." Vague deliverables produce vague accountability.
2. Map the RACI (20 min). Assign R, A, C and I. Flag every row with more than one A, or none. Those flags are conversations for the next 20 minutes, not problems to park.
3. Find the D (20 min). For every deliverable that involves a decision, name the Decider. If you cannot, you have a governance gap. Consensus is not a decision process, and political decisions still need an owner.
4. Name the DRIs (15 min). For the five most critical deliverables, write one name next to each. If it "feels wrong" to put one name on a team's work, treat that feeling as a signal, not a veto.
5. Close the gaps (20 min). Where are there several As? Where is the D too high? Where is there no DRI? Give each gap an owner who resolves it within a week, and book a 30-minute follow-up.

An example: the 11 pm outage

Here is an illustrative scenario. A service goes down at 11 pm. Three team leads issue instructions, and the instructions contradict each other. The team freezes while it waits for clarity. A one-hour fix takes four.

The fix is an escalation RAPID built before any crisis:

• Level 1 (fewer than 100 users affected): the team lead decides.
• Level 2 (100 to 1,000 users): the head of delivery decides.
• Level 3 (more than 1,000 users, or an SLA breach): the COO decides.

The thresholds are examples. Set your own. The point is that everyone knows who holds the D before the crisis starts. Escalation becomes a protocol, not a panic.

The same logic works for a product launch, where one person holds the D on go/no-go and marketing, sales and product each have a DRI for their part. It works for an operational change too, where adoption gets its own DRI instead of being a hoped-for outcome.

Five mistakes that break role clarity

1. RACI without RAPID. You know who does the work but not who makes the call.
2. A DRI that is a team. Name a human. Today.
3. Mapping once. Role clarity decays with every reorganisation and new initiative. Revisit it after every major change.
4. Using RACI to settle a conflict. If two leaders are fighting over the A, that is a conversation about authority and trust. Have it, then update the matrix.
5. Skipping the gap review. Most teams do steps 1 to 3, feel good about the document and never close the gaps. The gaps are the work.

Your action plan

• Pick one target. Your most complex project, your most friction-heavy process, or the initiative where "who owns this?" comes up most.
• Block 90 minutes and invite the people whose work meets there.
• Run the five steps and leave with a RACI, a named D for every decision and a DRI for each critical deliverable.
• Check after 60 days. Can every team member name the DRI for their top three deliverables without looking it up? Are escalations settled in one meeting cycle? Are the "I thought you were handling that" conversations going down?

The bottom line

Strategy rarely fails because people do not care. It fails at the seams, where ownership is assumed instead of named.

The goal is not a perfect document. It is a shared understanding that survives the first week of execution, and the tenth.

So where in your organisation does "who owns this?" come up most often?

Read next: The next series starts with Why Your Organisation Needs a PMO (and What Kind). Role clarity also sits at the heart of The Translation Layer: Bridging Sales & Delivery.

Want clear ownership in your leadership team? See how I work on IT Leadership Consulting & Strategy Execution.

References

1. Rogers, P. & Blenko, M. (2006). "Who Has the D? How Clear Decision Roles Enhance Organizational Performance." Harvard Business Review, January 2006. https://hbr.org/2006/01/who-has-the-d-how-clear-decision-roles-enhance-organizational-performance. Republished by Bain & Company: https://www.bain.com/insights/who-has-d-how-clear-decision-roles-enhance-organizational-performance/
2. GitLab Handbook. "Directly Responsible Individuals (DRI)." https://handbook.gitlab.com/handbook/people-group/directly-responsible-individuals/