RAKI
RAKI is a responsibility and communication matrix to clearly assign roles for tasks, decisions, and deliverables (closely related to RACI/RAM).
Classification
- ComplexityMedium
- Impact areaOrganizational
- Decision typeDesign
- Organizational maturityIntermediate
Technical context
Principles & goals
Use cases & scenarios
Compromises
- Multiple A per task leads to conflicts and decision gridlock
- RAKI is perceived as bureaucracy if not integrated into real workflows
- Matrix is created once but not maintained (stale truth)
- Keep A strictly to exactly one party per item
- Limit the matrix to a meaningful granularity (not everything)
- Schedule reviews whenever the organization changes
I/O & resources
- Tasks/deliverables or decision items
- Roles/teams/stakeholders
- Context (governance, processes, interfaces)
- RAKI matrix (documented and aligned)
- Clear communication and escalation paths
- Reduced coordination and alignment costs
Description
RAKI is used to define, for tasks, decisions, or artifacts, who executes (R), who is ultimately accountable (A), who must be consulted (K/C), and who needs to be informed (I). This reduces ambiguity, duplicate work, and decision bottlenecks. In practice, RAKI is functionally equivalent to the widely used RACI/RAM model (Responsible, Accountable, Consulted, Informed) and is commonly applied in projects, governance structures, and organizational interfaces.
✔Benefits
- Reduced ambiguity and duplicate work
- Faster decisions through clear accountability
- Better collaboration and predictable communication
✖Limitations
- RAKI clarifies responsibilities but does not replace domain decisions or prioritization
- Overly granular matrices increase maintenance effort and lose adoption
- Without clear role definitions, the matrix remains open to interpretation
Trade-offs
Metrics
- Decision lead time
Time from decision submission to final decision (A).
- Escalations per decision
How often decisions require escalation due to unclear responsibilities.
- Rework caused by responsibility ambiguity
Effort caused by unclear responsibilities (e.g., duplicated implementation).
Examples & implementations
RAKI for architecture decisions
A company uses RAKI to define for ADRs who performs the analysis (R), who makes the final call (A), which experts are consulted (K), and which teams are informed (I).
RAKI for platform/product interfaces
RAKI makes it transparent who is responsible for shared interfaces and who must be involved for changes.
RAKI for agile teams
RAKI helps agile teams to clearly define responsibilities and improve communication paths.
Implementation steps
Define scope: Which tasks/deliverables/decisions are covered?
List roles/stakeholders and align on role meaning
Assign RAKI per item and facilitate conflicts (A is critical)
⚠️ Technical debt & bottlenecks
Technical debt
- RAKI is not versioned and not updated as things change
- Decision and communication paths are implicit rather than documented
- Unclear ownership causes recurring rework loops
Known bottlenecks
Misuse examples
- Using RAKI as micromanagement or control instrument
- Defining RAKI without real buy-in from accountable parties
- Applying RAKI to every detail, creating bureaucracy
Typical traps
- Mixing roles and persons (matrix should be role-based)
- Confusing R and A (execution vs. ultimate accountability)
- Interpreting Informed (I) as co-decision
Required skills
Architectural drivers
Constraints
- • Existing governance structures and committees
- • Role and job descriptions
- • Time budget for alignment