02 / ANALYSIS
Frontier founders have an unusual headcount problem.
A small company can already need:
sophisticated regulatory,
commercial,
manufacturing,
recruiting and
government capabilities.
External institutions do not care how many people are on your payroll. A regulator still expects competent engagement. A utility can have an enterprise procurement process before you have an enterprise sales team. A manufacturing partner still needs someone who knows what they are doing.
If every important problem becomes a function, though, you can build a surprisingly large organization before you have built much of the company.
The goal is to become more precise about what deserves to become organization.
1 / Start with what is holding the company back
“The biggest bottleneck right now will be to hire personnel who can start serving all of these customers.”
Founder · Seed-stage AI compliance · Nuclear + space
Early companies have dozens of important problems, but usually only a few determine how quickly the company can move.
At one advanced-materials company, the early constraint was technical credibility. The team needed to develop the technology far enough that customers would take it seriously. Later, the market taught them something unexpected: the application attracting investor attention was not where the strongest customer pull existed. The company had to redirect its commercial attention even though the underlying technology had not changed.
At another frontier company, customers already understood the problem and were buying. The emerging constraint was delivery: the founders needed enough people who could serve the customers they were winning.
Similar stage but completely different operating priority.
Before discussing headcount, ask what is actually setting the clock:
If twice as many engineers would not move the next milestone forward, engineering capacity probably is not the constraint.
If customers are waiting on qualification, another salesperson may not help.
Find the thing controlling progress before adding capacity around everything else.
2 / A capability does not have to become a function
“By being able to use somebody else’s facility and rent it out, we weren’t waiting six months to a year to set up equipment.”
Employee #2 · Growth-stage battery technology · 120+ person scale-up
Once something becomes important, the natural response is often to hire someone to own it. Insert another question first:
What is the smallest form in which we can acquire this capability today?
I saw this repeatedly while working inside an early nuclear company. We needed access to utilities, state governments, regulators, investors and specialized technical expertise, often at the same time. Some of the highest-leverage commercial work did not require building a larger commercial team. It required finding the person already embedded in an ecosystem who could get us to the right decision-maker.
The same logic applies elsewhere as you may need:
sophisticated regulatory advice without needing a regulatory department.
excellent recruiter without needing internal recruiting.
manufacturing expertise for one consequential supplier decision without needing a VP of Manufacturing.
Small companies can now borrow a surprising amount of scale.
In the field, one hardware company needed specialized equipment that would have taken roughly six months to acquire and commission. Instead, the team used someone else's facility and started the work. The decision mattered because it changed the clock, not because outsourcing was inherently better.
Facilities, manufacturing capacity, regulatory expertise, recruiting networks, relationships and technical specialists can all be accessed before they are owned. Software and AI are expanding that list.
The founder's question is to figure out how much of a capability the company needs to own right now (if ever).
3 / Bring work inside when repetition makes you better
Borrowing capability eventually stops being leverage so keep an eye on accumulation.
Does doing the work repeatedly create knowledge you will use again? Are relationships becoming an asset? Does company context materially improve performance? Would becoming unusually good at this help the company win?
One early hardware team took this logic into hiring itself. Through roughly its first 50 employees, most new hires had previously worked with someone already inside the company. Existing relationships reduced uncertainty as senior people joined and responsibilities changed. The company was gaining more than labor; it was also gaining trust and coordination speed.
That is a stronger reason to hire: the work gets more valuable because the capability lives inside the company.
4 / Use cross-functional operators while the work is still taking shape
“Show me what [the founders] spending your time on. As I see things, it’s: ‘Why are you doing this? Okay, show me one more time. You’re never going to do this again. This is now my responsibility.’”
Early operator · The Engine · MIT-born "tough tech" ecosystem, 150+ companies
Important work often appears before there is enough of it, or enough understanding of it, to justify a dedicated function. This is where a strong cross-functional operator can be especially useful.
I have held roles where my remit moved across hiring, regulatory work and commercialization as the company's constraints changed. The job was to take an important problem that did not yet have a natural owner, build the first version, bring in expertise where needed, and run it long enough to understand what durable ownership should look like.
Another early operator described a similar progression. Marketing initially sat within a much broader remit while the organization figured out what it needed. Once the work became substantial and specialized enough, the company hired an experienced marketer and the operator moved to the next unresolved problem.
This is an important distinction. Cross-functional operators are not generalists because they lack depth. Their specialty is taking ownership across functional boundaries when the company does not yet know where those boundaries should be.
Specialize too early and you can build a function around a problem you do not yet understand. Keep the work with a cross-functional operator too long and they become the bottleneck.
Once the problem is frequent, consequential and understood well enough that deeper functional expertise improves execution, hand it over and move the operator to the next company-level constraint.
5 / Count the coordination cost
A hire adds capacity, but it also consumes capacity. That matters in frontier companies because the people transferring context are often the same scarce technical leaders needed to move the technology forward.
One early hardware operator described deliberately resisting a larger operations team for this reason. Every additional person required technical people to explain the work, transfer context and answer questions. More support did not translate cleanly into more technical capacity.
A founder should account for that burden. If a hire saves ten hours of work but requires eight hours of founder or technical-lead attention to remain effective, the organization gained much less capacity than the headcount suggests.
Sometimes the answer is still to hire, just calculate the real trade.
6 / The company must be able to change shape
To be clear, none of this is an argument for keeping frontier companies artificially small. Manufacturing and deployment eventually require real organizations, and refusing to build them when the work demands it creates another constraint.
But a true competitive advantage of a small company is that it can completely reconfigure its shape, both inside and out, at a moment's notice. Unfortunately, this lever is often abandoned by many companies far too quickly.
Remember that a capability can start with a founder, move to a generalist, borrow an outside specialist, become partly automated and eventually warrant a dedicated leader. Another capability may never need to come inside at all.
That flexibility matters because the constraint keeps shifting: technology becomes credible and customers become the problem. Or customers arrive and delivery breaks. Or maybe deployment reveals a regulatory issue. Manufacturing starts consuming capital. The sequence varies by company, and the organization has to move with it.
Frontier companies already operate inside systems they cannot easily accelerate. You cannot eliminate a physical test cycle or wish away construction lead times.
But you can avoid making the company itself another source of delay.
That is the underlying operating advantage: a company that can change shape faster than its constraints do.
