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 (that require more band-aid solutions).
As a leader, youll 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. Its tempting to delay difficult decisions or to keep good systems in place past their expiration date, but its always better to make changes proactively, with a plan to manage potential side effects.
Jessica is speaking from her collective experience across her long tenure in Silicon Valley. In her nearly 30 year career, shes learned exactly what it takes to scale an engineering organization while maintaining their 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 roles 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 youre deliberating whether to start hiring internationally or when to bring on new engineering leadership, Jessicas advice can help you come to the best decision possible and then prepare for what comes next.
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 that 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 reports abilities can be hard, and it only gets harder when it comes to people we love working with and whove been critical to a companys success in the past. When someone is talented in one area, its natural for us to overestimate their capacity in another, says Jessica. Thats why its so common for founders and CEOs to wait until theres a loud signal within the engineering organization that a change is needed before theyre 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, youll 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. Heres 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.
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, thats a big plus, says Jessica.
"From Seed to 10 engineers, you need a leader who is hands-on in the code."
If a startup doesnt have a technical co-founder, the CEO will need to bring in a technical leader who has the experience to lead a small team 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.
At the seed to 10 engineer stage, everyone is likely working as individual contributors and reporting directly to the CTO, whether thats the co-founder, or someone else. Once your team grows beyond 10 engineers, its 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 dont 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 its 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 thats 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 youre making it, anything that impacts your teams day-to-day operations can become a core part of your engineering organizations 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.
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.
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, its 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.
Its 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 Jessicas experience, its 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.
In the second scenario, youve 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 thats 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: Im 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 it is, 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.
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 its 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 arent 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.
In Jessicas experience, the strongest business case for hiring engineers globally is access to talent. If youve maxed the available talent in your current location and/or theres an abundance of a specific skill set or subject matter expertise in another country, thats 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 dont 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, youd ask a question and hear back a day later. Often, the person needed more context or wasnt the right person, and so it would take three or four days to get unblocked, recalls Jessica.
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.
A remote US policy can also increase a companys 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 startups 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.
The common reasons that leaders choose structured hybrid or in-person policies usually arent good business cases for those policies. I dont have a strong personal preference for in-person vs. remote its 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, its usually because theyre 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. Its very hard to build a brand new company entirely remotely. Youll 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, its much harder to learn from others when youre not sitting next to them, and even when theres a lot of investment and intention to give mentorship, it just isnt the same.
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.
Engineering leaders have to proactively ward against that threat of cybersecurity attacks particularly as a companys brand grows and it 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, Ive 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 initially help set up initial team expectations and practices for cybersecurity and data protection, eventually, youll 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 youre still trying to find product-market fit, you dont want to spend on anything thats not an absolute necessity. And if you dont have anyone using the product yet, cybersecurity is not an absolute necessity, says Jessica. Once you start to see traction with customers though, youll 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 youre willing to take and how much of an investment youre 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. Theyre not sharing any IP. But we also know that the intent not to share IP doesnt 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.
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 doesnt 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 youre 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 very expensive hire. Then, I have one other person to support or even hire outside contractors until more resources are absolutely necessary.
Need input on a decision or challenge we didnt 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.
Go here to see the original:
Scaling your engineering team from one to 50 and beyond - Bessemer Venture Partners
Read More..