Check Whether You Have an Answer Before You Approve Scaling

This is the full playbook from “Scale Early Enough to Stay Ahead of Demand.” The book prints a shorter version at the end of that chapter, and this page keeps every step and every example.

Run the Scaling Threshold Framework every time you see a growth inflection approaching. It is a recurring diagnostic, not a one-time planning document.

1. Name your current threshold. State three things: the size of your team, its structure (co-located, distributed, or hybrid), and the growth you believe the business will require over the next two quarters. Do not wait for someone else to hand you that number. Developing a credible capacity and hiring forecast is part of the CTO’s job. Build it from the company’s revenue plan, product commitments, customer pipeline, known technical constraints, and the team’s current capacity, then reconcile it with the CEO and CFO. If you cannot produce a number you are prepared to defend, that is itself information: engineering and the business are operating without a shared growth model.
2. Run the three-signal check. Score yourself green, yellow, or red on the commitment-versus-delivery gap, the shape of the support-ticket load, and the team’s consensus on remaining capacity before something breaks or gets noticeably worse. That last measure is not the same as anticipated team growth. Growth is the staffing you expect to add; remaining capacity is the headroom in the team and systems you already have. Write one sentence of evidence for each score. A color without evidence is a guess.
3. Build the cost-of-inaction case for every signal that scored yellow or red. Estimate what continued growth without intervention costs in four categories: customer churn risk, SLA or reputational exposure, attrition cost on the current team, and the cost of delay when too little capacity forces you to postpone a customer, a committed feature, or new demand. State a range, not a single number that implies false precision, and write your assumptions beside it. Then a CFO can challenge a specific assumption instead of rejecting the whole estimate.
4. Inventory what is still tacit. List the judgment calls your senior engineers make by instinct, the ones a new hire would still get wrong after six months: technical debt tradeoffs, code review disagreements, exception authority, incident ownership. For each, either document and teach it before the next hiring wave, or leave it late-binding at your current size. Be honest about which answer applies. This list is what you lose if you scale the org chart without the playbook under it, and it is worth reading twice: an inventory of judgment nobody else’s new hires arrive with is an inventory of advantage.
5. Name which current projects you protect and which you pause. Before the growth period starts, write down which strategic or innovation work continues through the scaling push and which stops. Tell the team both halves. A stated triage and an unstated freeze produce very different levels of trust, even when the paused work is identical.
6. Set the next threshold check. Don’t treat this exercise as complete once you hire or build the capacity. Name the next headcount or traffic level at which you run the whole thing again, and put that check in the calendar now.

Use it before you approve the next scaling request, whether it comes from sales, from finance, or from your own engineers. The framework does not give you the answer. It tells you whether you have one, or whether you are about to make an expensive, hard-to-reverse decision on a hope.

All of the playbooks are listed on the playbooks page.