What changes is not the title, it is which question comes to the founder
Someone watching a company institutionalize usually looks for the change in the founder's role at the title line — CEO becomes Board Chair, the corner office gets smaller. Those changes are real, but they are secondary. The actual change happens somewhere quieter: in which question reaches the founder's desk on an ordinary day.
In a company's early years the founder is the answer to almost every question that matters — which vendor to keep, which customer gets a discount, which hire clears budget. All of it lands on the same desk, because there is no other desk for it to land on. As the company institutionalizes, those questions move one at a time to other desks, and the founder often does not notice, because there is no ceremony that marks when the role itself has changed.
The shift happens in three functions, not one moment This piece treats the change in a founder's role not as a single handover but as three distinct functions arriving one after another — each running on its own logic, each with its own end point. Most of what makes transformation hard here is that the three get confused with each other: a founder keeps behaving like the previous function after it should have ended, or stalls in it when the next one is already due.
Three functions: deciding, bounding, and reading the signal
The first function is deciding. At this stage the founder answers every significant question directly, because the company's size and the organization's inexperience require it. The founder is fast and usually right here, because the information is fresh and the founder personally carries the outcome of the call.
The second function is bounding. The founder no longer makes individual calls; instead the founder defines which range belongs to whom — finance clears spend under a set amount, the sales lead sets discounts up to a set size, anything above goes to the founder. The founder's daily work is no longer deciding, it is drawing that range correctly and redrawing it when it stops fitting.
The third function is reading the signal. The founder no longer decides individual cases or draws ranges; instead the founder watches for the early marks that the system itself needs to change — which range keeps getting exceeded, which decision keeps traveling back upward, which rule now describes the past rather than the present.
- The question the deciding function answers: What should be done?
- The question the bounding function answers: Who can decide, and up to what point?
- The question the signal-reading function answers: Is the system still working?
All three functions are still about deciding something, but each decides a different object — the first decides the case, the second decides the range, the third decides the system itself.
What delays the shift is the same thing every time: comfort in the previous function
A founder who stays in the deciding function — still pulling individual calls onto their own desk when bounding is what the stage calls for — becomes the company's bottleneck as it grows. Because every decision waits on approval, the organization's speed is capped at the founder's own daily capacity; the company has grown, the decision rate has not.
Staying too long in the bounding function is its own mistake The reverse also happens. A founder stays in the bounding function too long — still defining ranges, still logging exceptions one at a time — when the organization has already reached the maturity to produce its own ranges. Here the founder's daily involvement is not a contribution, it is a delay; the organization could write its own rule but keeps waiting on approval, because the founder still treats that work as their own.
The piece on which judgment gets written into a procedure is about a related but earlier question — whose judgment ends up on the page. Here the question is one step earlier still: whether the founder even knows which function they are currently in. The two sit on different floors of the same process, one about the content of the rule, the other about the founder's own position relative to it.
A founder who has not moved into the signal-reading function sees the moment the organization starts outgrowing its own rules too late, because the founder is still looking at individual exceptions rather than the pattern they form. A founder who changed function too late may still be doing the right work — just at a stage it no longer belongs to.
A founder who changed function too late may still be doing the right work — just at a stage it no longer belongs to.
The end point of a transition is not a date, it is a test
When to move from one function to the next is not settled by a date; it is settled by a specific test, and the test is different for each transition.
The test for moving from deciding to bounding is this: once a team member's call in a gray area has matched the call the founder would have made, several times in a row, the range is already ready to be written down — it already exists in the organization's practice even before the founder names it; naming it is the only step left.
The test for moving from bounding to signal-reading is different: once the same range starts being exceeded in more than one team, independently and in the same direction, the issue is no longer one exception to resolve — it is that the range itself no longer reflects the present. If the founder keeps approving each exception individually at this point, a signal that belongs at the level of the system gets absorbed one case at a time and disappears.
Skipping a function entirely creates its own failure. Some founders, following advice about delegation, try to move straight from deciding to signal-reading — "let go, trust the system" — without ever going through bounding. But because no range was ever written, what the system inherits is not a rule, it is a gap; a founder trying to read signals is actually still standing in a stage that needed bounding, and what looks like a signal is only evidence of a boundary that was never drawn.
Misreading either test carries an asymmetric cost. A founder who applies the first test too early — writing the range before the organization can carry it — hands over autonomy the organization cannot yet support, and mistakes multiply. A founder who applies the second test too late keeps ignoring a reality that has already shifted; the rule still stands on paper while the practice has already abandoned it. Both errors trace back to the same thing: moving on a calendar instead of on the test itself.
From the room
In the coaching room this difference usually surfaces through one question: "This past month, how many individual calls did you approve, how many ranges did you redraw, and how many times did you do neither and just notice a pattern?" Most founders count these three numbers there for the first time.
For some the count is a relief, because a flaw they had attributed to themselves for years — "I can't let go" — turns out to be a misdiagnosis; what they were doing was the right function running late, not an abandoned habit. For others it is uncomfortable, because the count shows that someone who believed they had moved into bounding is, in practice, still deciding.
The answer usually contradicts the story the founder has been telling themselves — someone who still describes themselves as the decider may have spent most of the past month bounding or reading signals, or the reverse: someone who believes they have stepped back may still be pulling every significant call onto their own desk. Until that gap closes, institutionalization runs on two tracks — the story the founder tells and the reality the organization is living — rather than one.
Requesting a conversation starts with counting those three numbers together — which function the founder is actually in today, and which one the organization is already waiting for.