Scaling Without Losing Leverage

Hold the number of people who must agree before work ships roughly constant as headcount grows. Speed is lost to decision rights rather than to size, which is why companies slow down at a specific headcount rather than gradually. Most of the other symptoms, including burnout and key person risk, turn out to be consequences of the same structural drift.

Growth does not slow you down, approvals do

Teams describe the slowdown as a size problem because it correlates with size. It is more precisely a decision-rights problem, and the distinction matters because the two have different fixes.

Count how many people must say yes before a typical change reaches a customer. In a ten-person company that number is usually one or two. If it is five or six at sixty people, that is where the speed went, and no amount of process improvement recovers it. Meetings are a symptom of the approver count, not a cause.

The practical discipline is to treat the approver count as a budget. Adding a required approver is a real cost that has to be justified, in the same way adding headcount is.

Burnout is usually a structural signal

It concentrates predictably. The people who burn out first at a scaling company are rarely the ones with the most work. They are the ones absorbing the coordination that the org failed to design away: reconciling between two teams, translating between functions, holding context nobody wrote down.

The instinctive response is to give that person help, which staffs the gap and makes it permanent. The structural response is to ask why the reconciling is needed at all, and to close the boundary producing it. That usually removes the work rather than redistributing it.

What to screen for changes around fifty people

Early hiring selects for scrappiness: willingness to do whatever is needed, comfort with undefined scope, bias to action. Those traits are correct at ten people and become a liability at sixty, because they produce roles nobody can describe and work that overlaps invisibly.

Leverage hiring selects differently. Can this person own an outcome without a manager decomposing it? Do they leave systems behind that make the next instance of the work cheaper? Will they define the boundary of their role rather than expanding into whatever is adjacent?

The transition is uncomfortable because the traits that built the company stop being the traits that scale it, and the people who embody them are often the earliest employees.

Key person risk, correctly framed

The common framing is that depending on one person is dangerous, so you should reduce the dependency. That is half right and leads to the wrong action, which is hiring someone to shadow them.

What is actually dangerous is undocumented, unowned systems. A highly productive person is an asset. A highly productive person whose work nobody else can operate or extend is a risk, and the fix is documentation plus a named second owner, not a duplicate person. Test it during their next holiday: if something they built cannot be extended while they are away, you have found the gap.

Sort the hiring list by cost of delay

Most hiring plans are sorted by expected benefit, which makes every role look worthwhile and produces a list nobody can prioritise.

Sort by cost of waiting one quarter instead. What breaks, what is lost, what becomes more expensive. That reliably collapses a list of six roles into one that is genuinely urgent and five that can wait, and it produces a defensible answer when someone asks why their role was not approved.

Common questions

How do I maintain startup speed with a 100-person team?

Protect decision rights rather than process. Speed is lost when the number of people who must agree before something ships rises, not when headcount rises. Keep the count of required approvers flat as the company grows and most of the slowdown does not happen.

How do I build a team that scales without burning out?

Burnout at scale is usually a structural symptom rather than a workload one. It concentrates in people absorbing coordination that the org failed to design away. Find who is doing the reconciling between teams and fix the boundary, rather than giving that person more support.

How do I transition from hiring for scrappiness to hiring for leverage?

Change what you screen for. Scrappy hiring selects for willingness to do whatever is needed, which is correct at ten people and becomes a liability at sixty because it produces undefined roles. Leverage hiring selects for people who can own an outcome and build the systems that make it repeatable.

How do I prevent key person dependencies as I scale?

Separate the person from the systems they built. Dependency becomes dangerous when what someone built is undocumented and unowned by anyone else, not when one person is unusually productive. Require a named second owner for anything load-bearing, even if they never touch it day to day.

How do early-stage founders evaluate role ROI before hiring?

Write the outcome the role unblocks, the cost of waiting one quarter, and what you would observe in six months if the hire worked. If you cannot describe the observable difference, you cannot evaluate the role afterwards either, which is how unnecessary roles become permanent.

How do I make hiring decisions when every penny matters?

Rank candidate roles by the cost of not doing them rather than by how much each would help. Most hiring lists are sorted by benefit, which makes everything look worthwhile. Sorting by cost of delay usually collapses a list of six roles into one that is urgent and five that can wait a quarter.

Should I hire specialists or keep my team generalists as we scale?

Keep generalists where the work is still changing shape and hire specialists where it has stabilised and correctness matters. The mistake is treating this as a company-wide philosophy rather than a per-function decision. Most scaling companies need both, in different places, at the same time.