The operating manual for your company

Every company runs on rules. The dangerous ones are the rules nobody wrote down — the unwritten conventions about who really decides things, what the culture actually rewards, and which processes exist on paper only. When those rules live only in founders' heads, every new hire spends their first ninety days doing archaeology. The operating manual that makes a company scalable is not an HR document. It is a live description of how the company actually works.

The archaeology problem.

Walk into a 40-person startup that has been operating for three years and ask any employee hired in the last six months: "How does a major product decision get made here?" You will get different answers depending on who you ask. Some will describe the formal process. Some will describe what actually happens. A few will admit they are still figuring it out.

This is not a culture problem. It is a documentation problem, and it compounds. Every new hire who fails to absorb the real rules in their first 90 days operates at reduced effectiveness for months. They either move too slowly because they are uncertain who needs to sign off on things, or they move too fast and step on someone's toes and have to repair the relationship. Both outcomes are expensive.

The founders, meanwhile, are answering the same questions over and over — or worse, not answering them, because they assume the company has communicated what it has only demonstrated. Demonstrated knowledge transfers well when the team is eight people in one room. It transfers poorly when the team is forty people across three time zones.

The operating manual solves this by making the implicit explicit. Not as a compliance exercise, but as a genuine act of organisational engineering.

What an operating manual actually contains.

The confusion starts with what the document is supposed to do. Most founders who attempt this build something between an employee handbook and a culture deck — long on values, short on mechanics. That document is not useless, but it does not solve the archaeology problem. The archaeology problem is solved by describing mechanics.

A functional operating manual has five components. First: a decision rights map. For every category of decision the company makes regularly — hiring, firing, pricing, partnerships, product scope, budget allocation — the manual names who has authority to decide unilaterally, who must be consulted before the decision, and who must be informed after. This is not the same as the org chart. The org chart describes reporting lines. The decision rights map describes authority, which often runs differently.

Second: the meeting architecture. Which meetings exist, what their purpose is, who attends, and what outputs they are expected to produce. This sounds mundane but is one of the highest-leverage things to document. When the meeting architecture is unclear, people schedule new meetings to compensate, and the calendar fills with conversations that should be decisions.

Third: the planning and review cadence. When does the company set annual targets? When does it review against them? Who is in the room? What does a good quarterly review look like versus a bad one? What triggers an off-cycle review? This is where strategy meets operations, and it is almost never documented.

Fourth: the resource allocation process. How does headcount get approved? How does budget get moved between teams? What is the process for a new initiative to get funded? In most startups this happens through informal conversations with the CEO, which is fine until the CEO is in twelve conversations simultaneously and decisions start getting made without them.

Fifth: the norms that define the culture in operational terms. Not "we value transparency" but "we share internal metrics with all employees in the Friday all-hands and anyone can ask about any number." Not "we move fast" but "the default answer to a request for a new tool or process is yes, and the person who says no has to explain why." These are the rules that actually govern behaviour, and they need to be written down in the language of behaviour, not values.

The live document problem.

The operating manual that is written once and never updated is worse than no operating manual, because it creates false confidence. People refer to a document that describes how the company worked eighteen months ago and wonder why the actual behaviour does not match.

The manual needs a maintenance architecture as deliberate as its creation. Practically, this means three things. Someone owns it — a named person whose job includes keeping it current, not a committee. There is a regular review cycle — at minimum annually, ideally at each significant organisational inflection like a funding round or a leadership change. And there is a lightweight amendment process — any team member can propose a change, proposals are reviewed by the owner, approved changes are versioned and announced.

The versioning matters more than most people expect. When an employee joined six months ago and the decision rights for product scope have changed since then, they need to know the current version, not the version that was accurate when they were onboarding. A short changelog at the top of the document — "version 3.2, updated March 2026, changed: product scope decisions now require VP Engineering sign-off in addition to VP Product" — makes this trivial to track.

