Photo by Ryan Quintal on Unsplash

5 Pros and Cons of combining the CTO and CPO roles

My experience working at this “CPTO” role for the last two years

Depending on company age, industry, and evolution, they have very different structures for their product development organizations.

Since going into the details of those different scenarios may require a very long article, I want to focus on companies that are in a situation similar to one of these options:

• Have both CTO and CPO roles (most grown tech startups where the CEO already left the product vision in the hands of the CPO)
• Have product reporting to a technical oriented CTO and are considering hiring a CPO
• Have product reporting to Marketing or another business role and are considering hiring a CPO reporting to the CEO

These companies may benefit from examining the option of a combined role.

Describing the roles

It is not my intention to make a full description of each, but it is important to understand the difference between these roles.

The CTO is the most “traditional” and widespread role, existing in most organizations (even if it is with other names), and is in charge of the development, implementation, and maintenance of the software solutions required for the business. It may also be in charge of other technical aspects like the wifi network in the office and hiring services like productivity suites (Office, Gsuite, etcetera).

The CPO is an emergent role, mainly due to the growth of the Product and UX disciplines (of which they will be responsible), and the importance of the product strategy for the company’s success.

Most CPO vs. CTO articles agree that the CPO is in charge of the “Why” and the CTO is in charge of “How” mimicking how product teams work (Product Manager tackling why and development how to implement it). There is a middle ground about the “what”, which probably requires agreement between the two.

In reality, both roles have the same goal: create and run products customers love and succeed in the market. But with the above mentioned different responsibilities.

Combining the roles

Finally, getting to the heart of the article! Combining both roles is merely putting someone in charge of the entire product development and product operation disciplines.

This person will require both a deep product-oriented mindset and a strong technical background. They will be responsible for the “Why-What-How” and will own decisions from product vision and strategy to the technology strategy accompanying it. The CPTO will have in-depth knowledge of the customer, understand the market conditions, communicate with stakeholders, and negotiate with technology service providers.

Pros

1. Centralized accountability: since both roles have the same goal, it does make sense to have one person with ultimate responsibility to achieve it. The split structure gives some room for blaming (in any case, this will still happen with other roles like CMO or COO, I guess it is just human nature :D ).
   From a CEO perspective, I do not know why two different 1–1s about the same topics may be desired.
2. Centralized reporting and communication: similarly, stakeholders will know that there is a single line of scaling for any type of issue. With the two functions, sometimes it is hard for stakeholders to know that when the site is down, they must talk with the CTO, but when they want to change the roadmap, they speak with the CPO. The same is valid for reporting: a single person may communicate OKR results, site SLAs and complete R&D budget.
3. Structure and resource allocation decisions. Most modern product organizations work with interdisciplinary cells, split reporting up the CEO level may rise to the top some problems that may be able to be solved at the CPTO level in a combined structure. Also, a big part of executing the product strategy is allocating resources to the essential products. This decision may be harder if there are separate budgets and goals for the CTO and the CPO, and they have to negotiate it.
   Furthermore, it clarifies where some functions report to (like Agile Coaches).
4. Product culture: a critical aspect of creating a successful product organization is to develop a strong culture (as visible in Netflix, Spotify, Google, and countless successful examples). Having a single “department head” for the entire members of product development cells make it easier to foster a unified and powerful product culture.
5. Tech vs. product-driven and amount of tech work: some companies are said to be tech-driven and others product-driven. Even when this is kind of silly, there is a typical “tension” or “power conflict” between the two groups. One of the most visible aspects is how technical work is considered and how much time is assigned to things like technical debt, refactoring, and automation. Again, with the CPTO role, this can be resolved as a very informed decision inside the department instead of having two people arguing it with the CEO who may not have the tools to decide (other than the one who cries louder).

Cost reduction: a final benefit for budget-constrained companies, one salary instead of two :)

Cons

1. Lack of strong “discipline” management. I’m a firm believer that managing roles in the different disciplines of product development (like Product Management, Product Desing, Development, QA, Agile, etcetera) requires an in-depth knowledge of their function to be able to add value to the individual contributors doing the work. Combining CPO and CTO roles will probably result in the “weakest” side of the one doing the job suffering from technically weak management. This problem can be partially solved by having a strong “VP” role to help out. In my case, I’m much more product-oriented, and my Director of Development helps me make more technically strong management of the DevOps team.
2. A wide span of control over very different disciplines: being in charge of things ranging from product strategy up to wifi connection gives you a vast array of problems to solve, of very different characteristics. It is hard to split the important (product strategy) from the urgent (wifi is down) and prevent the latter from consuming time from the things that truly add value. Again, this may be solved by having strong positions in support areas that have the autonomy to handle most interruptions and prevent them from getting to the CPTO.
3. Requires particular expertise and skillset: I would argue you need a very product-oriented person to fill this role. There are technically risen CTOs with this product orientation. Still, it can be more difficult for them to be involved in activities like research and product discovery that are key to a strong product strategy. The option I vouch for is to have an experienced product person that has a strong development background and can have informed discussions about architecture or infrastructure without being its core discipline. I believe these profiles will continue to grow as more tech startups serve as career ladders for technical folks moving to product roles.
4. Time constraints: the counter-argument for centralized communication and reporting is how busy this person can be. If trying to meet with every stakeholder or even with so many different topics to tackle, it may be easy to fill up the calendar. Thankfully, at the core of the autonomous interdisciplinary product team structure is decentralization. In essence, teams will be able to make their own decisions and discuss them with their pairing stakeholders in the rest of the organization.
5. “Bouncing ideas”: when the Product Manager and Tech Lead couple works well, it has a powerful combination of different views that drives great innovation. Similarly, when CPO and CTO make a good couple, they can have a powerful impact on the success of the product and the company.

Conclusion

Sorry to say it, but deciding if this role may work for you entirely depends on your company’s structure and situation.

Many, many, many organizations work wonderfully with CPO and CTO, with a very healthy relationship with both. This result may point to the split role structure as the most reasonable one. Especially for larger organizations, having these functions divided makes a lot of sense from a focus and skill set perspective.

But if you are considering this from scratch and your organization is growing, you may want to give this position a shot. Worst-case scenario, you split it later (it is harder to combine two existing roles than to cut one function in two).

Note: this story was originally published in LeanExperimentation.com. If you enjoyed it and want to receive more tools & tips to improve your product, you can subscribe here and join +1200 readers of my Lean Experimentation blog!