The risk of subcontracting is not the subcontractor. The risk is the undocumented methodology that the subcontractor cannot follow because it has never been written down.
Most practitioners who have tried subcontracting and experienced inconsistent quality conclude that the subcontractor was the problem. In most cases, the methodology was the problem. The subcontractor did what they knew to do. What they needed to do was never documented in a way that could be followed.
The Three Ceiling Indicators from Article 34 identified where the practice’s capacity limits live: in tasks that only the founder can do, knowledge that exists only in the founder’s head, and processes that have never been documented. Subcontracting addresses the first of these. Documentation addresses the second and third. The quality of subcontracted work depends entirely on how well the second and third are resolved before the first is delegated.
Why Subcontracting Fails Without Standards
The typical subcontracting failure follows a predictable sequence. The practitioner gives the subcontractor a brief, the subcontractor completes the work, the practitioner reviews it, finds it lacks the specific judgment and quality markers that make the practice’s work distinctive, and concludes that subcontracting does not work for this type of practice.
The conclusion is wrong. The subcontractor cannot produce what was never defined. If the practice’s quality standard exists only in the founder’s judgment, no brief can convey it. The subcontractor applies their own judgment, which is good but not the same.
The correct conclusion is that the practice needs a documented quality standard before it can subcontract successfully. The standard defines what “good” looks like in terms specific enough that someone with the right skills can meet it.
The Three-Part Subcontracting Standard
The Three-Part Subcontracting Standard is a structured approach for preparing a consulting or coaching methodology for consistent delivery by someone other than the founder. Each component addresses a different element of the quality problem.
Component 1 defines what quality looks like in measurable outcome terms
The quality definition answers the question: when a piece of work is complete, how do we know if it is good enough to deliver to the client?
This is harder to answer than it appears. Most practitioners know good work when they see it. Fewer can describe what makes it good in terms a subcontractor could apply without the founder’s review. The quality definition converts that intuition into explicit criteria.
The criteria are most useful when they are specific to the outcome rather than the process. “The deliverable is clear enough that the client can act on it without clarifying questions” is a testable outcome criterion. “Use proper business writing” is not.
Component 2 provides the process documentation subcontractors can follow
The process documentation is the step-by-step description of how the work should be produced. The Client Process Map from Article 17 describes the client-facing process; the subcontracting standard describes the practitioner-facing process: what happens in what order, which decisions are made at which points, and what good output looks like at each stage.
The methodology documentation from Articles 6 and 7 is the source material for this component. If the methodology has not been documented yet, subcontracting is premature. The documentation work must precede the delegation work.
Component 3 establishes the quality review cadence and criteria
The quality review protocol describes how the founder maintains oversight without being involved in every step of the delivery.
The review cadence is typically milestone-based rather than continuous. The founder reviews at defined checkpoints: at the end of the diagnostic stage, before any client-facing deliverable is sent, and at the conclusion of the engagement. Between checkpoints, the subcontractor operates with documented standards as the guide.
The review criteria match the quality definition from Component 1. The founder is evaluating whether the work meets the specific outcome criteria, not whether it matches exactly how the founder would have done it. The latter standard cannot be met; the former can.
How the Conductor Maps Your Teachable Methodology
The week the first subcontractor starts, the founder discovers how much of the methodology lives only in their own judgment. Handing off the work means making that judgment explicit. The question is which parts matter most.
The Conductor is Kiluma’s context-aware AI. It reads the methodology documentation, subcontracting records, and quality notes the founder has saved to the Living Library.
Asked which aspects of the methodology have tracked most strongly with good client outcomes, the Conductor returns them. It also flags the delegated work that most often needed correction before reaching the client. Those are the places where the standard has to be written down.
The first set is what to protect as the practice grows. The second is where the quality standard most needs to be explicit before the next handoff.
Document the Quality Standard Before Hiring Anyone
Do not hire a subcontractor and then develop the standard. Develop the standard first.
Take the most recent deliverable you produced that represents your best work. Write down what made it good, in terms specific enough that a competent practitioner with relevant skills could aim for the same qualities without your judgment as a substitute.
That document is the first draft of the quality standard. Present it to a potential subcontractor as part of the briefing. Their reaction will tell you whether it is specific enough to be followed.
Documentation Does Not Protect Your Work. It Enables It.
The practitioner who has documented their methodology well enough for a subcontractor to follow has not made the work commoditized. They have made it scalable.
The documentation that enables consistent subcontractor delivery is the same documentation that enables every other form of scaling the practice might take. Try Kiluma free for 14 days at kiluma.ai.