The CPTO role did not exist at most companies ten years ago. It exists now because companies learned the hard way that splitting product and technology into separate organizations creates problems that are worse than the problems it was supposed to solve.

I was hired as the first Chief Product and Technology Officer at the Wall Street Journal. Before this, I was CTO at The New York Times. The difference between those roles is teaching me more about organizational design than any book on the subject. When technology and product report separately to different executives, alignment is a constant negotiation. When they report to one leader, alignment is a given. The work gets done faster, the quality is higher, and the talent stays longer.

Why One Leader

The argument for splitting CTO and CPO into separate roles goes like this: technology is complex enough to deserve its own executive, and product strategy is important enough to deserve its own executive. Both claims are true. But the conclusion does not follow.

The problem with two separate leaders is that their incentives diverge in subtle but damaging ways. The CTO optimizes for engineering quality, scalability, security, and technical debt reduction. The CPO optimizes for user experience, feature velocity, market fit, and business impact. These goals are not opposed, but they compete for the same resources, and the competition produces friction that reaches the CEO’s desk.

When the CTO says “we need to spend the next quarter on infrastructure” and the CPO says “we need to ship three new features this quarter,” someone has to arbitrate. If that someone is the CEO, two things go wrong. First, the CEO spends time adjudicating technical tradeoffs that they may not fully understand. Second, the organization learns that the way to get resources is to make the better argument to the CEO, which turns product and engineering into competing factions rather than collaborating teams.

A CPTO resolves this by making the tradeoff internally. They understand both the technical constraints and the product strategy. They can decide to invest in infrastructure for eight weeks and then ship features for four, or to interleave infrastructure work with feature development in a way that serves both goals. The CEO does not need to arbitrate. The organization does not split into factions.

Three Disciplines, One Organization

A CPTO leads three distinct disciplines: product management, design, and engineering — what I call PDE (product, design, and engineering). These disciplines should be separate, with their own leadership, career paths, and professional standards. But they should report to one person.

The reason is that product development requires tight collaboration between people who define what to build (product), people who design how it works and looks (design), and people who build it (engineering). When these three functions sit in separate reporting lines, every decision requires a cross-functional meeting, a Slack thread, or an escalation. When they sit in one organization, they can work as a single team with shared goals and shared accountability.

I have seen companies try the alternative. Product reports to a Chief Product Officer. Design reports to a Chief Design Officer or sits in marketing. Engineering reports to a CTO. The result is three organizations that each have their own priorities, their own planning cycles, and their own definition of success. Aligning them requires constant coordination overhead, and the people doing the actual work spend too much time in alignment meetings and not enough time building.

Under a CPTO, a product team consists of a product manager, designers, and engineers who work together on the same problems. The product manager defines the problem and the success metrics. The designer defines the user experience. The engineers build the solution. They share the same goals, the same timeline, and the same accountability. Disagreements are resolved within the team or escalated to a single leader, not across organizational boundaries.

Why the CPTO Needs Finance and HR

This is a point most companies miss. A CPTO leading a large PDE organization needs dedicated Finance and HR support, either as direct reports or strong dotted lines. Being effective as a CTO is hard enough; a CPTO without this operational support is set up to struggle.

The Finance lead helps the CPTO manage a large budget across multiple product lines, track spend against plan, model the cost of new initiatives, and present investment cases to the CEO and board. Without dedicated finance support, the CPTO either does this work themselves (poorly, because they are not a finance person) or relies on a central finance team that serves multiple departments and may not deeply understand technology investment dynamics.

The HR lead helps the CPTO manage hiring, retention, performance, compensation, and organizational development for what is often the largest and highest-paid department in the company. Technology talent markets move fast. Compensation benchmarks change quarterly. Retention requires understanding what engineers, product managers, and designers actually care about, which is different from what sales or marketing professionals care about. A generalist HR business partner who serves three departments simultaneously cannot provide the depth of support that a 200-person PDE organization needs.

These are not luxury additions. They are operational necessities for any CPTO running a PDE organization of meaningful size. At a small startup, the CPTO can manage finance and HR interactions directly. But once the organization reaches a hundred or more people, dedicated support in these areas is essential to the CPTO’s effectiveness.

The CPTO and the CEO

The most important relationship in a CPTO’s professional life is with the CEO. Everything else flows from that.

