<p><strong><em>tl;dr: A growing startup does not need every decision to pass through the founder. It needs the decision’s logic to travel with it: a named owner, intended outcome, constraints, evidence, trade-offs, reversibility, thresholds, escalation conditions, and a record of the rationale. This edition introduces the Decision Contract, a lightweight way to make that logic inspectable without pretending it guarantees faster growth, longer runway, or better fundraising outcomes.</em></strong></p><hr><p>Your team does not need access to every thought in your head.</p><p>It needs enough of the logic behind those thoughts to act while you are in another meeting, on a flight, or dealing with the problem that genuinely requires you.</p><p>That distinction matters. Many growing companies have plenty of information and very little decision context. The dashboard says what happened. The SOP explains a known task. The roadmap lists what the team hopes to build. Then a consequential choice arrives, and everyone looks toward the founder as if the missing operating system is stored in their hippocampus.</p><p>Decisions queue behind one person. Old questions reopen because nobody recorded the original reasoning. Or the loudest preference in the room wins. The company looks busy, but the logic is still being run manually.</p><p>The answer is not to remove judgment. It is to make judgment inspectable.</p><p>### The question behind the question</p><p>"How do we get people to make decisions without me?" is not quite the right question.</p><p>A better one is: <strong>What logic must travel with a decision so the team can make a good call without copying the founder’s brain?</strong></p><p>That logic usually includes the owner, intended outcome, constraints, evidence, trade-offs, threshold for action, and escalation conditions. It also needs a record of why the decision was made. Memory is a poor document-management system and an even worse governance process.</p><p>Call this the <strong>Logic Layer</strong>.</p><p>The term is a practical synthesis, not a validated external framework. Its value is diagnostic. It shows you what is missing when a company has metrics, meetings, and capable people, yet ordinary judgment still routes back to the founder.</p><p>### A decision is not a discussion</p><p>Founders often describe a decision problem as a communication problem.</p><p>"The team needs more context."</p><p>Sometimes it does. But context alone does not create authority.</p><p>Ten people can receive the same information and still have no idea who decides, what matters most, or when the choice should travel back up the chain.</p><p>Established decision-rights approaches separate those roles. GitLab’s DRI model names one directly responsible individual. Bain’s RAPID model distinguishes recommending, providing input, agreeing, deciding, and performing. Atlassian’s DACI framework separates the driver, approver, contributors, and informed participants.</p><p>The vocabularies differ, but the useful point is the same: <strong>collaboration is not consensus, and input is not decision authority.</strong></p><p>You do not need to install three acronyms across the company. Pick language people can remember.</p><p>For a recurring decision, name one owner. Then state who must approve, who should be consulted, who executes, and what crosses the escalation boundary. If everybody owns the decision, it has entered a committee-shaped waiting room.</p><p>### The Decision Contract</p><p>For decisions that recur or carry meaningful cost, use a lightweight Decision Contract. Put it in a document, ticket, planning record, or wherever the work already happens.</p><p>The location matters less than the logic it preserves.</p><p>#### 1. State the decision narrowly</p><p>"What should we do about enterprise demand?" is a strategy seminar.</p><p>"Do we add the requested security feature before the next financing milestone?" is a decision.</p><p>If the question contains several decisions, split it. Broad questions invite broad opinions. Narrow questions give someone something they can own.</p><p>#### 2. Name the intended outcome</p><p>What is this choice meant to change or protect?</p><p>It may be milestone timing, customer learning, reliability, cash preservation, regulatory readiness, or a specific commercial opportunity. The outcome tells the team what to optimize. Without it, people optimize the part of the problem closest to their function.</p><p>That is how a feature gets approved because it is elegant, a hire gets approved because the team is exhausted, or a vendor gets approved because procurement has finally found a spreadsheet with a green cell.</p><p>#### 3. Name the owner</p><p>Choose one decider, then separate the other roles. Who provides input? Who must approve? Who is accountable for execution? Who needs to know afterward?</p><p>The owner does not have to be the most senior person in the room. They should be close enough to the relevant information and able to act within the stated boundaries. The founder stays in the system when a decision crosses an agreed escalation condition.</p><p>Delegation is not abandonment. It puts authority near the information and keeps the boundary visible.</p><p>#### 4. Declare the constraints</p><p>Write down the boundaries that can actually change the choice.</p><p>Cash and runway may matter. So may a customer commitment, hard date, technical debt, security, safety, regulation, contractual obligation, or the opportunity cost of pulling people off another milestone.</p><p>Do not list every imaginable constraint. That turns the contract into a museum of anxieties.</p><p>Financial information belongs here as operating logic, not decoration. If a burn or runway threshold changes what the company can responsibly fund, state the response. Which hire pauses? Which experiment gets capped? Which milestone gets re-scoped? Who decides, and who is informed?</p><p>The number alone is not the logic. <strong>The trigger and the response are the logic.</strong></p><p>#### 5. Identify the evidence</p><p>Use the smallest set of decision-relevant facts. Say how fresh the information is and how confident you are in it.</p><p>NASA’s decision-analysis guidance begins with the intended outcome, then covers measurable criteria, alternatives, evaluation methods, assumptions, and uncertainty. You do not need to turn every product choice into a space programme. The more useful lesson is that the method should fit the decision.</p><p>A reversible experiment can run on light evidence. A hard-to-reverse, safety-critical, regulated, or financially material commitment deserves stronger evidence and review by people qualified to assess it.</p><p>#### 6. Make the trade-off visible</p><p>Every decision favors something at the expense of something else.</p><p>Are you choosing speed over completeness? Learning over near-term revenue? Cash preservation over capacity? Reliability over feature breadth?</p><p>When the trade-off stays hidden, the team argues about preferences while pretending to argue about facts. Put the sacrifice on the page. It often reveals the real disagreement faster than another meeting will.</p><p>#### 7. Match rigor to reversibility</p><p>Amazon’s shareholder letter distinguishes reversible "two-way door" decisions from choices that deserve more care. The useful operating lesson is not a universal percentage or an order to move quickly. Classify the decision before you build the process around it.</p><p>A reversible experiment might need a named owner, capped budget, success signal, stop condition, and review date. A hard-to-reverse decision may need more evidence, explicit assumptions, specialist review, and senior approval.</p><p>The process should be heavy enough to protect the company and light enough that people do not avoid the decision because the form has become a second product.</p><p>#### 8. Write the rule and the escalation condition</p><p>What evidence triggers yes, no, pause, or escalation?</p><p>"The founder can step in if it feels important" is not a boundary. It is a founder-shaped fog machine.</p><p>Use a condition people can observe. Escalate if the spend exceeds the approved limit, the decision affects a regulated obligation, a milestone moves by more than an agreed amount, evidence conflicts across a defined threshold, or the choice becomes difficult to reverse.</p><p>The exact thresholds belong to your company and the decision. There is no universal runway, headcount, approval, or timing number that can be pasted responsibly into every technical startup.</p><p>#### 9. Record the rationale and review point</p><p>Record the context, choice, assumptions, and expected consequences. Add the date and the condition that should trigger reconsideration.</p><p>AWS’s Architectural Decision Record guidance uses this structure because teams otherwise rediscover the same question without the original reasoning. A later decision can supersede an earlier one. It should not quietly rewrite history.</p><p>This is not bureaucracy for its own sake. It prevents a changed outcome from being mistaken for a failed process. The earlier decision may have been reasonable under the evidence available at the time. The record lets the team see what changed.</p><p>### A composite example</p><p>Imagine a technical startup considering a custom enterprise feature before a financing milestone.</p><p>The request is real. The deadline is real. The engineering cost is not yet fully known. Customer evidence looks promising but remains incomplete. The work may affect security review, milestone timing, and the team’s ability to finish a committed product path.</p><p>A Logic Layer does not answer the question automatically. It makes the question harder to misunderstand.</p><p>The Decision Contract might name the product leader as owner, require security input, define the milestone that must be protected, list the necessary engineering and customer evidence, and specify a reversible discovery step before full delivery. It might cap exploratory effort, identify the signal that justifies continuing, and send the choice back to the founder and board if it materially affects cash or the milestone.</p><p>No invented conversion rate. No fictional customer. The point is to expose the reasoning before the company spends its way into a conclusion.</p><p>### What the founder still owns</p><p>The Logic Layer is not an argument for pushing every choice downward.</p><p>Some decisions should remain central because they involve existential risk, fiduciary responsibility, safety, regulation, or a conflict the local team cannot resolve.</p><p>The empirical evidence on decentralization is also narrower than startup folklore suggests. Research by Aghion, Bloom, Lucking, Sadun, and Van Reenen found that firms with more delegated authority before the Great Recession outperformed more centralized counterparts in sectors hit hardest by the shock. That supports a conditional trade-off, not a universal decentralization rule. The research is not startup-specific.</p><p>The founder’s job shifts from running the answer desk to designing the boundary conditions.</p><p>You decide which choices stay close to the centre. You make sure owners have the information and capability to act. You review decisions that cross the line. You also accept that a documented decision may differ from the one you would have made with the same information.</p><p>That last part is where the heroics tend to walk back into the building.</p><p>If you reopen every decision because the team did not reproduce your instinct, you have not delegated. You have built a delayed approval process with better branding.</p><p>### Start with one recurring decision</p><p>Do not launch a company-wide Logic Layer programme. The phrase alone should make your burn-rate instincts twitch.</p><p>Choose one recurring decision that consumes founder attention: pricing exceptions, enterprise feature requests, hiring against a milestone, reliability work versus roadmap work, or a recurring spend approval.</p><p>Write the contract. Run it once. Notice what people still misunderstand. Tighten the owner, evidence, threshold, or escalation condition. Record the outcome and the reasoning. Then reuse the format where the same pattern appears.</p><p>The first useful result is not faster decision-making. It is <strong>less hidden decision-making</strong>. You can see where judgment lives, what the company is optimizing, and which choices still depend on one person.</p><p>That visibility offers something better than founder heroics: a company that can learn from its own decisions.</p><p>If every meaningful choice still routes back to you, the problem may not be a lack of initiative. The team may be missing the logic that defines a good decision, what it must protect, and when it is theirs to make.</p><p>Build that layer before the queue becomes the company.</p><p>For the previous step in this series, read <a href="https://www.linkedin.com/pulse/you-hired-leaders-why-still-every-escalation-path-maciejewski-h1gze/" target="blank" rel="noopener noreferrer">"You hired leaders. Why are you still every escalation path?"</a>. It examines the ownership layer that must exist before decision logic can travel.</p><p>Rob</p><p><strong>P.S.</strong> Which recurring decision in your company still depends on your memory, instinct, or inbox availability?</p><p>If you want help installing decision logic across your operating system, learn more at <a href="https://www.FluentFounder.com/" target="blank" rel="noopener noreferrer">www.FluentFounder.com</a>.</p><h2>References</h2><ul><li><a href="https://handbook.gitlab.com/handbook/people-group/directly-responsible-individuals/" target="blank" rel="noopener noreferrer">GitLab: Directly Responsible Individuals</a></li><li><a href="https://media.bain.com/Images/BAINBRIEFDecisionInsightsThefivestepstobetterdecisions.pdf" target="blank" rel="noopener noreferrer">Bain: The five steps to better decisions</a></li><li><a href="https://www.atlassian.com/team-playbook/plays/daci" target="blank" rel="noopener noreferrer">Atlassian: DACI</a></li><li><a href="https://www.nasa.gov/reference/6-8-decision-analysis/" target="blank" rel="noopener noreferrer">NASA: Decision Analysis</a></li><li><a href="https://www.aboutamazon.com/news/company-news/2016-letter-to-shareholders" target="blank" rel="noopener noreferrer">Amazon: 2016 Letter to Shareholders</a></li><li><a href="https://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-decision-records/introduction.html" target="blank" rel="noopener noreferrer">AWS: Architectural decision records</a></li><li><a href="https://www.nber.org/papers/w23354" target="blank" rel="noopener noreferrer">NBER Working Paper 23354</a></li><li><a href="https://carta.com/uk/en/learn/resources/kpi-template/" target="blank" rel="noopener noreferrer">Carta KPI template</a></li><li><a href="https://www.oecd.org/en/publications/g20-oecd-principles-of-corporate-governance-2023ed750b30-en/full-report/component-7.html" target="blank" rel="noopener noreferrer">G20/OECD Principles of Corporate Governance 2023</a></li><li><a href="https://www.linkedin.com/pulse/you-hired-leaders-why-still-every-escalation-path-maciejewski-h1gze/" target="blank" rel="noopener noreferrer">Fluent Founder Episode 8: You hired leaders. Why are you still every escalation path?</a></li></ul><hr>
