Remove founder approval delays with a delegation ladder, reversible decision limits, evidence rules, stop conditions and a costed four-week test.
Short answer: answer: Keep the founder on irreversible, identity-defining and above-threshold decisions; delegate reversible choices inside written boundaries with evidence, spend caps and stop rules. Start with one class of low-risk decisions for four weeks, review a sample rather than every asset, and escalate only when a stated trigger fires. Measure queue time and rework before expanding authority.
The obvious fix—“the founder should trust the team”—is not operational. The founder may hold context nobody captured, while the team may submit work without a clear decision or approved boundary.
Removing the founder from everything is equally careless. Pricing architecture, public apologies, category position and material legal risk may deserve founder judgment. The problem is indiscriminate approval, not founder involvement itself.
The Founder Delegation Boundary Ladder
The Founder Delegation Boundary Ladder has four levels: Execute, Decide within bounds, Notify, and Founder decides. CDM’s position is: founders should retain hard-to-reverse decisions and delegate bounded reversible ones, even when the delegated work is not exactly how they would have done it. Delegation that preserves a hidden taste veto is not delegation.
Amazon’s shareholder guidance distinguishes one-way doors—consequential and difficult to reverse—from two-way doors that can use lighter process. The metaphor helps triage; it does not determine legal, financial or safety authority.
Level 1: execute an approved rule
No founder review. Examples: resize an approved asset, schedule inside the signed calendar, apply established UTM rules or correct a typo without changing meaning. The rule names owner, source version and prohibited changes.
Level 2: decide within bounds
The marketing owner chooses and records the decision. Boundaries might include:
- spend up to $2,500 within an approved campaign envelope;
- existing audience and approved claims only;
- two-week reversible test;
- no new customer data, creator rights or public comparison;
- automatic stop if verified cost exceeds 1.5 times target after the minimum sample.
The founder receives a weekly sample or results, not every draft.
Level 3: decide and notify
The owner acts, then notifies the founder within a stated window because reputation or commercial context matters. Examples: pause a weak campaign, change launch sequence within the quarter or publish a minor correction. Notification is not retroactive permission. If the founder routinely reverses these choices, the boundary is wrong or the founder has not actually delegated.
Level 4: founder decides
Reserve this for defined cases: new category or brand promise, pricing architecture, material commitment above threshold, acquisition or investor communication, significant public apology, existential reputation risk or a choice the board requires. A specialist may still be the substantive approver for law, security or evidence; founder authority does not replace expertise.
Build the boundary card
Each recurring decision needs:
| Field | Example |
|---|---|
| Decision class | Paid creative test |
| Level | Decide within bounds |
| Owner | Growth Lead |
| Allowed scope | Existing audience, approved claims, US only |
| Spend/time cap | $2,500 and 14 days |
| Required evidence | Brief, rights, tracking QA |
| Stop rule | Cost >1.5× target after 40 qualified actions |
| Escalation trigger | Public complaint, rights dispute, tracking failure |
| Notification | Weekly decision digest |
| Review date | After four tests or 30 days |
Use stable decision IDs and preserve outcomes. GitLab’s DRI model shows how one person can gather input yet retain final decision authority. The company example is evidence that a singular-owner system can be documented, not proof of results for a startup.
Diagnose the current queue
For two weeks, log request time, complete-for-decision time, founder response time, number of revisions, reason for escalation and outcome. Separate waiting caused by incomplete submissions from true founder delay.
Illustrative baseline: eight approval requests weekly, founder handling averages 20 minutes, each request waits 18 business hours and four are taste-level copy choices. Founder review consumes 2.7 hours; team waiting does not equal 144 lost hours because people can switch tasks, so do not make that false calculation. Track actual blocked person-hours.
If the team records six blocked hours weekly at a $70 blended rate, modeled capacity cost is $420, plus founder time at the chosen rate. These are CDM scenario inputs, not interview or time-study findings.
Four-week delegated test
Week 1: choose one Level 2 class, such as paid creative variants within approved claims. Review the boundary card and three historical examples.
Week 2: owner makes up to three decisions. Founder reviews the record only after action unless a trigger fires.
Week 3: founder samples one decision and checks boundary compliance, not stylistic preference. Operations compares queue and rework.
Week 4: review outcomes, false escalations, missed triggers and reversals. Expand, revise or withdraw the boundary.
Illustrative after-state: four of eight weekly approvals move to Level 2. Founder review falls from 160 to 80 minutes, complete-request wait from 18 to 6 hours, and actual blocked team time from six to two hours. At $70, modeled blocked-capacity cost falls by $280 weekly. These numbers are a transparent simulation; the test must generate real data.
Approval and automation boundary
Automation may validate fields, compare spend with caps, verify that approved claim IDs exist, route Level 4 decisions and enforce a stop state. It may not decide whether a new category position fits the founder’s strategic intent or whether evidence supports a high-risk claim.
Give delegated owners the access required to act. Requiring the founder’s password, payment token or publishing session recreates the queue technically. Apply least privilege, backup ownership and transaction limits instead of shared accounts.
Handle disagreement without recentralizing
Review whether the owner stayed within the boundary and used reasonable evidence. If yes, treat a different aesthetic choice as the cost of speed and learning. If the boundary omitted a material concern, update it prospectively. If the owner ignored it, address that control failure.
Do not rewrite a delegated decision as “founder approved” after success. Preserve who decided so the organization can learn whether delegation works.
Review the ladder monthly at first. Retire triggers that add no protection, tighten boundaries after genuine misses, and publish every change before the next delegated decision enters the queue.
Related guides
Frequently asked questions
Which decisions should a founder keep?
Keep decisions that are difficult to reverse, define company identity, exceed an agreed financial threshold or create material legal, customer or reputation exposure. Examples include pricing architecture, a new category promise, major public correction and commitments outside the approved plan.
The founder should not automatically own specialist conclusions; counsel, finance or security may have required authority. Review the retained list quarterly because yesterday’s unusual choice may become a safe recurring rule. For each retained class, define the submission evidence, response service level, backup authority and emergency route so “founder decides” does not mean an unmeasured inbox.
How do we set a delegation spending limit?
Use downside the company can absorb, reversibility, learning value and cumulative exposure. A $2,500 per-test cap is illustrative; also cap monthly total so ten “small” tests cannot bypass governance. State included fees, currency and who can change the threshold. A lower limit may apply to new vendors or unproven tracking.
Finance should approve the boundary, and any contractual or regulatory obligation can require escalation regardless of spend. Review actual loss, refund and stop performance after several tests; raise the limit only when controls work, not because the team is impatient.
What if the founder keeps changing delegated work?
Classify each change. A missed boundary or new fact should update the rule; a preference should not become a veto after delegation. Use sampled review and require the founder to name the consequence, not merely “I dislike it.” If reversals persist, either the decision is genuinely Level 4 or the organization has not accepted delegated variation.
Make that choice explicitly rather than letting the team wait under fictional authority. Track reversals with their reason and cost for four weeks; patterns reveal whether the rule, evidence, owner capability or founder behavior needs correction.
Should delegated decisions still be documented?
Yes, but proportionately. Record the decision ID, choice, boundary, key evidence, owner, stop rule and outcome for material tests. Routine execution under a rule needs a log or platform history, not an essay. Documentation allows sampling and prevents the founder from reconstructing context from memory.
The caveat is sensitive information: limit access and retain only what policy requires, especially for personnel, customer or legal matters. A record should be findable within two minutes and link to the controlling evidence; otherwise delegated learning disappears into the same conversational bottleneck.
Can an AI system replace founder approval?
No. It can check completeness, compare structured limits, summarize evidence and flag exceptions, but strategic identity, accountability and ambiguous risk remain human decisions. A model may also miss the private context that made founder review necessary.
Use AI to prepare the decision card and preserve cited sources; never let a confident output silently expand spend, claims or rights. Test false negatives before trusting any automated gate. Log model version, input boundaries and human confirmer for consequential use, and provide a manual path when the system is unavailable or uncertain.
How quickly should approval turnaround improve?
Set a target from business need and baseline rather than a generic benchmark. The illustrative test moves complete-request wait from 18 to 6 business hours, but real queues differ. Measure median and longest waits, plus blocked hours and reversals. A faster answer is not improvement if corrections rise.
For true incidents, use a separate emergency escalation target; ordinary approval speed should not borrow crisis authority. Segment requests by level and completeness, because counting time before the submission contains required evidence unfairly attributes preparation delay to the founder.
Next decision: Design a marketing team for creator-led growth and AI discovery
Related reading: Design creator approvals without killing the idea · Build the contemporary marketing operating system · Create a practical experimentation system
Sources and research notes
- Amazon, 2015 Letter to Shareholders.
- AWS, Elements of Amazon’s Day 1 Culture.
- GitLab Handbook, Directly Responsible Individuals and Equal contributions.
- Microsoft, 2023 Work Trend Index.
Research checked 26 September 2026. CDM conducted no founder interviews, delegated live tests or decision-delay study. Times, costs, thresholds and before/after results are explicitly illustrative simulations. Run the four-week test with real logs, finance-approved costs and specialist escalation for legal, security, financial or customer-harm decisions.
This article is editorial guidance. Apply the principles in proportion to your market, evidence, and responsibilities.
