Decision Rights (DACI)
We use DACI for the handful of decisions that recur and cross role boundaries. Everything not on this list is decided by the role that owns it — do not escalate what you own.
flowchart LR
subgraph legend["DACI"]
D["D — Driver<br/>runs the decision"]
A["A — Approver<br/>one, final yes/no"]
C["C — Contributors<br/>give input"]
I["I — Informed<br/>told the outcome"]
end
D --> C --> A --> I
stateDiagram-v2 [*] --> Framed: Driver frames the call Framed --> Input: Contributors weigh in Input --> Decided: Approver decides Decided --> Informed: Informed are notified Informed --> [*]
The six recurring calls
Section titled “The six recurring calls”| Decision | Driver | Approver | Contributors | Informed |
|---|---|---|---|---|
| Tech-stack change | CTO | CTO | Relevant Team Lead(s), affected devs | CEO, PM |
| Hiring | Team Lead (for the role) | CEO | CTO, PM, interviewers | Team |
| Taking a project | PM | CEO | CTO (feasibility), BA (scope), Team Leads (estimate) | Team |
| Architecture direction | Team Lead | CTO | Seniors, affected devs | PM |
| Release to prod | PM | PM + QA Lead | Team Lead, original dev, Tech Support | CEO, client |
| Client escalation | PM | CEO | CTO, Team Lead, BA | Team |
How to read it
Section titled “How to read it”- One Approver per row. If two people think they approve, the table is wrong — fix it, don’t argue live.
- Driver ≠ Approver on purpose for the high-stakes calls (hiring, taking a project, escalation) so no single person both proposes and rubber-stamps.
- Release to prod is the one deliberate two-key gate: PM owns the go/no-go, QA Lead owns quality. Both must say yes. That decision is not the same thing as the pipeline’s
prodenvironment approval, which is the CTO’s plus client sign-off — see Pipelines & Environments. Two keys decide whether we release; the environment approval is how it ships. - Contributors are consulted, not vetoing. Give input once; the Approver decides.
Arabic version: حقوق اتخاذ القرار.