Grow the machine.
Do not break the promise.
Capacity scaling is not “hire until the work goes away.” It is the disciplined process of turning demand into productive capacity, productive capacity into repeatable delivery, and repeatable delivery into more margin instead of more rework.
A full calendar is not proof of healthy capacity.
Founders usually notice capacity too late. The team is already overloaded, dates are slipping, quality checks are skipped, the founder becomes the final reviewer, and every new customer appears to improve revenue while quietly increasing the cost of delivery. Then the emergency hire arrives without a stable process to teach.
The alternative is a staged operating decision. Prove the demand, calculate productive capacity, choose the smallest reversible move, document the work at the moment it happens, and only then decide whether the repeatable core is ready for a productized offer.
Move from demand pressure to controlled scale.
Select a checkpoint to inspect the operating decision. The sequence is a model; your gate depends on work mix, demand quality, ramp time, contribution, and the cost of a failed delivery.
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 qualityFour decisions that protect delivery while you grow.
Each stage prevents a different kind of expensive mistake. Skip the first and you hire for a pipeline illusion. Skip the third and you hire people into chaos. Skip the fourth and every new customer still requires the same custom invention.
Prove demand before you staff for it.
Start with the work that must be delivered, not the work the sales dashboard hopes will close. Label each demand unit as committed, likely, seasonal, or speculative. Then classify the delivery load: one familiar service is not the same capacity problem as four custom engagements with different skills and dependencies.
Build a demand ledger: customer, service type, required start date, required finish date, probability, delivery hours, required skill, dependency, contribution, and consequence of delay. A weighted pipeline can inform planning, but it should never be treated as contracted work. The more uncertain the demand, the more reversible the capacity response should be.
Calculate productive capacity, not fantasy capacity.
Nominal working hours are not delivery capacity. Remove selling, management, coordination, training, leave, support, internal review, and expected rework. Then compare the remaining capacity with the real workload by skill and time window. A team can have spare hours and still have a critical bottleneck if only one person can perform the decision that unlocks the rest of the work.
Use the gate: forecasted required hours plus a quality-preserving buffer, minus productive hours available after non-delivery work. If the gap is recurring and the work produces enough contribution to carry loaded cost and ramp, a hire may be rational. If the gap is temporary or the process is unstable, first sequence, scope, cross-train, price, partner, or remove waste.
Document decisions where the work happens.
A 90-page manual is not standard work if operators cannot find the next decision inside the delivery moment. A useful process document states the trigger, required inputs, ordered steps, decision rules, acceptance criteria, owner, evidence, exception path, and review date. It includes examples of acceptable and unacceptable outputs when quality is visual or judgment-heavy.
Make documentation executable: attach the checklist to the job, require evidence at the handoff, record the defect that caused rework, and update the step that failed. Documentation should reduce dependence on memory while leaving room for declared exceptions. If a new operator cannot use it to make the next correct move, it is reference material, not a control system.
Productize the repeatable core.
Productization is not pretending that every customer has the same problem. It is packaging the part of delivery that is stable enough to define, sell, staff, inspect, and improve. The customer should know the required inputs, the sequence, the deliverable, the acceptance standard, the timing logic, and what happens when the case falls outside the boundary.
Keep judgment at the edges: standardize intake, common analyses, recurring deliverables, status reporting, quality checks, and handoffs. Reserve expert time for diagnosis, exceptions, and decisions where variation creates value. The goal is not to remove craft. The goal is to stop charging the customer for avoidable reinvention.
Hire because the system can absorb a person.
The right trigger combines demand, capacity, economics, process readiness, and the cost of waiting.
| Signal | Move toward hiring or permanent capacity | Do not hire yet |
|---|---|---|
| Demand | A recurring or committed workload will exceed productive capacity after ramp time. | One unusually busy week or an unqualified pipeline creates the pressure. |
| Bottleneck | The constraint is identified by skill, role, sequence, or time window. | The team cannot explain why work is late or where hours disappear. |
| Economics | Expected contribution can cover loaded cost, management, ramp, and a quality buffer. | The hire is justified by revenue while contribution and remediation cost remain unknown. |
| Teachability | Inputs, acceptance criteria, examples, owners, and exception paths are usable. | The founder is still the only person who knows what “good” looks like. |
| Quality | On-time delivery, rework, escalations, and customer outcomes stay within guardrails. | The team is already skipping review and relying on heroics to finish. |
Use a reversible option when uncertainty is high. Resequence work, narrow scope, raise price, contract a vetted specialist, cross-train an adjacent operator, or pause low-contribution commitments. These moves create information without making a fixed-cost commitment before the demand pattern is understood.
Use a permanent hire when the gap is durable. The role should have a clear owner, a trainable workflow, a realistic ramp plan, a quality rubric, and enough contribution to make the investment sensible. A person cannot be the process. If the system works only when the founder is available to translate every request, the next hire increases coordination cost faster than output.
Watch the cost of scale before it becomes visible in the P&L.
Review a small operating set every week. Pair every capacity metric with a quality and margin metric.
What should be reviewed every week?
Review committed demand, probability-weighted demand, forecast error, productive capacity by skill, bottleneck load, work in progress, on-time delivery, cycle time, rework, quality escapes, customer escalations, gross contribution per delivery unit, ramp progress, documentation usage, and repeatable-core percentage. The exact dashboard will vary, but the pairings matter: utilization with quality, output with contribution, and growth with customer experience.
What is productive capacity?
Productive capacity is the amount of work a role can complete to the required standard in the planning window after subtracting selling, management, coordination, training, leave, support, review, and expected rework. It is not a universal percentage. Measure it from your actual work mix and keep the denominator visible.
When should a founder hire?
When a recurring, economically healthy demand gap remains after process waste and sequencing have been addressed; when the role’s ramp time fits the forecast; when the contribution can carry loaded cost; and when the workflow is teachable enough to protect quality. If any of those are unknown, reduce uncertainty before making a permanent commitment.
How do you know a process is documented well enough?
A trained operator can use it during the work to identify inputs, take the next step, make decisions, meet the acceptance standard, record evidence, and escalate exceptions. The best test is not whether the document is comprehensive. It is whether it changes execution and reduces avoidable variation.
When does productization hurt?
When the offer is standardized before the customer problem, inputs, outcomes, and quality criteria are understood. Forced uniformity can reduce fit, hide exceptions, and move complexity into support or remediation. Productize the repeatable core and price or route the exceptions deliberately.
What if growth is faster than the team can hire?
Protect the promise before accepting more volume. Narrow the ideal customer, reduce scope, increase price, cap intake, use a documented partner layer, or sell a later start date. Delaying a sale is usually cheaper than taking revenue that creates missed outcomes, refunds, reputation damage, and a team that cannot recover.
Scale the system before you scale the headcount.
Prove the demand, calculate the gap, document the work, inspect quality, and productize only what is stable enough to keep the promise.
Run The Capacity Path