The SCALE Method
Understand the operation. Identify the constraints. Design what needs to change. Put it into practice. Build it to last.
SCALE is the evolving methodology behind how I approach operational problems inside growing businesses. It is built around a simple principle: Diagnose before you prescribe.
S — See the Operating Reality
Before changing the business, understand how it actually operates. This means looking beyond how the process is supposed to work and understanding how work really happens.
Core question: How does this company actually operate today?
C — Clarify the Constraints
Once the operating reality is visible, identify what's actually getting in the way.
Core question: What is making this business harder to operate than it needs to be?
A — Architect the Better Operation
Determine what the company actually needs next.
Core question: What needs to change for the operation to better support where the business is going?
L — Launch & Learn
A solution isn't proven because it looks good on paper. Put the new way of working into the actual business. Observe it. Learn from it. Identify where the design meets reality—and where it doesn't. Refine accordingly.
Core question: Does the new way of working actually work in practice?
E — Embed Ownership
The goal is not to create a new dependency on the person who designed the solution. Ownership has to move into the organization.
Core question: Can the business continue operating this way without unnecessary dependency on one person?
The solution follows the problem.
We don't begin with: “You need more SOPs.” “You need ClickUp.” “You need automation.” “You need another employee.” “You need a Company Operating System.” Any of those could eventually be appropriate. But first, we need to understand why the problem exists.
Diagnose first. Design second. Implement intentionally.
SCALE begins with understanding.
The Operations Diagnostic currently applies the first three stages: SEE → CLARIFY → ARCHITECT. The goal is to understand the operating reality, identify the constraints, and determine what needs to change before deciding how—or whether—to implement it.