The Founder Needs to Stop Being the Operating System
The Difficult Problem
Important decisions, exceptions, customer knowledge, and informal approvals all route through the founder. The arrangement once created speed, but now limits scale and makes the organization fragile.
Executive problems rarely arrive as clean questions. They arrive as missed targets, competing explanations, urgent requests, and partial information. A useful diagnosis must distinguish the visible symptom from the mechanism creating it. It must also identify what is not yet known, because confident action based on a weak premise can make the situation harder to reverse.
The purpose of this framework is not to replace the knowledge of people inside the organization. It is to create a disciplined way to combine that knowledge, expose conflicts, and decide what deserves scarce executive attention. The output should be a small number of owned actions and measures, not another presentation that describes the problem without changing it.
The first operating question is what must remain true while the problem is being solved. That may be liquidity, customer continuity, safety, a regulatory obligation, critical talent, or the ability to reverse a decision. Naming those constraints prevents a fast intervention from destroying the capacity needed for recovery.
The second question is where authority and information meet. A person cannot own an outcome if the essential information arrives late or another function controls every meaningful choice. A useful problem map therefore shows decisions, handoffs, dependencies, measures, and escalation thresholds, not only reporting lines.
Finally, the team needs a learning loop. The initial diagnosis is a working explanation, not a performance of certainty. Each action should produce evidence. Leaders should decide in advance what result would support the explanation, what result would weaken it, and when they will reconsider the plan. That discipline makes speed compatible with intellectual honesty.
What Leaders Usually Get Wrong
- Demanding delegation without transferring context or decision rights
- Adding management layers while preserving every founder approval
- Automating a workflow whose rules still exist only in the founder's head
These errors are understandable because each offers the appearance of movement. The test is whether the action changes the mechanism sustaining the problem, preserves necessary options, and creates evidence that the diagnosis is correct.
How I Would Diagnose It
Identify the decisions and exceptions that repeatedly return to the founder.
Separate decisions requiring founder judgment from those returning because information, authority, or standards are missing elsewhere.
Document the signals the founder uses, including thresholds and unacceptable risks.
Look for roles that carry responsibility without the information or permission required to act.
Before recommending a larger change, I would run a short operating review with the people closest to the work. The purpose is to compare the formal process with what actually happens, identify exceptions and workarounds, and locate the decision where delay or rework first appears. I would record disagreements rather than average them away, because a disagreement often reveals that teams are optimizing different outcomes. The resulting map should make clear which observation is verified, which is an inference, which assumption needs a test, and what decision can safely be made now.
I would then ask what evidence could disprove the leading explanation. That question protects the team from building a confident plan around the most convenient story. The diagnosis should state assumptions, missing information, and triggers that would change the recommended course.
Simple Action Framework
- 1. Inventory recurring founder decisions
- 2. Define decision rights and escalation thresholds
- 3. Transfer context through operating reviews and examples
- 4. Give owners measures and consequences
- 5. Remove founder approval gradually and test the system
Each action needs an owner, a near-term decision date, and a measure that reveals whether the intervention is working. Measures should describe the outcome or bottleneck, not simply report that meetings occurred or tasks were completed.
The goal is not to remove the founder from the business. It is to reserve founder attention for decisions where it creates distinctive value.
Related work
Watch and read Daily Difficult Problems for short examples of the same diagnostic approach.
Discuss a Difficult Problem
If the issue is consequential, cross-functional, or difficult to diagnose from inside the operating system, start with a bounded conversation.
Bring Me the Difficult Problem