Scaling Engineering From 3-30+ Engineers

What are the “stages” that engineering orgs go through as they scale from founding teams to larger teams?

Stage	Engineering Employee Count	Fundraising Stage	Activities	Engineering Leadership
1	0-10	Seed / Bootstrapped	– Find a clear market signal for what you want to build – Fiercely coding to build the product	Founder CTO
2	10-30	Series A-B	– Start to specialize your team, build dedicated support teams	Founder CTO + VP of Engineering
3	30-100	Series C-D	– Start to tackle enterprise challenges as the business really starts to scale	Founder CTO + VP of Engineering
4	100+	Series E-F (preparing for IPO)	– Bring in “big company” tech leadership, prepare for IPO	Professional CTO

When should you bring in a VP of Engineering? What should you look for?

The first CTO is typically one of the co-founders – this person is typically the first engineer as well, so they’re very technical. They can serve as your CTO until they want to focus on other responsibilities (product strategy and evangelism, architecture, etc.), or you need someone with more professional engineering management experience.

A VP of Engineering is typically hired at series A or B – as the founder CTO shifts to other responsibilities, hire a VP of engineering to boost your managerial know-how and bandwidth. They assume the full-time management of the engineering org, including hiring, recruiting, building the product, delivering the roadmap, staffing, and project management.

Hire a technical or managerial profile to fit your needs and look for stage familiarity – you will likely be hiring for either technical (domain-specific) or managerial skills. The right profile matches the problem you’re trying to solve. Whoever you hire should have experience with your company’s stage. They should understand what they’re entering into and how to navigate an early-stage startup.

At series E and F (100+ engineers), you might hire a “big company” CTO – once you have 100+ engineers, you’re a big company, and you might need a professional CTO to parachute in from an adjacent role and get you prepped for an IPO.

Note: the “CTO” title can encompass a wide variety of roles – a founder could be called CTO, someone filling a VP Engineering role could have a CTO title, and there are large corporation CTOs. Whatever your title structure, seek leaders experienced with your company’s stage of growth.

What should you think about when making your hiring plan?

Three factors determine how many engineers you can hire:

Budget – how much money are you willing to spend to bring on engineers? The cost of hiring depends on geography and profile—an experienced North American engineer fully loaded (laptop, health insurance etc.) will cost $200K+.
Ambitions – you need to think about your business and engineering goals when hiring. Don’t hire engineers that are going to sit around with no meaningful work, but also ensure the engineering team is sufficiently staffed to accomplish your goals.
How many engineers can you successfully onboard – your current engineering team has to interview and onboard all the new engineers, while also building a product. Their bandwidth limits how many new engineers you can bring on.

Never hire more engineers than you already have – you want to be able to match each new hire with a tenured engineer. If you go over this limit, then either the hiring and onboarding process or the product will suffer—and you could end up with turnover as tenured engineers become overburdened.

How long does it take to hire and ramp new engineers?

Hiring + onboarding a new engineer will take more than a quarter:

Expect a lead time of 4-6 weeks for hiring an engineer – 2-3 weeks from the first interview to the offer, plus ~2-3 weeks from the time they accept to the time they start. You want your hiring to move as quickly as possible, but the lag is typically on the candidate’s side. They can delay the application process or the start date, which can vary from an immediate start, to pushing out several months.
A typical onboarding process lasts 90 days – your program should run 90 days, but every employee’s uptake speed is different. Some can contribute in the first week and some take longer to get their bearings.

Interviewing will take ~25 hours of your team’s time per hire:

Expect to interview ~10 candidates to make an engineering hire – sometimes it’s easier and sometimes it’s harder. You want to fail candidates early in your interviews so you don’t waste their time or yours.
The typical interviewing process takes 5 hours to complete – this will depend in part on the complexity of the position you’re hiring for. Look at your own historical interview data to plan. You should have a very structured interview process. A typical process includes a recruiter screen, a hiring manager screen, and two technical interviews. Given you can cut some candidates early in the interview process, plan for ~25 hours of interviews to get one hire

