DARCI Decision Framework
Define decision roles: Driver, Approver, Recommender, Consulted, Informed. Clarify who makes decisions and who has input.
v3
Last updated: November 5, 2025
General
Engineering Manager
template
Loading...
Define decision roles: Driver, Approver, Recommender, Consulted, Informed. Clarify who makes decisions and who has input.
You are an engineering manager using the DARCI framework to clarify decision-making roles for a project or initiative. Generate a DARCI matrix: **Decision Context:** - Decision/Initiative: [What decision needs to be made?] - Scope: [Team-level / Department-level / Company-wide] - Timeline: [When does this decision need to be made?] - Impact: [Who will this affect?] **Generate a DARCI matrix with these roles:** ## DARCI Roles Explained **D - Driver** (1 person) - Owns the decision and drives it to completion - Does the research, analysis, and preparation - Recommends a solution - Typically: PM, Tech Lead, or Engineering Manager **A - Approver** (1 person, sometimes 2) - Has final veto power - Makes the final decision - Signs off on the Driver's recommendation - Typically: Director, VP, or CTO **R - Recommender** (1-3 people) - Provides input and recommendations - Contributes expertise and perspective - Influences but doesn't decide - Typically: Senior Engineers, Architects, Product Managers **C - Consulted** (2-5 people) - Provides expertise when asked - Subject matter experts - Consulted before decision but not in every meeting - Typically: Security, DevOps, Design, Legal, Finance **I - Informed** (Everyone else affected) - Told about the decision after it's made - No input required, but kept in the loop - Typically: Team members, stakeholders, users ## DARCI Matrix **Decision:** [Decision/Initiative Name] | Person/Role | D | A | R | C | I | Notes | |-------------|---|---|---|---|---|------| | [Name/Role] | โ | | | | | [Why they're the Driver] | | [Name/Role] | | โ | | | | [Why they approve] | | [Name/Role] | | | โ | | | [Their expertise/input] | | [Name/Role] | | | โ | | | [Their expertise/input] | | [Name/Role] | | | | โ | | [When to consult them] | | [Name/Role] | | | | โ | | [When to consult them] | | [Team/Group] | | | | | โ | [How to inform them] | ## Decision Process **Phase 1: Research & Analysis (Driver)** - [ ] Driver researches options - [ ] Driver consults with Consulted roles - [ ] Driver prepares recommendation document **Phase 2: Review & Input (Recommenders)** - [ ] Driver shares draft with Recommenders - [ ] Recommenders provide feedback - [ ] Driver incorporates feedback **Phase 3: Approval (Approver)** - [ ] Driver presents final recommendation to Approver - [ ] Approver reviews and asks questions - [ ] Approver makes decision **Phase 4: Communication (Informed)** - [ ] Decision communicated to Informed roles - [ ] Rationale and next steps shared - [ ] Questions answered ## Communication Plan **To Recommenders:** - "I'm driving this decision and would value your input. Can you review [document] by [date]?" **To Consulted:** - "I'm working on [decision] and would like to consult with you about [specific aspect]. When can we talk?" **To Approver:** - "I've researched [decision] and recommend [option]. Here's my analysis: [link]. Ready for your decision." **To Informed:** - "We've decided [outcome]. Here's why and what happens next: [summary]." ## Common Mistakes to Avoid โ **Too many Drivers** - Only one person should drive โ **No Approver** - Decision stalls without clear approver โ **Too many Approvers** - Creates deadlock โ **Consulted treated as Recommenders** - Slows down process โ **Recommenders not given enough time** - Rushed decisions โ **Informed roles not informed** - Creates confusion and resentment ## Decision Log **Decision:** [Outcome] **Date:** [Date] **Driver:** [Name] **Approver:** [Name] **Rationale:** [Why this decision was made] **Next Steps:** [What happens next] **Review Date:** [When to revisit this decision]
Get access to enhanced versions, advanced examples, and premium support for this prompt.
Loading revision history...
Apply what you learned with these prompts and patterns
Acts as a critical Red Team consultant to pressure-test your product strategy, identify hidden assumptions, uncover potential weaknesses, and validate market fit before presenting to executives or committing resources.
Plan effective sprints with capacity planning and risk assessment
Facilitate effective sprint planning sessions with your team