Framework 1
Founder Dependency Index
The Founder Dependency Index is a 3-question, 60-second diagnostic that measures how much a company depends on its founder.
How fragile is your company?
How many decisions require the founder? How many exceptions? How many client relationships would be at risk if the founder was unreachable for two weeks? The FDI measures the invisible dependency a company has on one person. Three questions. Sixty seconds. One number that tells you the truth.
The real-world symptom
The founder cannot take a vacation without the phone ringing. The team escalates everything. The founder is the approval layer, the exception handler, and the relationship holder all at once.
What founders mistake it for
"I just need to hire a COO." "My team needs more training." "We need better project management software." These are downstream symptoms. The FDI measures the upstream dependency.
- · Podcast: Founder Dependency series
- · Founder Notes: Why Most Founders Build Their Own Cage
- · The Moron Test: Law 1 (Users Feel Like Geniuses)
Take the FDI →Framework 2
The Dependency Cascade
The Dependency Cascade is the four-stage path from complexity to dependency to compensation to fragility that every failing system follows.
Complexity → Dependency → Compensation → Fragility.
The four-stage path every system follows when it fails the Moron Test. Complexity accumulates. Dependency forms around specific people. The team compensates with workarounds. The company becomes structurally fragile. The cascade is invisible because each stage looks like something else: complexity looks like sophistication, dependency looks like expertise, compensation looks like teamwork, and fragility looks like growing pains.
The real-world symptom
The company runs on tribal knowledge, side spreadsheets, and Slack threads. When a key person leaves, entire processes stall. The official system and the actual system are two different things.
What founders mistake it for
"We just need better documentation." "The team needs to communicate better." "We're growing too fast." These describe compensation, not the root cause. The cascade starts at complexity.
- · The Moron Test: the canonical diagram
- · Podcast: Episode 12
- · Related: Invisible Fragmentation, Operational Load Theory
Framework 3
Operational Load Theory
Operational Load Theory is the principle that every new dollar of revenue adds load the operating system has to carry.
Revenue is not strength. Revenue is load.
Growth without structure does not build a stronger company. It builds a heavier version of the same problem. Revenue rises. Operational capacity rises slower. The widening gap between the two is load. Load is invisible because revenue hides it. The founder feels the weight but cannot name it. Operational Load Theory names it.
The real-world symptom
Revenue is growing but the founder is more exhausted than ever. The team is bigger but decisions are slower. Margins are thinning even though the top line looks great. Every new client adds weight instead of value.
What founders mistake it for
"We need more people." "We're just going through growing pains." "Revenue fixes everything." Revenue does not fix load. Revenue IS load. Structure fixes load.
- · Podcast: Episode 9 (Revenue Architecture)
- · Founder Notes: Revenue Is Load
- · Related: FDI, Designing Scalable Control
Framework 4
Invisible Fragmentation
Invisible Fragmentation is the gap between owning tools and having a working system, where the founder becomes the integration layer.
The gap between "we have a system" and "the system works."
Most companies have tools. They might even have good tools. But the tools do not talk to each other. The CRM does not connect to project management. Project management does not connect to invoicing. The founder becomes the integration layer. The human API. The fragmentation is invisible because each tool works individually. The system fails collectively.
The real-world symptom
The founder is the only person who can pull a complete picture of any client, project, or process. Data lives in six different places. The team spends more time finding information than using it.
What founders mistake it for
"We need a better CRM." "We need to consolidate our tech stack." "We need an integration platform." These address the symptom. Invisible fragmentation is an architecture problem, not a tool problem. Adding another tool often makes it worse.
- · Podcast: Episodes 10, 8
- · The Moron Test: Law 3 (Highly Personal)
- · Related: Dependency Cascade
Framework 5
The Bottleneck Cascade
The Bottleneck Cascade is the sequence of constraints that only becomes visible as each layer of constraint is removed.
Fixing one thing reveals the next.
Every company has a primary constraint. Most consultants find it and fix it. Then they leave. The problem: removing the primary constraint surfaces the secondary constraint. And removing that one surfaces the third. The bottleneck cascade is the sequence of constraints that only becomes visible as each layer is removed. Mapping the cascade before touching anything is the only way to avoid solving yesterday's problem.
The real-world symptom
The founder fixes the biggest bottleneck and nothing improves. Or worse, a different problem surfaces that was hidden by the first one. The team loses confidence in the improvement process.
What founders mistake it for
"We fixed the bottleneck and nothing changed." "It feels like whack-a-mole." "Every solution creates a new problem." These describe the cascade. The cascade is not a failure of the fix. It is a feature of complex systems. It must be mapped, not fought.
- · Related: Dependency Cascade, Founder Dependency Index
Framework 6
Designing Scalable Control™
Designing Scalable Control is the master operating system framework built on one number, one owner, and one cadence per function.
One number. One owner. One cadence.
The master operating system framework. One number per function (the metric that tells you whether it is healthy). One owner per decision (single-threaded accountability, not committees). One cadence per review (the rhythm that makes the system self-correcting). These three elements replace the founder as the operating system. The founder stops being the metric, the decision-maker, and the review mechanism. The system carries those functions instead.
The real-world symptom
The founder is involved in every review, every decision, and every metric interpretation. The team cannot tell whether a function is healthy or unhealthy without asking the founder. There is no rhythm to operational review; it happens when something breaks.
What founders mistake it for
"We need more meetings." "We need better KPIs." "We need clearer roles." These are all components of the framework but they fail individually when they are not connected by the three-element architecture: metric, owner, cadence.
- · Podcast: Episodes 9, 7
- · Founder Notes: Hustle Is Not a Strategy
- · Related: FDI, Operational Load Theory
Framework 7
The Moron Test
The Moron Test is the discipline of three laws and one question that every system must pass before it ships.
Will this work the first time, without instructions, without heroics, and without complexity?
The discipline applied to every system before it ships. Three laws: users feel like geniuses, no instructions needed, highly personal. The test catches dependency at the design stage, before it calcifies into architecture. If the system requires the builder to be in the room, it has failed the test.
The real-world symptom
New hires cannot do their jobs without weeks of shadowing. The CRM has fields nobody understands. The scheduling system only works on desktop. The onboarding process requires the founder to walk through it personally every time.
What founders mistake it for
"My team just needs more training." "The system works fine, people just need to learn it." "We need better documentation." If the system needs training, documentation, or explanation, it has failed the Moron Test. The system should be the documentation.
- · Dedicated page: /the-moron-test
- · Podcast: Episode 8
- · Hall of Failed Systems: living archive of failures
Read the philosophy →Framework 8
Communication Is Infrastructure
Communication Is Infrastructure is the principle that communication failures are architecture failures, fixed with protocols instead of culture work.
Most companies think communication is culture. It is infrastructure.
Communication failures are architecture failures. When the team does not know what is happening, when decisions are made in hallway conversations that never reach the people who need them, when the same question gets asked three times because the answer lives in one person's head, that is not a culture problem. That is a missing communication protocol. Protocols are infrastructure. Infrastructure either works or it does not.
The real-world symptom
Important decisions are made in conversations that never get documented. The team learns about changes through the grapevine. Meetings end without clear outcomes or owners. Information lives in individual inboxes instead of shared systems.
What founders mistake it for
"We have a communication problem." "We need to work on our culture." "We need better team building." These treat communication as a human behavior problem. It is an infrastructure problem. Build the protocol. The behavior follows.
- · Homepage Doctrine: one of the canonical lines
- · Related: Designing Scalable Control (cadence is a communication protocol)