Doubling your team doesn’t mean that your output will double – you double your team and at best, the output is going to stay the same during onboarding. You’re adding interviewing, teaching, and onboarding responsibilities to your veteran engineers. You hire engineers for the long term benefits, don’t expect immediate returns.

Where should you look for engineers?

There are three sources you can look to for hiring:

Invest in full-time recruiters (in-house or outsourced) – to make enough hires to scale an engineering team, you need a recruiter who can source engineers.
Referrals – you might be able to source a handful of hires through your network, but you can’t expect to hire 10+ engineers through referrals.
College – as your team grows to 20+, you might start layering in college hires—while keeping the majority of your hires veteran engineers.

How can you assess candidates?

Candidate assessment:

Define your desired profile before hiring – for your own sake and the recruiter’s, you need to define the profile you’re looking for. I usually sit down with my recruiter and look through a few LinkedIn profiles to give guidance before they spin up their own efforts.
Build an objective interview process – outline what traits or skills the candidate needs to exhibit, whether these are technical or non-technical, and outline how you will assess them.
There are two types of technical assessments to run:
- A take-home problem, timeboxed to 45 minutes – scope something that should only take 15 minutes to complete, and give a 45-minute time limit. You don’t want someone spending their entire weekend on it.
- Solving a problem in a coding environment live with an engineer – have them share their IDE VS code and work together. Don’t do a whiteboard test because that’s not the environment they’ll work in.

How do you deal with a “bi-modal” team made up of some veterans, and some new team members?

As you start to scale, you can end up with two very different groups – you might have 10 people who have been with a company five years, and 10 who have been there five minutes.

Be aware of this divide when you’re hiring – you can’t hire 20 new engineers if you only have 10 on staff. Your staff will need to interview and onboard the hires while also doing their jobs. Quality will suffer, and the tenured engineers are going to leave because they’re spending too much time babysitting.

Pair each new hire with a veteran – once a class of hires have been on the team 6 months, they’ll be able to pair with the next wave of new engineers.

How should you invest in growth and development?

Pair new hires with engineers working on the same codebase – so the new hire can have a mentor to lean on, and a sounding board on the same team to ask questions and learn from.

Give new hires a 30-60-90 plan – it should include all the skills and tasks to successfully navigate their first several months. Start from the basics: setting up a developer environment, building the product, writing a unit test, pushing code into production, and participating in the design discussion.

Design career growth programs for your company – you need to invest in career progression and compensation design as you get to ~30 engineers. What does career growth mean? How can employees offramp into other functions (like product management) if they choose to? People will ask about compensation and promotions, and they’ll want regular feedback.

Hire managers along with engineers – many companies forget to hire managers while they’re scaling initially. You end up with 20 engineers who don’t report to anyone. Get ahead of this and ask what the management layer will look like while you’re considering adding individual contributors.

You need to hire self-motivated learners and provide them with managers/mentors who will coach and advise on career development – you can’t spoon-feed skills. Provide engineers with leaders who can advise on how to develop, but the engineers need to have the desire and initiative to make good on that guidance.

As you grow engineering headcount, what other specialists should you add What are rough ratios for each?

Engineering Managers – 1:7 to 1:10 – a healthy ratio is one manager for every 7-10 engineers. If you have a very experienced team, it can extend to 1:15, but that’s hard. Engineering managers can cover between 2-4 engineering teams.

Product managers – 1:4 to 1:8 – PMs should correlate with engineering team count, not necessarily individual engineers. Each product manager can handle 1-2 engineering teams—a typical team has ~4 engineers.

Designers/Front-end engineers – 1:4 to 1:8 – staff designers for your front-end focused teams (back-end teams may not need them). One designer can typically work with 1-2 frontend-focused engineering teams.

