Scaling your engineering team from one to 50 and beyond

Building a company from scratch requires a high tolerance for uncertainty and risk — no matter how promising the founder, product, or business model is. But even leaders who seek out the rapidly changing environment of an early startup may avoid or delay making changes once the company becomes more established. This predilection for keeping things the way they are is so universal that researchers coined a term for it: the status quo bias.

When it comes to scaling engineering organizations, embracing the status quo is very common and very detrimental. Founders and engineering leaders who only introduce change in response to problems that arise often end up choosing band-aid solutions that can cause more problems down the road (and require more band-aid solutions).

“As a leader, you’ll encounter many one-way doors: big decisions that may not feel big in the moment but will have ripple effects across your company and will be hard to reverse later,” says Jessica Popp, Bessemer operating advisor and SVP of engineering, security & IT at Rula. “It’s tempting to delay difficult decisions or to keep good systems in place past their expiration date, but it’s always better to make changes proactively, with a plan to manage potential side effects.”

Jessica is speaking from her experience across her long tenure in Silicon Valley. In her nearly 30 year career, she’s learned exactly what it takes to scale an engineering organization while maintaining its efficiency, impact, and culture. After getting her start as an engineer, Jessica quickly rose through the ranks into management and then senior leadership positions, eventually holding VP and CTO titles at SendGrid, Twilio, Ada, and now Rula, a company in the behavioral health space with a mission to make mental healthcare work for everyone.

In this guide, Jessica gives critical insight into some of the one-way doors founders, CEOs, and engineering leaders are likely to encounter on the journey to scale. Whether you’re deliberating whether to start hiring internationally or when to bring in new engineering leadership, Jessica’s advice can help you come to the best decision possible and then prepare for what comes next.

Adjust your leadership to fit your stage

As a startup evolves, the responsibilities and required skill set of its leaders evolve alongside it. That means that the CTO or engineering leader who did an excellent job scaling your engineering organization from one to 20 may not be the person best suited to scale it from 20 to 50. Or, you could have a CTO who really could rise to the challenge, but would need additional outside mentorship or a team of managers who have more experience at larger companies.

Assessing a direct report’s abilities can be hard, and it only gets harder when it comes to people we love working with and who’ve been critical to a company’s success in the past. “When someone is talented in one area, it’s natural for us to overestimate their capacity in another,” says Jessica. “That’s why it’s so common for founders and CEOs to wait until there’s a loud signal within the engineering organization that a change is needed before they’re willing to make one.”

What your engineering organization requires from a leader will change as it scales.

But waiting can actually cause these issues within the organization to become more entrenched, or can lead to hasty decisions. “If your company is successful, you’ll likely need to change or augment your engineering leadership several times. Teams and companies do better when CEOs face that reality head on and evaluate engineering leadership regularly.”

What your engineering organization requires from a leader will change as it scales. Here’s what Jessica recommends CEOs and founders take into account at three critical stages: seed stage to roughly 10 engineers, 10 to 20, and 20 to 50.

Stage 1: Seed to 10 engineers

Most startups have at least one technical founder who typically leads an engineering organization from the seed stage to around 20 engineers. “At this stage, the focus is really on building the product — first getting your MVP out the door and then adapting, building, and modifying as you search for product market fit. To do that well, you need a leader who is hands-on in the code. If they have a strategic perspective on architecture, that’s a big plus,” says Jessica.

"From Seed to 10 engineers, you need a leader who is hands-on in the code."

If a startup doesn’t have a technical co-founder, the CEO will need to bring in a technical leader who has the experience to lead a small team through the initial product build, and who has comfort working with scarce resources, balancing managerial and individual contributor (IC) responsibilities, and dealing with other challenges and dynamics typical to seed and Series A-stage companies.

Stage 2: 10 to 20 engineers

At the seed to 10 engineer stage, everyone is likely working as individual contributors and reporting directly to the CTO, whether that’s the co-founder, or someone else. Once your team grows beyond 10 engineers, it’s helpful to have more structure.

“I would consider bringing in at least one manager who can prioritize projects, manage engineers’ workloads, address any issues within the organization, and establish the minimum people, operational, and technical processes that the organization needs. You don’t need to worry about career paths and performance plans at this stage. It just helps to have one person responsible for making sure the team is focused on the right goals and is working in concert to achieve them.”

The 10 to 20 engineer stage is typically when engineers will face other “one-way doors,” and it’s important to be aware of decisions where you could benefit from a more informed perspective. “Make sure you have the right people on board to help your team make the best decision. You may need to bring in a specialist or seek opinions outside of your organization,” says Jessica.

