A few nights ago I attended a SVSG panel discussion, which focused on the attributes of a successful startup CTO. Broadly speaking, there was agreement that the CTO has to have business sensibility, understand the product, and take a primary role in the development. However, based upon some of the questions that followed, it seems there may be some value to further elaborate on what the role entails and how it co-exists or overlaps with the roles of product management, VP engineering, lead developer and software architect.
Let’s focus on two initial concerns of all startups: first, finding the market need and formulating the product or service that fills that need; and second, actualizing this product or service. Product management’s responsibility is to understand the market and develop a solution that addresses a particular need or desire. The CTO’s primary role is to understand the proposed solution and develop the actualization strategy. As one participant put it: Product management is about building the right product, and development is about building the product right. But what is “right”? The CTO’s definition of “right” must be fully grounded in business priorities. While every founder is passionate about having identified the problem and the solution, seasoned investors understand this is just a hypothesis which needs market validation (and very likely, reformulation). If the management team buys into this and the product is unproven, the “right” product may be very minimalist and only test the key, highest value features (the MVP), and the “right” way to build it may be to prototype it using some off-the-shelf framework that the CTO knows will not scale. Perhaps the implementation will not even cover corner cases, and initial users will experience occasional errors. In this scenario, what is business “right” is antithetical to what is technically “right”, or even final product “right” for that matter. The CTO must understand these tradeoffs, communicate them and their justification to all concerned, and plan for transitioning the product to a more scalable architecture as needed.
Additionally, the CTO is generally responsible for establishing the company’s technical direction and culture. This includes understanding how the technology landscape is evolving and where to place bets. For example, whether to jump on a new technology that promises great benefits or go with something that is tried and true.
Depending on the industry the company is servicing, there are a few other items on the CTO’s plate:
- Understanding the business domain, core constructs and abstractions, and making sure these are reflected in the software modeling and architecture. This may be simple for a consumer product, but is a bigger deal if the company is developing, for example, software for handling FDA drug testing or compliance. Initially, the CTO is often the chief architect, but as the company grows, the role should transition to education and mentorship.
- Understanding what about the company’s solution is unique (and should therefore be developed in-house) and what can be outsourced.
- Describing and evangelizing the product’s technology
Let’s spend a few minutes discussing how the CTO role differs from another technical leadership role: VP of engineering. Usually, the VP of engineering is the tactical implementer of the CTO’s strategic vision, responsible for schedules, specific methodology implementation, and the engineering team, which normally reports to the VP rather than the CTO. In practice, this means that, for example, while the CTO may decide on using NoSQL databases, it’s typically the VP engineering that assigns the resources and manages how it is implemented. Of course, the two roles are tied at the hip, which is why they’re often filled by the same person, and if not, they had better be brothers in arms.
At the panel, there was also some discussion as to how much time the CTO should spend coding, with some estimates running as high as 70% initially and generally staying above 50%. I’m not sure I agree that the coding portion has to be this high once the company moves past initial product development and focuses on growth. To me, by far the most important role the CTO plays is strategic: understanding the business domain, the company’s business priorities, formulating the technical strategy for servicing these priorities, building the culture, and above all communicating tradeoffs, decisions, and activities between the technical and the business teams. As such, the CTO role requires more breadth than technical depth, more understanding of technology direction and less optimal solution algorithm for a particular problem. Often, business and technical teams have different priorities and constraints. The CTO is effectively the emulsifier that makes the whole thing work as one. If a company is a salad dressing, the CTO is the mustard that helps keep the oil and vinegar together. From these requirements, the characteristics of the successful CTO become clear: big picture view, understanding of the technology landscape and specifically how it must be used to serve business goals, strong leadership and communication skills, and good judgment.
One final note what I have described is the canonical CTO role. In the same way that the presence of Lebron James changes the role of the “point guard” on the Cavaliers team, the best CTO for a particular company may in fact skew more toward the business or technical side.
Farhad Farzaneh
A software technologist who enjoys building useful products. After obtaining his Ph.D. in Medical Physics from Duke University, Farhad headed to the startup mecca of Silicon Valley, where he has held technology and product executive roles at various startups in industries that span medical imaging, telecommunications, Fintech and consumer apps. He finds elegance and efficacy in simplicity, and is a big fan of iterative development.