Founder decision-making rules: Define decisions as clear questions with deadlines; ASIC requires formal resolutions for consequential choices in Australian companies; Record decisions with reasoning, review conditions and key uncertainties
Image: Startup Operations Guide

Operating Cadence

Founder decision-making

A practical way for founders to frame decisions, assign authority, weigh consequences and evidence, then communicate and review the choice.

For a consequential operating decision, define the choice, identify who may make it, weigh evidence and consequences, and set a review point. Routine choices can stay with an owner acting within agreed authority.

Frame the choice

Write the decision as a question with a deadline. “Should we offer this customer a different delivery date?” is clearer than “Discuss delivery”. State the current position, available options and any constraint each option must meet. Include waiting only if it is a real option, and say what waiting would mean.

Separate the decision from the work that follows. One person may gather information, another may make the authorised decision, and another may carry it out. Ask what outcome the choice protects, so disagreement about the goal is not mistaken for disagreement about an option.

Match the effort to the consequences

Reversibility is one factor in how much scrutiny a choice needs; see the supporting article for a detailed assessment.

Agree which choices an owner can make within existing limits and which need further approval. For an Australian company, check the applicable constitution or replaceable rules and any required resolution. ASIC says a consequential choice may need a formal resolution rather than only an informal record.

The right kind of resolution must be used, and the vote must follow the relevant meeting rules. ASIC says a resolution that does not follow those rules may be challenged. An informal agreement between founders does not replace a required company process.

ASIC states that a valid resolution must be entered in the company’s records within one month of the vote and included in minutes signed by the chair of that meeting or the next meeting. Ordinary resolutions require a simple majority—more than 50% of votes—and companies do not need to notify ASIC when they pass one.

Formal vs Informal Decision-Making in Australian Companies

  • Formal ResolutionRequired for consequential decisions; must follow company constitution or replaceable rules under ASIC guidelines
  • Informal AgreementNot sufficient for consequential decisions; does not replace legal company processes
  • Resolution TypeOrdinary resolution requires >50% of votes; no ASIC notification needed
  • Recording RequirementMust be entered in company records within one month and included in signed minutes

Australian Business Decision Compliance Facts

ASIC Resolution Recording Deadline
Within one month of vote
Vote Threshold for Ordinary Resolution
More than 50% of votes cast
No ASIC Notification Required
For ordinary resolutions

Put authority and input in the right places

Name the person authorised to make this particular decision. Identify who will assemble the facts, whose knowledge is needed and who must hear the result. One person can fill several of these roles in a small team.

If founders disagree, check the existing authority before debating who should have the final say. Where it is unsettled, agree on a valid route for this decision or follow the applicable governance or dispute process. Give contributors the question and a deadline for useful input; consultation need not leave a routine decision open indefinitely.

Atlassian’s DACI framework is one way to make the distinction between the person who decides and those who contribute or need to be told explicit, so that consultation is not mistaken for shared approval.

Decide with visible uncertainty

Separate confirmed facts from estimates and assumptions. A customer enquiry shows interest, but does not establish demand or delivery capacity. If information that could change the choice can arrive before the deadline, assign someone to obtain it. Otherwise, consider a smaller commitment or a delay.

A hypothetical team considering a new service after two customer enquiries could authorise a limited proposal, subject to a capacity check before accepting work. Approval of the proposal would not show that the service had succeeded.

Preserve the reasoning as decisions evolve

For significant software architecture choices, AWS Prescriptive Guidance describes an architectural decision record (ADR) that captures the decision’s context, the choice and its consequences for the project and deliverables. The guidance emphasises recording why the team chose an option, rather than focusing only on how it was implemented.

A collection of ADRs can act as a decision log: project members can scan headlines for context and read individual records for design and implementation detail. This is especially relevant when a choice affects architecture, security or other non-functional requirements, dependencies, interfaces, or construction techniques such as libraries and frameworks.

AWS guidance treats an accepted ADR as immutable. If new information calls for a different choice, the team proposes a new ADR; once accepted, it supersedes the earlier one. That leaves the original reasoning available while making the current decision clear.

Using ADRs (Architectural Decision Records) for Technical Decisions

  • ProsCaptures rationale behind choices; supports long-term project continuity; enables auditability and learning across teams
  • ConsRequires discipline to maintain; can become outdated if not reviewed; may add overhead for small or low-risk decisions

Close the loop

Record the choice, decision-maker, date, main reason, material uncertainty and review condition. Give the resulting actions owners and tell affected people what changed.

When a premise changes or a review point arrives, compare the new information with the original reason. Keep, adapt, pause or replace the decision, then make the current position clear.

In this guide

  1. Recording decisions that are likely to be revisitedChoose which founder decisions need a record, capture their reason and review trigger, and show clearly when a later decision replaces them.
  2. Assigning a decision owner when founders disagreeSettle who may make a disputed founder decision by checking existing authority, defining the question and agreeing a valid escalation route.
  3. Distinguishing reversible from hard-to-reverse decisionsTest the real cost of undoing a choice, then choose a bounded trial or a more careful approval path according to its consequences.
  4. Reviewing an assumption after new evidence appearsCompare new observations with the assumption behind a decision, assess uncertainty and decide whether to keep, change or replace the choice.

More from Operating Cadence