Scaling Your Technical Org

Before we discuss hiring the right engineering or product leader for your company, it’s worthwhile to step back and ask some questions about how you’re scaling your technical organization. 

As your company grows and your technical org headcount increases, the structure of your technical teams is increasingly reflected in the products you ship—your company “ships its org chart.” One of the most important questions facing CEOs at the growth stage then becomes: how should I structure the relationship between my engineering and product leaders and their functions? (We’ve seen a recent trend where companies try to combine these leadership roles into a single chief product and technology officer (CPTO). However, in our experience, finding someone with the right combination of experience to both roles can be very difficult.)

While you could architect your technical org in a number of ways, generally, companies balance two considerations:

TABLE OF CONTENTS

Will you structure around your product units or your functions? 

A technical org structured around different product units embeds product managers, designers, and data analysts within the engineering teams. Each team has its own engineering leader with the latitude to make decisions quickly on their area of the product. These leaders then typically report to a senior technical leader, such as a chief product officer (CPO) or chief technology officer (CTO), who focuses on coordinating the different units into a cohesive product. While the upside is that teams can make decisions and build quickly on their product area, the challenge becomes finding a senior leader who can integrate the work of each team into a cohesive product suite. 

In functional org structures, each functional unit has its own chain of command: engineers report to an engineering leader, product managers report to a product leader, and so on. For companies with especially complex products, this structure allows teams to develop the specialized knowledge for running and shipping code. It also gives different teams the same context for how different functions are solving business problems across the unit. But it can be very difficult to make progress because those teams need to get buy-in from various leaders in order to move their work forward. 

How will you balance sustaining engineering on the existing product with building new products and features? 

As you reach the growth stages and have a product out in the market, you’ll need to balance maintaining your existing product with building net-new features or even new products. Engineers in Silicon Valley and other tech hotspots often want to work on newer, flashier products, so we often see companies add engineering teams in new locations, such as India or Eastern Europe, to sustain engineering on core products. 

Broader trends to consider

Two broader trends may impact how you structure your org or the types of leaders you’ll need to bring on in the coming years:

Product drives revenue, especially in enterprise. In the past, enterprise companies could sell high value, multiyear contracts and leave it to customers to figure out how to implement their products. Now, however, more enterprise software is adopted in the same way as consumer software: someone downloads and starts using it. For both consumer and enterprise software, customers expect an intuitive user experience. The best products allow users to self-onboard and get immediate value, then, over time, add more complex features that provide additional value. This means hiring product and engineering leaders who can build products with great design and user experience (UX), adding features, security, and reliability as the product scales to more end users. 

It’s very hard for an incumbent to lock out a startup with account control. The decisions have been federated to the edge now. Everyone is a buyer.
—Martin Casado, a16z Infra #3: What Microsoft Can Teach Us about Technical Product Leadership at Scale 

Customers have more options than ever, more buying and budget authority lower in the organization, and CIOs are less willing to buy a wall-to-wall solution unless it’s proven with internal champions. All of this means the product not only needs to be easy to use, at first—but that the most enduring enterprise products earn the right to be complex. These products provide immediate value to a user and then deliver “a crescendo of value” to the enterprise with new capabilities.
—David Ulevitch

AI is poised to deliver a seismic change in what products are built and how. With the advent of generative AI, AI can write and troubleshoot code, and already we’ve seen companies use it to automate lower-level engineering tasks, increase engineering efficiency, and even build APIs in a fraction of the time it used to take. Engineering and product teams who successfully integrate AI into their workflows are likely to be able to build faster and better than companies that are slower to adopt generative AI coding tools. Some questions to consider when implementing AI include:

• Engineering: how does AI best integrate with your current engineers? Does it shift the number of engineers you need to build the best code base? How could it change your process for writing and QAing code? 
• Product: does AI fall on your product roadmap? What AI-driven features might be big value-adds for your product? Should you be building your own language learning model (LLM)? If not, what set of architectural decisions are you making in order to use other LLMs? 

Next, let’s look at how to approach Hiring a Chief Product Officer and Hiring a Senior Vice President of Engineering.