“For instance, any engineer can go out on AWS or GCP and pick a managed service and data store. But if you realize that data, data flow, or data scaling is critical to the success of your product, you want the person evaluating your data store choices to be someone who has made this decision before. Maybe that’s your CTO or maybe you need to bring in someone else to help you make the decision.”

Jessica gives another example of software testing. “Currently, the most common model is for each scrum team to be responsible for their own DevOps, but you might choose to build a separate quality team. While this decision might not feel like a big one when you’re making it, anything that impacts your team’s day-to-day operations can become a core part of your engineering organization’s culture. Once that happens, it will be very difficult to reverse course. So when you encounter these types of decisions, set aside the time to really think it through.”

Stage 3: 20 to 50 engineers

Around the 20-engineer mark, Jessica recommends that founders and CEOs determine whether they need an engineering leader with expertise in people and scaling, or whether the current CTO can take the organization to the next stage. Making this decision well requires taking stock of the challenges your company is facing, and then determining what skills and experiences an engineering leader will need to have to solve them.

Scenario 1: Your biggest challenges are people-related

Post-product-market fit, engineering organizations have typically exhausted what they can achieve with line management alone and are feeling the friction. This is typically when CEOs bring in a more people-focused engineering leader to the organization like Jessica, either as the CTO, or with an VP or SVP of engineering title.

“If your biggest challenges are productivity, culture, career pathing, and turnover, it’s time to look for someone who has led a high-functioning engineering organization in the past, who has managed managers, and has experience setting direction. This person should have a track record of introducing performance management, building operational processes, improving product quality, driving down incident rates, and getting software out the door on time.”

It’s also critical that the person has experience leading different types of engineering skill sets.

“It takes different techniques to manage different groups,” explains Jessica. “Find out how much of the engineering function the person has experience managing. And not just application skill sets — they need to have managed things like DevOps and security as well.”

In Jessica’s experience, it’s better to find a leader who has past experience scaling an engineering organization to 50 engineers and beyond. That may be your current CTO but it may not be. “Do your best to give an honest and unbiased assessment of whether a current leader is suited for the role, or whether the organization would benefit from having someone new.”

Scenario 2: Your biggest challenges are product-related

In the second scenario, you’ve still reached the 20+ person engineering milestone and the biggest challenge is reworking or scaling your initial product, or continuing to be successful in your market with a highly specialized and technical product.

“To do this well, you need someone who is great with external customers and is able to be a point person on critical architecture decisions,” says Jessica. “Often, your initial CTO or technical co-founder is this person. If that’s the case, be very clear with your co-founder and board what role the CTO will be playing as the organization matures. For example, the CTO might decide: ‘I’m going to run a two-person architecture team and set the technology vision, and the SVP of engineering will manage the other 50 or so people and organize them to execute on the vision. Whatever set-up is going to be, it should be transparent and determined in advance.”

Like for all decisions, Jessica emphasizes the importance of being conscientious about the trade-offs of the decision you make, and having a plan for how to fill any gaps. “If the type of product, customer, or challenges your organization faces warrants sticking with very technical senior leadership, maybe you bring in middle managers who can step in to support process, career, and team development.”

Choose your hiring locations and remote work policy wisely

Since the pandemic, many companies opted to make fully or partially remote work permanent. Sixty-seven percent of startups with 100 employees or fewer offer a fully flexible work policy — meaning employees can work fully remote and choose when to come into the office. Hybrid work policies are also becoming more popular among tech companies that have 25K+ employees, with 65% of employers allowing some amount of remote work with mandatory in-office days.

The rise of remote work seems to have also accelerated international hiring among small and mid-sized companies. In another survey, 68% of employers reported that they had at least one remote US employee prior to making an international hire, and 72% reported that a positive experience with a remote employee influenced their decision to hire globally.

Regardless of the policy a company adopts, where engineers live and how they work will affect everything from hiring plans and budget to collaboration and product quality. Every policy has pros and cons, so it’s important for leaders to always: (1) choose a policy based on a strong business case — not a preference or fear; (2) identify any constraints of the chosen policy; and then (3) set up the team to be as efficient and effective as possible under those constraints.

“Make sure that the benefits of a particular set-up aren’t overshadowed by the issues that the set-up creates,” says Jessica. “Similarly, avoid any policies or practices that create stratification or inequities among team members based on where they live or work, and if they do, put some systems in place to offset those issues.”

In our conversation, Jessica gave us a detailed overview of the benefits and challenges of three common policies — remote global, remote US, and hybrid US — and how to set up your team for success under each.

Remote global

In Jessica’s experience, the strongest business case for hiring engineers globally is access to talent. “If you’ve maxed the available talent in your current location and/or there’s an abundance of a specific skill set or subject matter expertise in another country, that’s a great reason to build a global engineering team,” says Jessica.

