Grow the capacity without spending the margin.
Scaling delivery is the work of matching real demand to productive capacity, teaching the work without hiding the judgment, and packaging the repeatable core without making a promise the system cannot keep.
The capacity path
Choose a checkpoint to read the next decision. The sequence is a practical model; the correct move depends on demand certainty, work mix, ramp time, contribution, and the cost of quality failure.
Prove the workload is real
Separate signed work, probability-weighted demand, recurring patterns, and pipeline optimism. Then locate whether the constraint is volume, skill, scheduling, rework, or a broken sequence.
forecast → bottleneck → demand qualityI. The demand ledger
Capacity decisions begin with the work that must be delivered, not with the emotional temperature of the team. Record the customer, service type, required start and finish dates, probability, expected effort, required skill, dependency, contribution, and consequence of delay. A signed project and an optimistic opportunity may occupy the same column in a sales report, but they should not occupy the same staffing decision.
Separate volume from complexity. Ten familiar jobs may require less capacity than three custom engagements with different decision-makers, integrations, approval paths, and quality standards. Classify demand by the work it creates, not merely by the number of contracts. Then compare the forecast with historical error. If the pipeline is consistently overestimated, the answer is not to staff for the optimistic case and hope sales catches up.
Weekly prompt: What work is committed? What work is likely? What work is merely possible? Which work creates contribution after delivery, and which work creates activity without enough economic return?
II. The capacity gate
Nominal hours are not productive capacity. Remove management, selling, coordination, support, training, leave, review, and expected rework. Then break the remaining capacity down by skill and time window. A business can have spare hours in aggregate and still miss a deadline because the one scarce role is the constraint.
A hiring gate should include four facts: the demand gap is recurring or sufficiently committed; the bottleneck is named; the role can reach independent quality within the required window; and the expected contribution can carry loaded cost, management, ramp, and a quality-preserving buffer. If those facts are not available, a reversible move is usually better: resequence work, narrow scope, raise price, cross-train, use vetted flexible capacity, or delay the start date.
“A full calendar is a signal to investigate. It is not a conclusion.”
CAPACITY RULE / 02The cost of waiting matters too. Late delivery, refunds, rework, lost renewals, reputation damage, and founder distraction can make under-capacity more expensive than a carefully timed hire. The decision is not “hire or do nothing.” It is a comparison of the cost, reversibility, and quality risk of each capacity move.
III. The standard-work test
Documentation should meet the operator at the point of decision. Every critical process needs a trigger, required inputs, ordered steps, decision rules, owner, acceptance criteria, evidence of completion, exception path, and review date. Where judgment is difficult to express, attach examples of good and bad outputs. A document that describes the philosophy but cannot help someone choose the next action is not standard work.
Use the defect log as a learning system. When a reviewer finds an error, record where it entered, what signal should have caught it, and which process step or training artifact must change. Do not use review as a permanent founder tax. The purpose of review is to make the standard visible, improve the work, and gradually move routine decisions into the system.
Documentation test: Can a competent new operator gather the inputs, follow the sequence, meet the acceptance standard, record evidence, and escalate the exception without asking the founder to translate the entire job?
IV. The productization boundary
Productization is the decision to package a repeatable core of service so that it becomes easier to sell, staff, inspect, and improve. It does not require pretending that customers are identical. The best productized offers state who enters, what inputs are required, what the sequence includes, what output is produced, how timing works, what the customer must do, and where exceptions go.
Standardize the stable layer: intake, common analyses, recurring deliverables, status reporting, quality checks, handoffs, and escalation rules. Keep deliberate judgment at the edges when it creates value. A custom exception can be profitable when it is visible, scoped, and priced. It becomes margin death when it is smuggled into a standard promise and discovered only after delivery has started.
Productize only after the outcome, inputs, process, and acceptance criteria have enough repetition to define. If the team is still learning what the customer actually needs, package the learning process before packaging the final promise.
The weekly operating ledger
Questions from the field
Is there a universal utilization target?
No. Utilization depends on work mix, coordination load, quality requirements, selling responsibility, and the cost of interruption. Track productive capacity with its denominator and pair it with rework, on-time delivery, customer outcomes, and contribution.
When is a contractor better than a hire?
When demand is uncertain, the skill is specialized, the gap is temporary, or the business needs a reversible experiment. A contractor is not automatically cheaper; include management, quality, coordination, and handoff costs.
What makes a hiring trigger credible?
A recurring demand gap, a named bottleneck, a ramp timeline, a contribution case, and a teachable process with quality evidence. A single overloaded week or an unqualified pipeline is not enough.
How do you document tacit knowledge?
Observe the work, capture decisions and cues at the moment they occur, add examples, define the acceptance standard, and test the document with another competent operator. Improve it from actual defects rather than attempting to write every possible exception in advance.
When does productization reduce quality?
When a service is standardized before the problem, inputs, and outcome are stable, or when valuable exceptions are hidden instead of routed. The stable core should become repeatable; expert judgment should remain visible and deliberate.
What should happen when demand outruns capacity?
Protect the customer promise. Cap intake, narrow scope, increase price, schedule later, add vetted flexible capacity, or pause low-contribution work. A delayed sale is cheaper than a failed delivery that creates refunds, remediation, and lost trust.
Scale what you can teach and inspect.
Demand creates the opportunity. Productive capacity captures it. Standard work protects it. Productization makes the repeatable core easier to grow without spending the margin.