Current engagement

FF90

Founder Freedom in 90 Days

A 90-day operating engagement for agency founders who want the company to rely less on their attention, memory, approvals and exception handling.

We identify and remove the operational dependencies that keep your agency unnecessarily tied to you.

Your agency should not stop because you stop answering Slack.

Investment: $10,000 / 90 days
Structure: Observation and diagnosis, implementation, stabilization. One month each.

FF90

Video pending

If the first few minutes sound like your company, the rest of this page explains what I do about it.

The founder became the operating system.

An agency can have people, managers, SOPs and tooling and still run on the founder. The org chart says the work is distributed. The day says otherwise, because the parts that are actually load bearing are memory, judgment and attention, and none of those were ever designed.

This is not about being too involved. Founders should be involved in the things only they can do. The problem is when involvement is the mechanism that keeps ordinary operations moving. At that point the company has an operating system, and it is a person.

If every edge case ends with "ask the founder," the system is not finished.

Approvals: Work waits because one person has to look at it before it ships.
Client context: The history of an account lives in the founder's memory, not in a system.
Exceptions: Anything outside the normal case gets escalated by default.
QA: Quality holds because the founder is the last check, not because the process catches errors.
Routing: Requests arrive without an owner and get assigned by whoever knows the most.
Troubleshooting: When a workflow breaks, the fix depends on the person who built it.
Internal questions: Answers that should be written down are asked in Slack instead.
Delivery issues: Slippage is caught by attention rather than by visibility.
Reporting interpretation: The numbers exist, but only the founder can explain what they mean.

What stops working when you stop paying attention?

Who it is for

Built primarily for established agencies. The engagement assumes the commercial side already works and the operating side is what has fallen behind.

Existing clients and existing revenue
An existing team, including people who already own delivery
Proven demand rather than a search for product market fit
Recurring delivery with real operational complexity
Too much founder involvement in ordinary operations
Delegation that has started but has not fully worked

Typical team size is roughly 5 to 30 people. That is a pattern, not a rule.

Observe. Rebuild. Stabilize.

Ninety days, in three parts. Each part depends on the one before it, which is why the engagement is not sold as a document or a workshop.

Month 1 · Observation and Diagnosis

Watch how the agency actually operates, not how it is described in a document.

The first month is spent inside the operation. Calls, threads, handoffs, escalations, delivery cycles, the moments where work stops and waits. The point is to find where founder attention is doing structural work, and why.

What gets examined

Founder dependency
Client delivery
Ownership
Approvals
Handoffs
QA
Meetings
Escalation
Tooling
Automation
Reporting
Recurring decisions
Capacity
Undocumented knowledge

Outputs

01Founder Dependency Map
02Operating Bottleneck Analysis
03Target Operating Model
04Implementation Priorities

What needs to change, in what order, and why?

Month 2 · Implementation

Build the highest-leverage changes the diagnosis identified.

Month 2 is scoped by what Month 1 revealed. No engagement includes every item below, and pretending otherwise would produce a checklist instead of a system. The work goes where the dependency is heaviest and the change holds.

Possible areas

Ownership
Decision rights
Escalation rules
Process architecture
SOPs
Internal systems
QA
Automation
Reporting and dashboards
Client workflows
Meeting cadence
Role clarity
AI-assisted operations where useful

Month 3 · Stabilization

Run the new model under real conditions and fix what real conditions break.

A process that works on paper is not necessarily a process that works on Tuesday afternoon. Month 3 exists because the first version of any operating model meets situations it did not anticipate, and someone has to be there when it does.

What gets fixed

Unclear ownership
Edge cases
Weak handoffs
Bad escalation rules
SOPs nobody uses
Automation problems
Reporting gaps
Remaining founder dependencies
Unnecessary approvals

The goal is an operating model stable enough to keep running without me watching it.

The founder should remain important. Not operationally mandatory.

Before	After
Founder memory	Documentation
Founder approval	Decision rights
Founder routing	Defined ownership
Founder QA	QA systems
Founder troubleshooting	Defined escalation
Founder reminders	Automation
Founder exception handling	Operational visibility

What success looks like

No numbers are promised here, because any number I published before seeing your operation would be invented. What can be described is the direction the operating model moves.

Fewer decisions routed to the founder
Clearer ownership
Fewer unnecessary escalations
Stronger operational visibility
Fewer undocumented processes
Less repetitive manual work
Better use of automation
More predictable delivery
Cleaner management cadence
Increased capacity without proportional founder involvement

Can the founder step away from normal operations without the agency immediately losing momentum?

Pricing

$10,000 / 90 days

Month 1Observation and Diagnosis
Month 2Implementation
Month 3Stabilization

This is an operating engagement, not an SOP package, coaching program, or traditional agency retainer.

Apply

Specific answers get a specific reply. Describe the parts of the operation that still depend on you and what happens when you are not there.

The reasoning behind this engagement is written up in Writing. The wider practice is at Work.