The strongest business case for hiring engineers globally is access to talent.

Another reason that engineering leaders tend to hire internationally is to save budget on headcount, but recently, Jessica has started questioning whether this is really an effective long-term cost-saving strategy. “The global pay rates for knowledge work have gotten closer and closer over the years, so I don’t see it as the strong business case it once was.”

The decreases in efficiency that often come with having engineers in multiple countries can also outweigh whatever costs a company does save. “The communication challenges can be hard to overcome. I worked for a company that had teams in 18 countries. Because of the time zones, you’d ask a question and hear back a day later. Often, the person needed more context or wasn’t the right person, and so it would take three or four days to get unblocked,” recalls Jessica.

How to prepare for a global engineering team

If your company ultimately chooses to hire a global engineering team, Jessica recommends using the following principles to reduce some of the common side effects.

• Keep teams with dependencies on similar time zones: “Outcomes improve when people aren’t trying to collaborate across an ocean. Make sure scrum teams have the same basic daytime, and if you have a set of applications that are highly related, the teams that work on those coupled parts would ideally have the same daytime too.”
• Make sure that strategic work happens in every location: “When employees in the US are given the highest-priority projects and responsibilities, engineers in other locations have to wait for those in the US to make decisions, causing bottlenecks. Plus, people don’t perform as well when they think the things they’re working on just aren’t important.”
• Create opportunities for in-person connection: “If you sit by someone and share a meal, it creates trust and empathy really quickly, and that reduces the chances of ending up with an “us vs. them” mentality between offices. The benefits of in-person connection are hard to replicate over a computer screen, so make sure that engineers have the chance to meet colleagues in other locations — even if it’s just once a year or even less.”

Remote US

A remote US policy can also increase a company’s access to engineering talent. Competition for engineers in large cities remains higher than other places, and by offering remote work, smaller companies can get a competitive edge over bigger tech companies that offer higher salaries but have returned to fully in-person or structured hybrid work policies that some engineers avoid.

Recent surveys show that employees across industries prefer remote work policies, with 65% of workers reporting they want to work remote all of the time and 98% wanting to work remote at least sometimes. “Engineers typically have a strong preference for either in-person or remote work, and in my experience, that preference is more often for remote,” says Jessica.

Hiring remotely can have the added benefit of increasing the diversity of a startup’s applicant pool. In a Wharton study, identical jobs listing that were changed from in-person to remote policies, drove a 15% increase in female applicants, and a 33% increase in applicants who are underrepresented minorities.

Hiring remotely can increase the diversity of a startup's applicant pool.

In addition to improving hiring outcomes, remote is also cheaper. “Because of the varied cost of living, hiring nationwide instead of just within tech hubs tends to reduce your costs,” says Jessica. In addition to savings on salaries, companies can save as much as $11,000 per employee on office space, utilities and other resources.

Adopting a remote policy comes with its fair share of challenges, too. Unlike in-person or hybrid models where teams get significant facetime with colleagues and leadership, remote engineering teams may struggle to build and maintain a consistent culture, develop more junior engineers, and create strong working relationships that improve collaboration between team members.

How to prepare for a remote engineering team in the US 

• Invest more in company culture: “When you’re in an office, it’s a lot easier to establish culture through the everyday performance and practices of leaders. When everyone is working remotely, leaders have to be much more explicit about those expectations.”
• Make sure practices are consistent: “It’s important not to have exceptions to your policy. Don’t let a team start hiring exclusively in Austin because they want to go out to lunch. Otherwise it can compromise equal access to opportunities and internal mobility for engineers.”
• Be more intentional about mentorship: “It’s really hard for engineers out of college and even L2 engineers to get the support and learning opportunities they need within a remote company. So much of what we learn is through osmosis, so if you go remote, set the expectations for senior engineers and managers to dedicate the time for mentorship.”

Hybrid or in-person

The common reasons that leaders choose structured hybrid or in-person policies usually aren’t good business cases for those policies. “I don’t have a strong personal preference for in-person vs. remote — it’s a pendulum that tends to swing every fifteen years or so. But when I ask other leaders why they want to return to the office, it’s usually because they’re worried about controlling output, and I don't think bringing engineers back to the office is the best solution to that problem.”

For seed-stage companies, though, Jessica does strongly recommend being in-person most, if not all, of the time. “Assuming your founding team isn't made up of friends who have past working experience together, in-person is the way to go. It’s very hard to build a brand new company entirely remotely. You’ll have to move so fast and make so many decisions to get your MVP out the door, and being remote will just slow you down.”

A less common business case for choosing a hybrid or in-person policy is a talent strategy that relies on hiring engineers who are right out of college or early in their careers. As Jessica explained, it’s much harder to learn from others when you’re not sitting next to them, and even when there’s a lot of investment and intention to give mentorship, it just isn’t the same.

