Start with decision classes

List the recurring decisions before assigning tools or titles. For each class, record the final decision owner, what a delegate may decide, who is consulted, what evidence is retained, and what triggers escalation.

Decision class Current owner Proposed delegate and limit Escalation owner Recovery owner and procedure
Routine scheduling Service lead Coordinator within published availability and client policy Service lead Coordinator corrects the calendar after the service lead decides
Vendor assignment Service lead Coordinator within the approved list and written scope Service lead Service lead pauses assignment and follows the approved vendor or safety procedure
Client exception Founder Service lead only within a written exception rule Founder Client owner records the correction and follow-up
Refund or credit Founder No delegate until a commercial limit is written Founder Founder records the decision and customer communication
Service recovery Service lead No delegate for incident or privacy decisions Founder as incident/privacy owner in this representative version Named incident owner follows the approved recovery procedure
Process change Founder Service lead may run a bounded test but cannot change policy Founder Service lead follows the approved rollback and review plan

The point is not to create a perfect matrix. It is to expose where a person believes they have authority and where the founder believes they still do.

Use one final decision owner

GitLab's public handbook describes a DRI as the person who gathers information, weighs options, and makes a decision while consulting relevant contributors. Its architecture workflow also distinguishes consultation from blocking authority. Those are first-party examples, not a universal service-team law.

For a small team, write one name in the current-owner column for each version. Do not write “founder or service lead.” Record a proposed delegate separately, along with the authority limit, acknowledgement, and effective transfer point. List other people as responsible for execution, consulted for expertise, informed after the decision, or authorized to block a defined risk. Do not turn “everyone should agree” into a hidden founder veto.

Hand off an escalation with its missing evidence

An escalation should not be a forwarded message that says “What do you think?” Capture:

  1. the decision class and requested deadline;
  2. the current owner and proposed next owner;
  3. the facts already known and the evidence still missing;
  4. the authority limit that was reached;
  5. the consequence of waiting or choosing incorrectly; and
  6. the recovery or follow-up record required after the decision.

The founder can remain a blocker for defined decisions without remaining the default owner of every routine question. A notification is not an approval, and a consultation is not a transfer of authority.

Copy the decision-rights register

Use one ID across both tables so ownership cannot be separated from escalation and recovery.

Ownership and transfer

ID Decision class Current owner Proposed delegate Authority limit Transfer status and effective point Delegate acknowledgement
D-01 Replace with recurring decision One named person One named person or none Written boundary proposed, active, paused, or revoked plus date/event named acknowledgement or pending

Execution, escalation, and recovery

ID Executor Consulted Informed Authorized blocker Evidence retained Escalation owner Backup or absence route Recovery owner and approved action
D-01 Named role Named role or none Named role or none Named risk owner and trigger or N/A with reason Decision inputs and result One named person Named backup or stop-work rule One named person and approved procedure

No owner or recovery procedure was observed for this representative draft. Replace every role and limit with a real record before using the register as operating policy.

Walk through recent decisions

Use the copyable register above, then select ten recent decisions from normal work, client exceptions, vendor coordination, and recovery. Ask the founder and delegate separately who they believed could decide and what evidence they used.

Mark mismatches as transfer gaps, not personal failure. Write the authority limit and escalation owner for recurring classes. Recheck the register after the next material exception.

This map does not select a tool or prove that delegation improves a business. It makes the hidden work visible enough for an operator to decide what should change next. The earlier five-versus-ten-employee workflow map diagnoses owner-routing growth failures; this page supplies the transfer register and escalation protocol. Compare it with stale client follow-up mapping and exception handoff before proposing another system.