Suggested application: If every proposed client-deadline change comes back to you, examine the delegation agreement before asking the team to be more independent. Start with this recurring decision rather than handing over an entire client relationship. Write down who chooses the response, what remains outside their authority, and how they communicate the outcome. The aim is to distinguish “prepare a recommendation for me” from “make this decision within agreed boundaries.”
1. Name the decision owner, not just the task executor
GitLab’s public guidance distinguishes doing the work from holding final decision authority. Its directly responsible individual, or DRI, is the ultimate decision-maker, not necessarily the person completing every task. It also recommends explicitly confirming which decisions the assigned person may make without approval. These are documented organizational practices, not independent evidence that delegation will improve your business’s performance. [1]
Suggested application: Define the decision as “choose how to handle a requested client-deadline change.” Name a single owner and state whether they can commit the business to a revised deadline or only propose one. Keep task assignments separate: a colleague might assess delivery capacity, while the owner decides which feasible option to offer. Avoid assigning joint final authority unless you also specify who resolves disagreement.
2. Separate consultation from permission
GitLab’s DRI guidance pairs final decision authority with consultation of relevant stakeholders. Its role definitions distinguish people providing expertise from those kept informed. It also recognizes exceptions requiring additional approval, including significant financial, business-risk, or reputational implications. Consultation therefore does not automatically give every contributor a veto, and decision ownership does not remove escalation obligations. [2]
Suggested application: Require the owner to seek delivery-capacity input before promising a change. Specify how long to allow for input and what to do if a required contributor is unavailable; do not treat silence as permission. Set explicit spending and risk boundaries suited to your business. For example, reserve contract changes, unbudgeted purchases above an agreed cap, and displacement of another client’s committed work for founder approval.
3. Copy a short authority agreement
Atlassian’s working-agreement practice asks teams to document communication channels and escalation arrangements, including the decider, transparency, and how others receive decisions. It treats agreements as adjustable shared expectations. The short decision agreement below is an adaptation for a small service team, not Atlassian’s prescribed template or a substitute for its broader working-agreement exercise. [3]
Suggested application: Copy and complete this agreement together: “Decision: [recurring choice]. Owner: [name]. Independent authority: [permitted commitments and exclusions]. Required consultation: [people, questions, response window, and unavailable-person route]. Escalate before committing when: [spending cap, contract change, capacity conflict, or defined risk]. Escalation decider and channel: [name and location]. While awaiting approval: [permitted holding action]. Outcome report: [audience, location, timing, decision, and relevant context]. Review point: [after the first few decisions].” Replace vague terms such as “major change” with conditions both people can recognize.
4. Walk through a hypothetical deadline request
Suggested application: In a hypothetical design studio, a client asks to bring delivery forward. The account lead owns deadline-change decisions within existing scope and available capacity. They consult the designer, who confirms that resequencing internal work would accommodate the request without changing another client’s commitment. The account lead agrees to the revised deadline and records the choice; the founder receives an update, not an approval request.
Suggested application: Change the hypothetical facts: meeting the request now requires outside help exceeding the agreed spending cap. The lead gathers the feasible options and escalates before committing. They tell the client that feasibility is still being checked. The founder decides the exception; the lead retains responsibility for coordination and reporting. Escalating this boundary should not automatically return all future deadline decisions to the founder.
5. Review the boundaries without taking ownership back
Suggested application: After the first few decisions, review where the agreement was unclear. Common mistakes to check for include consulting everyone as though unanimous permission were required, reporting only after making an out-of-bounds commitment, and the founder reopening an authorized choice merely because they preferred another option. Discuss the decision against the agreed limits rather than judging independence by whether the owner guessed your preference.
Suggested application: Use this short checklist before the next request: confirm the owner, identify the permitted commitment, name required input, check escalation triggers, and specify the outcome report. Then amend only the unclear boundary. Ask the owner to explain how they would handle the next similar case, and reaffirm that they still hold the decision within the revised agreement.
Sources
- Equal Contributions | The GitLab Handbook
- Directly Responsible Individuals (DRI) | The GitLab Handbook
- Working Agreements Play | Atlassian
Prepared with AI assistance from the linked public sources, checked on 2026-10-06. Examples are suggested workflows, not claims of hands-on product testing.