All practices

Practice — Decision-Making

Decision Ownership: Accountability, Authority, and Approval

Decision ownership makes authority and accountability explicit for a project or decision. GitLab's formal DRI model, 37signals' emphasis on self-direction and Shopify's human authority in an AI workflow offer distinct examples; they do not establish one universal model for distributed companies.

What It Is

Decision ownership makes accountability and decision rights explicit for a defined scope. A named owner may make the final decision or prepare a recommendation that requires another person’s approval. GitLab normally empowers the DRI to decide after consultation, while documenting exceptions where someone else owns the final decision. (Source)

The company examples address different forms of accountability:

  • 37signals emphasizes “managers of one” — individuals are expected to direct their own work without waiting for an assignment. (Source)
  • GitLab defines the DRI (Directly Responsible Individual) — a named person is accountable for the success or failure of the assigned project. (Source)
  • Zapier emphasizes defaulting to action and working in public. Its async guide supports those behavioral norms; it does not establish a universal DRI definition or mandatory single-page project specification. (Source)

These examples distinguish self-direction, formal project accountability and communication norms; their names and responsibilities are not interchangeable.


Why It Works

GitLab’s DRI guidance makes accountability explicit and asks owners to consult relevant stakeholders. Its examples distinguish product prioritization from engineering delivery; the same initiative can therefore contain different ownership scopes. (Source)

[Inference — application guidance.] A named owner can make it easier to identify who is moving the work and where an escalation belongs. Test whether this resolves a real delay. The cases do not establish that committees always choose worse options, that ownerless work is invisible only remotely, or that a DRI automatically speeds a decision.


Where It Fails

Authority and accountability can differ. GitLab documents exceptions requiring additional approval or another final decision-maker. Naming a DRI does not remove those controls. (Source)

Self-direction still needs management support. DHH’s August 2024 account describes senior staff carrying management duties and difficult performance cases escalating to the top. It concerns the absence of full-time managers, not the absence of management. (Source)

[Inference — implementation cautions.] Inspect overloaded owners, unclear approval boundaries, missing stakeholder input, and scope changes without a handoff. A responsibility label cannot supply capacity or resolve conflicting authority by itself.


Best Examples

37signals / Basecamp — Managers of One. The handbook expects self-direction. DHH’s August 2024 account describes management work distributed among senior contributors, with hard cases escalating to the top. Self-direction is not an interchangeable formal DRI role. (Handbook, DHH)

GitLab — DRI System. GitLab defines a DRI’s accountability for the assigned project. This makes the owner and scope of responsibility explicit. Its separate individual-contributor career path supports seniority without requiring a management role. (DRI guidance, structure)

Shopify — Human decision ownership in an AI workflow. Shopify’s September 2026 River account describes investigations that retain context during handoffs, while engineers retain authority over risk decisions, review and merges. [Inference — application guidance.] Assign authority for the decision, not just responsibility for preparing the work. (Source)


Implementation Guide

[Inference — application guidance.]

  1. Name the accountable owner and scope. Make the owner discoverable in the project record.
  2. Write the decision rights. Distinguish final authority, recommendations, mandatory consultation, and required approvals.
  3. Check resources and constraints. Identify what the owner can authorize and what requires escalation.
  4. Review capacity. Inspect delayed decisions and simultaneous responsibilities rather than applying an unsupported project-count limit.
  5. Provide support. Self-direction does not remove onboarding, mentoring, feedback, or management duties.
  6. Record handoffs and escalation. State who decides when a boundary is reached. GitLab’s approval exceptions and 37signals’ management account are examples, not one shared hierarchy. (GitLab, 37signals)

Common Mistakes

[Inference — implementation cautions.]

  • Using accountability as blame. Check that the owner has an explicit scope, resources, and access to escalation.
  • Naming a team without a contact or decision path. Identify who moves the work and who can approve a consequential choice.
  • Treating consultation as optional or approval as illegitimate. GitLab’s DRI guidance requires stakeholder consultation and permits exceptions to the normal final-authority model. (Source)
  • Leaving ownership unchanged after scope moves. Revisit the owner and approvals when the decision crosses domains.


Sources

  1. DHH: We once more have no full-time managers at 37signals: https://world.hey.com/dhh/we-once-more-have-no-full-time-managers-at-37signals-f8611085
  2. 37signals Handbook: How We Work: https://basecamp.com/handbook/how-we-work
  3. GitLab Organizational Structure: https://handbook.gitlab.com/handbook/company/structure
  4. Zapier — How to Work Asynchronously: https://zapier.com/blog/how-to-work-asynchronously
  5. Expectations — Automattic: https://automattic.com/expectations/

Shopify — River security remediation (September 2, 2026): https://shopify.engineering/river-vulnerability-remediation

GitLab — Directly Responsible Individuals: https://handbook.gitlab.com/handbook/people-group/directly-responsible-individuals/


Inferences

  • Explicit ownership may expose stalled work and ambiguous decisions in distributed or colocated teams; inspect the actual coordination problem.
  • Self-direction and formal accountability may reinforce each other, but a manager-of-one philosophy does not establish a DRI assignment or its decision rights.

Work with Alex

If your company has too many projects that “everyone owns” and therefore nobody owns, Alex helps leadership teams build the ownership clarity that allows distributed execution to move.