Some companies use Notion, some use Confluence, some use a simple Google Doc. The tool is irrelevant. What matters is that it is in one place, everyone knows where that place is, and it is kept current.

The shadow manual problem.

Here is the harder challenge. Most companies that attempt this exercise discover, in the process of writing it down, that there is a gap between the official version of how the company works and the actual version. The decision rights map says the VP of Product owns product roadmap decisions, but in practice the CEO reviews every major decision before it goes to the team. The meeting architecture says the weekly leadership sync is for cross-functional alignment, but in practice it is where the CEO makes announcements and the team listens.

When you find these gaps, you have a choice. You can write the manual to describe what is actually happening — which makes the founder's informal authority explicit and sometimes uncomfortable. Or you can write the manual to describe what should happen — and treat the gaps as things to fix. The second approach is more useful but requires the founder to actually change their behaviour, which is the hard part.

The shadow manual — the unwritten actual system — often persists because founders have not processed that their role has changed. What worked when the company was eight people is not just unnecessary at forty people; it is actively harmful. When the CEO informally overrides VP-level decisions, the VPs learn not to make real decisions, and you end up with a leadership team that is good at presenting options and waiting for approval rather than good at deciding. That is the opposite of what a scaling company needs.

Where founders underinvest.

The parts of the operating manual that most founders skip or underspecify are the ones that feel politically sensitive: explicit escalation paths for disagreements, the process for removing someone from a decision-making role, and what happens when the company's actual behaviour violates its stated norms. These are the places where the document needs to be most specific and usually ends up most vague.

Write the escalation paths. If a product manager and an engineering lead disagree about scope and cannot resolve it in two conversations, what happens next? Does it go to the VP Product? The CEO? A committee? If it is ambiguous, it will default to whoever argues longest, which is a terrible selection mechanism. Specify it.

Write the norm violation process. If the company says it values direct feedback and someone in a leadership position is consistently not giving it, what happens? If the answer is "nothing, unless it becomes a performance management issue eventually," then the norm is aspirational rather than operational. Operational norms have consequences.

• 01
  Map decision rights, not just reporting lines. For every recurring decision category, name who can decide unilaterally, who must be consulted, and who must be informed. The org chart and the decision rights map will look different. That difference is information.
• 02
  Document the meeting architecture before you inherit a bad one. Every meeting should have a named purpose, named outputs, and a named owner. If a meeting cannot pass that test, cancel it rather than document it.
• 03
  Write norms in the language of behaviour, not values. "We value transparency" is a value statement. "We publish all department-level OKR scores to the full company every quarter" is a norm. Only the latter is enforceable.
• 04
  Name a single owner and a review cadence. A document owned by everyone is maintained by no one. Assign it to a person. Set a quarterly review for fast-growing companies, annual for stable ones.
• 05
  Close the gap between the official manual and the shadow manual. If there is a significant difference between how the document says decisions get made and how they actually get made, that gap is the most important thing to fix — not in the document but in the actual behaviour.
• 06
  Specify escalation paths explicitly. Vague escalation paths default to whoever argues loudest or longest. That is a terrible selection mechanism. Write down exactly what happens when two people with legitimate authority disagree.

The onboarding dividend.

The most immediate return on the operating manual is in onboarding. A new VP or senior hire who has access to a current, accurate operating manual in their first week can compress the standard 90-day orientation into something significantly shorter. They know from day one who owns what, what the cadence is, and what the unspoken norms are — because you have written the unspoken norms down.

This compounds at scale. A company that can onboard senior hires effectively has a structural advantage in recruiting because the offer of clarity is itself valuable to experienced operators who have lived through ambiguous environments. The operating manual, when it is good, becomes a recruiting asset.

More importantly, it makes the company less dependent on the founder's presence for basic operational coherence. When the CEO is travelling for two weeks and a non-trivial decision needs to be made, the team can look at the manual and figure out who makes it rather than waiting. That is not a small thing. That is what scaling actually means.

Frequently asked questions.