DevOps/Infrastructure – if you’re a SaaS company hosting infrastructure, you need an infrastructure team that you’ll slowly build as your infrastructure needs grow. Staff it with DevOps SysAdmins or SREs whose skillsets are managing infrastructure and provisioning and monitoring servers. Hiring a full-time DevOps employee should be an opportunity cost calculation. You hire full-time DevOps when you want to unleash full-time engineers to develop. Typically, a FTE for DevOps comes when you hit 10+ engineers.

DBA – at growth-stage companies, you can typically get by outsourcing any database-related needs to third-parties.

Quality assurance/QA engineers – most early-stage companies only need one or two for the entire engineering organization (even at 50-100 engineers). The onus of testing should be largely on the engineers. QA will handle the tests that are very difficult to automate and need to be manual or tests with high load and monitoring needs (like a long-running stress test).

What standardized processes do you need to establish as you scale?

Prioritization process – maintain an interface for prioritization planning between engineers and product–you need product and engineering to be on the same page regarding what needs to be done and why. It’s easy when everyone fits in a room but as you grow the interface blurs.

Release management process – how do you know when something is done? What needs to happen before it goes out? As you scale, you’re adding other teams like sales, marketing, and finance, who all need to be involved and aware during the launch process, and you need a process to handle this.

Scoping process – always discuss expected length of development. Early scoping and problem definition between product and engineering that will leave both with a better idea of what the end goal is and how to get there.

Don’t over-index on output-tracking processes – fancy project planning activities are less important than surfacing the important problems engineering needs to solve. You don’t need to sweat over activities like storypointing with Fibonacci sequence points. You need to define the problems for engineering and they should be competent enough to complete them.

What changes when you start serving large enterprise customers, or very large numbers of customers?

Enterprise customers will request customization—make disciplined exceptions – if your product isn’t a perfect fit for an enterprise customer but early on you really want to win that deal, they might know that and ask for things that aren’t in your roadmap. Make disciplined exceptions for important customers so that you can build a repeatable process and scalable product.

Avoid “whiplash” development – work with your sales team to say no. Engineering needs to work on the roadmap and won’t appreciate it if sales is always walking in and pulling them away to build random customizations to win a deal. The more mature you become the more disciplined you can afford to be.

Customer count shouldn’t matter unless you have a quality issue – look at the number of escalations normalized by customer count. If it’s linear, then you’ve got a quality problem, if it’s an asymptote, then you can get more customers without worrying about quality.

How should tech leaders in a rapidly-scaling org “manage up” with the CEO/board?

Report the high-level results that leaders need to do their job – the board might care about things like product quality, roadmap, new features, customer feedback, and traction. The CXO-level will care about derivatives of those: projects in progress, hiring, personnel changes, and delivery updates. The cadence of CXO updates might also be more frequent (weekly).

To manage expectations, find out what leaders need to know, how often, and why – get to the bigger problem that leadership is trying to solve so that you can deliver the information they need and keep them informed.

Expectation setting goes both ways – leadership shouldn’t sell things that you don’t have, they also need to give you a heads up on any big upcoming changes so you can do your job as an engineering leader.

What are the most important pieces to get right?

Button up your interview and onboarding process – institute an efficient and effective process for hiring quality engineers, then develop a well-defined onboarding process. You need to have a thoughtful and repeatable way to get new hires up to speed and contributing.

Provide meaningful work for new hires – you don’t want to hire new engineers to sit on their behinds. That won’t be helpful for you or them.

Invest in the people function – invest in all your people programs including HR, career development, compensation, and development.

What are common pitfalls?

Don’t burn out your team (they’ll leave) – if you don’t scale within a reasonable timeframe, you can end up hiring 10 engineers and losing 15 at the end of the day. Hiring takes time and you can overburden your tenured employees if you aren’t mindful.

“Whiplash” development – as you’re scaling try to keep engineers from jumping back and forth between development priorities.