The CEO needs to understand that the CPTO is a strategic partner, not a service provider. The CPTO should be in the room when strategy is discussed, not called in afterward to implement decisions that have already been made. When the company sets its annual priorities, the CPTO should be shaping those priorities alongside the CFO, the head of revenue, and the head of content or editorial.

In media companies specifically, I believe the CPTO should also have a reporting relationship with the editor-in-chief and be a member of the newsroom leadership team. This is how my role is structured at the Wall Street Journal, and I had a similar dual reporting structure at The New York Times. Most CTOs and CPOs in media report exclusively to the business side, which means the newsroom sees them as outsiders. When you sit in the editorial leadership meetings, when you have staff on both the newsroom and the business side, the relationship changes. The newsroom treats you as one of their own. You understand their priorities, their constraints, and their culture from the inside, not through a stakeholder request form. This is a structural advantage that makes it far easier to build products that genuinely serve the journalism.

In return, the CPTO owes the CEO clarity, candor, and accountability. Clarity about what the technology and product organization can and cannot deliver. Candor about risks, tradeoffs, and where the organization is underperforming. Accountability for measurable outcomes, not just activities or outputs.

The failure mode I have seen most often — and I wrote about this in the context of IT culture vs. product culture — is a CEO who hires a CPTO, declares a digital transformation, and then does not change any of the organizational dynamics that created the problems in the first place. The CPTO arrives to find that business stakeholders still expect to define the product roadmap, that the budget process still treats technology as an expense center, and that the CEO still arbitrates conflicts between the CPTO and other executives rather than backing the CPTO’s judgment on product and technology decisions.

A CPTO can succeed only if the CEO genuinely wants a product culture and is willing to endure the discomfort of getting there. That discomfort includes telling powerful stakeholders that they no longer get to dictate the product roadmap. It includes restructuring budget authority. It includes patience when the first quarter of a new approach does not immediately produce visible results.

What the CPTO Actually Does

Day to day, a CPTO does five things.

Sets product and technology strategy. This means deciding what the company’s products should become, what technology investments are required to get there, and in what order to pursue them. Strategy is not a document that sits on a shelf. It is a set of choices that the CPTO makes every week when deciding where to allocate attention and resources.

Builds and maintains the organization. Hiring the right leaders and individual contributors. Designing the team structure. Creating career paths. Setting compensation philosophy. Building a culture that attracts and retains the best people. This is the work that most determines whether the PDE organization performs well or poorly over time.

Manages the portfolio. A large PDE organization works on many things simultaneously: new product development, improvements to existing products, infrastructure and platform work, security, data, and operational reliability. The CPTO decides how to distribute resources across these areas and adjusts that distribution as priorities shift.

Drives innovation and technical excellence. The CPTO ensures the organization stays ahead on technology adoption, experimentation, and engineering quality. This means creating space for teams to explore new technologies, running experiments that challenge assumptions, maintaining engineering standards that prevent the accumulation of crippling technical debt, and making the judgment calls about when to adopt emerging technologies and when to wait. A PDE organization that only ships features without investing in innovation and quality will eventually find itself unable to ship anything at all.

Represents technology and product to the rest of the company. The CPTO translates between the language of engineering and the language of business. They explain why a platform migration matters to a board that cares about revenue growth. They explain why a business constraint shapes a product decision to an engineering team that wants to build the technically elegant solution. This translation work is constant and never finished.

Who Should Be a CPTO

Not every CTO should be a CPTO, and not every CPO should be either. The CPTO role requires someone who can think at the strategic level about both technology and product, who can manage and develop leaders across multiple disciplines, and who has the organizational and political skill to operate at the executive level.

The best CPTOs I have known share a few characteristics. They are deeply curious about users and markets, not just technology. They are builders who also know how to manage complexity. They are direct communicators who do not hide behind jargon or slide decks. They earn the trust of engineers by understanding the technical work, the trust of product managers by understanding the business, and the trust of designers by respecting the craft.

They also know when to delegate. A CPTO who tries to personally review every product decision or every architectural choice will become a bottleneck. The job requires building a leadership team that can make most decisions autonomously, reserving the CPTO’s attention for the decisions that genuinely need it.

The Result

When this works, the result is an organization where product, design, and engineering operate as one team. Where the technology strategy and the business strategy are the same strategy. Where the CEO has a trusted partner who owns the product and technology portfolio and delivers results. Where talent wants to join and stay because they are empowered to do meaningful work.

That is what a CPTO does. The title is relatively new. The need for it is not.