The hiring trap
How reactive hiring blocks growth, and what to do about it
The scaling block
The team is drowning. The startup has grown to 25 people, up from 8 a quarter ago. Everyone reports to the founder/CEO, who’s pulled in a million directions. Nobody can get hold of her. Without her, nothing can get decided.
The best engineer at the company has been offered another role and is looking for career progression or a strong reason to stay. The CEO can’t see tomorrow clearly, let alone how to move forward without this engineer.
So she gives him what he asks for. She promotes him to manager, promises he’s on the CTO path as the company grows. But she doesn’t give him any guidance. She just puts him in charge and disappears back into the chaos. Her only instruction? The company can’t keep up with its customer commitments, so hire more people.
Three months later, everyone is miserable. There’s now 40 people at the company, and nobody knows what to do. The Product Manager hired by the newly-minted CTO is tearing her hair out because every customer meeting seems to result in a new pivot. As a result, nothing is getting delivered. The company lost a great engineer three months ago and gained a struggling technical leader. Nobody has been able to step into his shoes because the CTO doesn’t have time to train the next cohort of engineers.
The company’s ability to scale is blocked by its reactive hiring strategy.
You can’t hire for urgency
I’ve written before about the “urgency-industrial complex,” where responsiveness becomes the de-facto product strategy. Startup survival can hinge on being able to pivot based on customer discovery.
As the Agile Manifesto has it, “Responding to change over following a plan.”
That reactive posture can work for product decisions. But it’s catastrophic for hiring, particularly in scaling organisations.
Hiring permanent staff has lead times. Two to three months to interview and onboard. Another month at least to get up to speed on the organisation’s culture, goals, and working practices. If you’re looking to grow leaders, you may need another three months before someone has the credibility to lead.
Most startups are so busy growing, that there’s no time to forecast hiring needs, and growing payroll too quickly can burn up the funding runway. The problem is that, if you wait, by the time you realise you need leaders, it’s too late to create them. If you’re hiring for what you need right now, it’s usually two months too late by the time you get someone in the door, longer before you get them up to speed. You can’t compress these timelines with wishful thinking. You can prevent being blocked by hiring ahead.
Hiring ahead
At a scale-up I worked with, we took a counter-intuitive but more intentional approach. As we achieved product-market fit, we began to see the sales pipeline fill. As a B2B SaaS company, we could use the lead time on deals to review the sales pipeline and forecast when customers would onboard, and how quickly. We used customer feedback and sales intelligence to predict what we’d need to deliver. This allowed us to create hiring plans, where we were able to look at the company we’d be in six months, and hire for that now.
We knew we were taking a gamble that the customers would land, but the alternative was that we wouldn’t be able to meet our customer needs, in which case we wouldn’t survive anyway.
This went beyond just hiring ICs. As we reached 20 employees, we started to actively interview for people who would want to become people leaders. We were explicit about the opportunity in interviews, creating a cohort of people who would be ready to step up as team leaders as the organisation grew. When we needed them to step up, they had the context, relationships and credibility to lead effectively.
Building capability
Hiring ahead was just the first step. We started to embed the structures and practices we wanted the growing organisation to have so that there was support in place for our new leaders. Many ICs fail as people leaders because they’re not given the tools to succeed. The assumption that someone who is good at writing software will be good at leading people who write software is misguided. But even someone who has the talent and motivation to lead is likely to fail if they’re not supported as they step into the role.
We thought about our reporting structures and how we would create team alignment in advance. We asked ourselves how decisions would be made. What should be escalated? How would teams interact as we grew horizontally?
By thinking these decisions through, we were able to develop a structure where people could succeed, and we planned for that success, creating clarity for new leaders when they came into the role.
Clarity is a kindness
Being clear about the organisation’s growth plans makes all the difference.
Let’s say that you have 15 people today, and you forecast that you’ll grow by 50% every six months for the next two years. In six months, you’re going to be a 23-people strong organisation. In a year, you’ll have 35 people.
If you’re aiming for a structure where teams will have 6 - 9 engineers and a Product Manager associated per team, you’re growing from one such team, to two, to three very quickly. You won’t be able to keep directing them in detail. You need to ensure that you give your incoming leaders the tools they need. You need to identify or hire your future leaders now, and you need to create some guardrails for them when they get into position.
Guardrails
What kind of guardrails make sense?
The idea of guardrails is not to create process and bureaucracy. It’s to give clarity and autonomy to leaders so that you can make space for them to lead as the organisation grows. Examples of guardrails include:
Decision boundaries (what can teams decide independently?)
Communication rhythms (when do we sync? what’s async?)
Quality gates (what’s non-negotiable?)
Ownership clarity (who owns what?)
These guidelines mean that rigid processes, command-and-control, or decision paralysis are avoided. Everyone has clarity on what is within their scope of authority and a quick way to get to a decision.
Install these guardrails before you need them. As you grow beyond one team, institute basic decision-making authority, and establish guidelines around meeting practices. Once you’re beyond two teams, you should have ownership guidelines in place and a RFC process for cross-team decisions. Once you’re at 50+ people, you may need to institute more formal practices, or divide efforts into different departments, e.g. establishing platform or developer experience teams.
Warning signs
Signs that you’re behind where you need to be include:
You’re involved in every decision, however small
People are complaining about chaos
Teams are stepping on each other
You’re desperately adding process reactively
Beyond 30: When to specialise
Going from 15 to 35 people is about adding your first managers, and creating your first formal organisation structure. The next stage of scale is going from 30 to 100+, becoming a real organisation. For this, you’ll need to think about layers and specialisation. At 30 people, most startups have generalist engineers on product teams. Everyone does a bit of everything - infrastructure, quality, features, support. This works because coordination overhead is still manageable.
At scale, though, the generalist approach creates bottlenecks. If each team is responsible for its own infrastructure, different practices emerge and quality can suffer. Security and compliance starts to become uncoordinated. A solution may be specialist teams, or a developer experience function with platform engineers who build shared infrastructure, establish quality standards, and own compliance. You’ll be reaching the point where you need to build out a proper support function. Up until now, this was probably managed informally or with everyone being on-call.
At the scale-up, we took the difficult decision to split ourselves in two. One half of the business became the support and platform function and the other continued to be the customer-facing product organisation. This took us a few weeks to implement, and it was a big change, impacting everyone who worked for us, but it was also our salvation, making it possible for us to scale and grow.
The six-month rule still applies: if you think you’ll need a platform team at 50 people, start hiring at 40.
The exception
One scenario where reactive hiring can work is bringing in contractors for well-defined, short-term needs.
If you suddenly need five more engineers to hit a critical deadline, contractors can be effective. They come with experience, require minimal onboarding, and can contribute immediately. There’s nothing wrong with buying capacity for a specific timeframe.
Spending wisely
Hiring ahead can feel expensive. You’re paying senior salaries for people who won’t manage for 6-12 months. But reactive hiring is more expensive: lost momentum due to unclear decision frameworks, poor managers put in a position where they can’t succeed, low morale, and quality problems from lack of ownership.
Guardrails may sound like process. You’re adding structure while still small. But lack of structure can lead to chaos. No clear decision-making authority leads to paralysis. Every decision requires coordination, teams block each other constantly, your best people are spending time in low-quality meetings instead of building high-quality software.
Won’t AI fix all this?
You might be tempted to think AI will solve this problem for you. We’ve already seen AI coding assistants increase IC productivity dramatically. The role of software engineer and Product Manager is being reshaped by AI, potentially meaning that you can (to use the dreaded phrase) do more with less. For example, AI might push back the specialisation inflection point - if generalists can maintain infrastructure with AI support, the need for platform teams could be significantly pushed back.
AI can also assist with compressing the recruitment process. But the fundamentals don’t change. High-performing teams operate with trust, which is built through shared experience.
The six-month rule might become a five-month rule, or even a quarterly rule. But it doesn’t disappear.
Hiring ahead remains essential. It just might look slightly different.
The reactive trap
Some organisations operate reactively by design - responding to urgent customer demands, pivoting quickly to market changes. Reactive strategy can work for product decisions where you can pivot in short timescales. More than once in my career, I’ve found myself writing a new product roadmap overnight.
But hiring has real lead times, and deep costs for getting it wrong. Hiring ahead isn’t a luxury - it’s essential.
Related reading
Appendix A - a practical playbook
This appendix is a playbook for hiring ahead at each inflection point. If you’re scaling, bookmark this and check it regularly for how you’re growing.
From 15 to 30 people
The situation:
One team, everyone knows everyone and can help on most things
Founder/leader directly manages most people
Informal decision-making relies on the CEO
Customer pipeline shows 50% growth every 6 months
Customer capacity forecast:
Currently, 15 people are serving 20 customers, sales pipeline indicates 8-10 new customers per month in the next 6 months. Can you serve 70 customers with 15 people? No. You’ll need 23-25 people at least.
At 25 people, you need 3-4 team leads and some division of ownership between the teams you’ll create.
Actions to take now:
Hiring (Month 1-2):
Hire 2-3 senior ICs with management potential
Be explicit in interviews: “IC role now, management opportunity in 6-12 months.” See Appendix B for more details.
Guardrails to install (Month 1 -3):
Weekly 1-1s between ICs and people leaders
Basic scheme of delegated authority
Team size limit (no team larger than 8-9 people)
Leadership development (Month 3-6):
Give future leaders mentoring responsibilities
Have them lead small initiatives
Include them in hiring and onboarding
Signal explicitly that they are on track for leadership role.
By Month 6 at ~25 people:
Your 2-3 hires are in team lead roles
They have context, relationships, credibility
The CEO is now managing managers, and decisions are made accordingly.
Cost:
3 senior hires × 6 months before they manage = investment in smooth scaling
Alternative cost:
Reactive hiring + chaos + failed promotions + lost momentum = much higher
From 30 to 100 people
Your situation:
3-4 teams, each with a team lead
Teams are generalist (everyone does everything)
Starting to see coordination overhead
Specialisation becoming necessary
Customer capacity forecast:
You have 30 people serving 60 customers, growth continuing at 40% every three months.
You’ll hit 50 people serving 100+ customers in the next six months.
At 50 people, you need 6-8 team leads, an additional layer of leadership (managers of managers) and are likely to turn to platform or developer experience teams to lighten the burden on your product teams.
Actions to take NOW at 30 people:
Hiring (Month 1-3):
Hire 1-2 people who’ve managed managers before
Hire for specialist roles if you see bottlenecks emerging
Continue hiring senior ICs with management potential for additional team leads
Guardrails to upgrade (Month 1-3):
Clear ownership (every service/product has exactly one team that owns it)
RFC process for cross-team decisions (1-page, 72-hour comment period)
Formal team splits when teams hit 9 people
Monthly retrospectives and lightweight, continuous planning ceremonies.
Organisational structure (Month 3-6):
Create manager of managers role (your team leads now report to them)
Consider first specialist team to address bottlenecks
Define career ladders (IC track vs management track)
Leadership development (Month 3-6):
Train your team leads on managing (don’t assume they know how)
Create peer support groups (team leads meet regularly)
Start identifying next cohort who might become managers in another 6-12 months
By Month 6-12 at ~50-60 people:
Clear organisational structure
Specialist teams handling platform/developer experience
Decision-making flows smoothly without everything escalating to CEO
CEO is focused on strategy, not operations
Warning sign you’re behind:
If your CEO is still making all decisions at 50 people, you’re 6 months too late.
Key principles across all stages
Always forecast 6 months ahead:
Sales pipeline + close rate = customer onboarding forecast
Customer load = team capacity needed
Team size + lead time = hire now
Always hire for potential, not just current need:
Can they deliver as IC immediately? (first 3-6 months)
Do they show leadership signals? (months 6-12)
Do they want to manage? (explicit career interest)
Always install guardrails before your teams get overwhelmed:
Establish decision rights before teams are blocked
Create communication ceremonies before meeting overload
Clarify ownership before territorial conflicts
Limit team size before co-ordination becomes unwieldy
Always acknowledge uncertainty:
The customers might not land (but you plan anyway)
The hire might choose IC path (and that’s fine)
The structure might need adjustment (build in flexibility)
Perfect planning is impossible (but some planning beats none)
When NOT to use this playbook
Don’t hire ahead if:
You don’t have 6+ months runway (solve cash flow first)
You haven’t achieved product-market fit (focus on survival)
Your sales pipeline is completely unpredictable (too much uncertainty)
You’re genuinely in exploration mode (team structure will change radically)
In these cases:
Use contractors for immediate capacity needs, keep team small and generalist, wait until you have clearer visibility before building permanent structure.
But remember, the longer you wait, the longer your scaling will take when you finally need it. The lead times don’t compress because you’re in a hurry.
Appendix B - How do you identify future leaders?
If you're on this growth trajectory, you need someone who can contribute as an IC immediately and can grow to be a manager as you scale. How do you identify potential?
Interviews are imperfect, but, much like democracy, they remain the best system we have when you consider the alternatives. Scale-ups are likely to be placing people in their first leadership role, so they won’t have direct experience. You’ll need to ask candidates for engineering positions about behaviours they have exhibited that indicate leadership traits, for example:
Tell me about a time you influenced without authority
Why: Can they demonstrate the ability to persuade peers and stakeholders?
Look for: collaboration, persuasion, building consensus
Tell me about a time you got things wrong?
Why: Managers must be able to admit mistakes and change course without blame
Look for: intellectual humility, learning orientation, willingness to take responsibility.
How do you like to receive/give feedback?
Why: The ability to give and receive constructive feedback is fundamental to good leadership.
Look for: thoughtfulness about approach, ability to listen and repeat back what is being said.
Tell me about a project that failed and what you learned
Why: Managers must handle failure productively
Look for: ownership, learning, systems thinking
You still need strong IC skills. Management potential is necessary but not sufficient. The ideal candidate:
Can deliver as IC immediately (needed for first 6 months)
Shows leadership signals (potential for months 6-12)
Actually wants to manage (explicit career interest)
In the interview, when candidates demonstrate that they might be a good leadership candidate, it’s a good idea to be open with them and see how they react. Telling them that an opportunity to become a people leader may arise within 6-12 months filters for interest and sets expectations clearly.