Decision Infrastructure
A plain-language method for moving operational clarity out of the founder's head and into the business. Three components: where decisions sit, how standards are held, and how authority flows.
A plain-language method for moving operational clarity out of the founder's head and into the business. Three components: where decisions sit, how standards are held, and how authority flows.
01
<p><strong>Version:</strong> 1.0 <strong>Status:</strong> Published</p> <h2>The problem this framework addresses</h2> <p>When a business grows beyond the founding team, operational clarity — the shared understanding of how things work, what the standards are, and who is authorised to decide what — does not scale automatically. In most businesses, it lives informally in the founder's head and in the institutional memory of early employees. It works until the business gets large enough that people who were not there at the beginning need to operate without constant guidance. At that point the informal system fails.</p> <p>The result is inconsistency, repeated escalations, and the founder being pulled back into operational decisions they thought they had moved on from.</p> <p>This framework addresses that. It requires building three things in sequence.</p> <h2>Component 1 — Decision location</h2> <p>Not all decisions need to sit with the same person. The first component is mapping which decisions should be made at which level, and then making that explicit.</p> <p>Most businesses have never done this. Decisions accumulate at the top by default because there is no system routing them anywhere else. The mapping exercise surfaces that accumulation and identifies where decisions can move without reducing quality.</p> <p>The output is a simple, written record of what type of decision sits where. It does not need to be exhaustive. It needs to cover the decisions that currently take up the most time and generate the most uncertainty.</p> <h2>Component 2 — Standards</h2> <p>Standards are the written version of how things should be done. They convert informal knowledge — the way the founder does it, the reason early decisions were made the way they were — into something the business can hold and use without the founder being in the room.</p> <p>A standard does not need to be a policy document. It needs to answer three questions clearly: what is the expected output, what is the acceptable range of variation, and what triggers escalation.</p> <p>Standards fail when they are too abstract to use or too rigid to accommodate real variation. Useful standards are specific enough to guide a decision and loose enough to accommodate judgement at the edges.</p> <h2>Component 3 — Authority</h2> <p>Authority is the explicit permission to act. Without it, capable people default to asking, because the cost of overstepping is higher than the cost of escalating. This is rational behaviour in the absence of clarity. It produces a volume of escalations that looks like a capability problem but is actually a clarity problem.</p> <p>The third component is making authority explicit: who can decide what, under what conditions, and what happens at the boundary.</p> <h2>What changes when all three are in place</h2> <p>When decision location, standards, and authority are explicit, the business can operate without the founder resolving routine decisions. The team acts with confidence because the system tells them what to do. Escalations fall to genuine exceptions. The founder's attention is available for decisions that actually require it.</p> <p>This is not a management methodology. It is infrastructure. It does not depend on hiring different people or changing the culture. It depends on making the operating logic explicit enough that it can be used without interpretation.</p> <p><em>This is a v1 framework. It will be updated as it is applied and tested across different types of businesses.</em></p>
02
Apply this framework at the point where informal processes are breaking down under scale. Begin with the diagnostic layer before building any delivery infrastructure.
03
This framework is most effective when a business is transitioning from founder-led to operator-led — typically at the 10–30 headcount inflection point, or when a second layer of leadership is being established.
A founder approaching the point where informal decision-making breaks uses this framework to build the first operating layer — without losing velocity.
An operator bringing structure to a team that has grown past the point of informal coordination deploys this to create consistent, documentable processes.
A business facing commoditisation uses the authority and decision layers to sharpen its operating position and defend market ground.
Documented operating architecture
Decision framework with ownership matrix
Process documentation set
Onboarding and handover materials
Calibration schedule and maintenance plan
Browse the full library for more frameworks.
Let's talk about what you need.