How to prepare for a hybrid or in-person engineering team 

• Only hire near your office locations: “Having some employees work out of your offices and then some employees who are fully remote creates disadvantages for those working remote in terms of onboarding, communication, and work opportunities for everyone.”
• Set clear expectations with candidates: “If you have an in-person policy, you need to tell candidates exactly what that means in the interview process and stick to it for the long haul. Nothing will anger employees more than finding out the hybrid job they thought was two days in the office is actually three.”

Other timely considerations for engineering leaders

Determining the right leadership and work policies for your organization is just scratching the surface of all the weighty decisions startups leaders will have to make to scale an engineering team from a few to a few hundred. In our conversation, Jessica shared quick thoughts on two additional topics that are on the minds of many technical leaders today.

Decide when to invest in cybersecurity

Engineering leaders have to proactively ward against that threat of cybersecurity attacks — particularly as a company’s brand grows and becomes a bigger target. The timing of your initial investment in cybersecurity depends on your environment and the risk tolerance of your leadership.

Highly regulated industries

“In a highly regulated environment, you should be thinking about cybersecurity from day one,” says Jessica. “Often, I’ve seen companies following certain compliance standards to the letter of the law rather than the spirit of the law. My advice for CTOs is to know which frameworks are important to your business and make sure your organizational culture is really embracing the underlying intent of those frameworks, rather than seeing them as a tick box activity.”

"In a highly regulated industry, invest in cybersecurity from day one."

While a founding team might help set up initial team expectations and practices for cybersecurity and data protection, eventually, you’ll need someone who has the experience, expertise, and bandwidth to build more robust security around and into your product. For practical advice on how to make that first hire and build a successful cybersecurity team, read this how-to guide featuring former Netflix leader Jason Chan.

Less regulated industries

Early-stage

For startups in other environments, Jessica recommends investing in cybersecurity only after you see early signs of product-market fit. “When you’re still trying to find product-market fit, you don’t want to spend on anything that’s not an absolute necessity. And if you don’t have anyone using the product yet, cybersecurity is not an absolute necessity,” says Jessica. “Once you start to see traction with customers though, you’ll need to make it a real focus.”

Around the 15 to 20 engineer mark, Jessica recommends making a deeper investment and hiring an engineer with cybersecurity expertise who can start establishing some best practices. “Timing ultimately depends on how much risk you’re willing to take and how much of an investment you’re willing to make to offset that risk.”

Growth-stage

At the growth stage, a robust investment in cybersecurity is non-negotiable. At a high-level that looks like: integrating security practices into the function of every team and employee; securing digital identities and cloud and development environments; protecting data assets; and monitoring and addressing third-party risks.

“I would argue that security is core to the success of most SaaS companies today. The bigger you get, the more of a target you become, so you need to have both an ongoing program and do one-off security prep for things like big brand campaigns that increase in attention, and therefore, risk,” says Jessica.

For engineering leaders, security should be a factor in every decision. “Take the growing abundance of AI tools for engineers for example. These can make us more productive and happier because they eliminate menial tasks. However, we also know that the data we give can leak back into the model, and so you have to decide if that benefit is worth the trade-off.

“You may think, ‘Well people are just asking a coding question. They’re not sharing any IP. But we also know that the intent not to share IP doesn’t prevent you from doing so, and a long enough segment of code could allow a competitor insight into how you think about a particular problem.”

Engineering leaders will weigh those trade-offs differently, choosing to disallow AI tools altogether, only allow tools where the company is a single tenant on the model, or allowing use of all tools regardless. As Jessica encourages with the decision, it should be made intentionally and with preparation for the side effects.

Assess your need for AI talent

With any technical skillset, supply and demand changes, and with it, salaries. With the dawn of the AI era, hiring for machine learning scientists and other AI talent is competitive, and as a result, very expensive. “For the first time, AI has true applicability to the entire SaaS market, but that doesn’t mean that every team needs to hire AI talent. Your existing engineers can make third-party calls to an AI model and display the relevant responses inside your product,” explains Jessica.

“If you’re going to invest in AI talent, it should be because AI is core to your product, or it is a core to a piece of your product that requires you to build and augment the models yourself,” says Jessica. “In that case, I would hire one senior scientist who I really trusted, and make that one my very expensive hire. Then, I'll have one other person to support or I'll even hire outside contractors until more resources are absolutely necessary.”

Need input on a decision or challenge we didn’t address in this article? Engineers and leaders part of the Bessemer portfolio can schedule a meeting with Jessica and get personalized guidance on how to successfully manage and scale engineering teams.