When the Founder Writes the Procedure

Institutionalizing a company looks like a paperwork job

When a company decides to institutionalize, the first move is almost always the same: an org chart gets drawn, job descriptions get written, a manual gets produced. None of that is the wrong move. The problem is mistaking these steps for institutionalization itself. Building a system on paper and having that system actually hold are not the same thing, and the gap between them only becomes visible the first time the system is put under real pressure.

This confusion shows up constantly in consulting work: writing a procedure gets treated as an engineering problem, when the real difficulty is behavioral. A process is institutional not because it was written down, but because it still holds up the first time it meets a genuine exception.

One pattern keeps recurring in our field notes: rather than handing institutionalization off, the founder turns it into a personal product. They write the procedures themselves, design the processes themselves — and precisely because of that, what they produce never becomes independent of them.

Missing this distinction is expensive, because producing documents is concrete and measurable — how many procedures got written, how many meetings were held, how many pages the manual reached can all be reported. Whether behavior actually changed is only visible over time, usually at the moment of a crisis, and until then everyone assumes the project succeeded.

When the founder writes the procedure, the procedure still carries the founder

A founder who does not yet trust the team's judgment tends to write the most sensitive parts of the business by hand: pricing exceptions, escalation rules for complaints, who can approve which expense. On paper these procedures read as objective rules, but they still carry the trace of whatever specific decisions the founder happened to make on the way to writing them.

A rule is not a substitute for a decision

Take one example: a customer request falls outside standard pricing. Years earlier, the founder answered three similar requests three different ways — one to protect a relationship, one to avoid setting a precedent, one because of that quarter's cash position. The procedure writes down something like an average of those three decisions, but an average is not a rule; it says nothing about which logic applies in which situation. The new manager reads the rule, applies it, and usually applies it at the wrong moment.

So the procedures a founder writes by hand end up doing the opposite of what they were meant to do. Instead of making the organization independent of the founder, they relocate the founder's judgment to the center of the business a second time, now in a form that looks permanent. The process has made it onto paper, but the organization's real point of reference is still the same person.

There is a way around this, but it is not more documentation — it is less of the founder's own hand. Rather than writing the procedure themselves, having the founder first articulate the decision out loud — which principle applies in which situation, worked through with someone else using real examples — gives the procedure a better chance of becoming independent of them. The difference looks small but the outcome is not: one substitutes the rule for the founder; the other transfers the reasoning behind the rule.

The difficulty isn't technical; it's whose judgment gets written down

Most institutionalization projects get framed as system-building projects: a CRM, an approval workflow, a reporting calendar. None of that is unnecessary. But that is not where the real difficulty sits — the difficulty is whose judgment, on whose behalf, ends up encoded inside the system.

The same symptom, three different sources

The difficulties we see in the field tend to repeat in the same three shapes:

• A new manager applies the procedure to the letter and never learns the reasoning behind it.
• The founder still steps in on every exception even though the procedure exists, sensing that the procedure cannot carry their judgment.
• The team stops looking for the right answer and starts guessing what the founder would do in this situation, which quietly makes the procedure irrelevant.

What these three patterns share is that none of them comes from bad intent. The new manager is being careful, the founder is being responsible, the team is being respectful. The difficulty is that while everyone is trying to do the right thing, the system itself rewards the wrong one: applying the letter, stepping in personally, and guessing all look like they work in the short run, which is exactly why none of them ever gets questioned.

All three trace back to the same root: what got written down is not a principle but a photograph of one decision, and photographs do not fit new situations.

The system becomes visible in who resolves the exception

The most reliable way to tell whether institutionalization has actually happened is not to read the manual. It is to watch who gets called the first time a situation falls outside what the manual covers.

The test itself is simple

The question is this: when an exception comes up, does the organization resolve it on its own logic, or does it still check with the founder? If the answer is the latter, institutionalization has not happened yet, no matter how correctly everything on paper was written.

This is the same pattern behind the observation that a professional CEO earns authority not by announcing it but by having it confirmed again and again — the difference here is that authority is being transferred to a system rather than to a person. A system, like a person, earns trust not by declaring it but by holding up when it is actually tested.

Another way to see this is through the sequencing we describe in why handover is never just a single signature: which decision gets let go first, and which gets let go later, decides how seriously the organization will take the new system the first time an exception arrives.

What makes this test hard to run is that the outcome is usually disguised as good intent. When the founder steps in, it reads as help rather than oversight, and the team accepts it as natural, because the founder's help genuinely does work. What signals that the system is not yet built is not the help itself — it is that the help keeps coming from the same person every time.

From the field

We once worked with a founder whose company had been running an institutionalization project for three years; the manual had grown to two hundred pages. But the first time a serious customer crisis hit, the team called the founder anyway, because the manual did not describe that crisis and no one actually felt authorized to act on their own judgment.

What we talked about there was not procedure. It was which decisions the founder needed to knowingly let go of, and which mistakes the organization needed to be allowed to make in order to build its own judgment. Institutionalization moved forward in that company not through a better document, but through the founder stepping back at the right moment.

What we took from that engagement was that institutionalizing is not a milestone but a habit: a habit of the founder deliberately choosing, week by week, which decision to let go of this time. The document gets written once; that choice gets made again every week.

Requesting a conversation starts with mapping, together, which decisions in your organization still come to you, and which have actually been handed off.