The CPTO role from people who know
Last week, I facilitated a panel of impressive and accomplished CPTOs on the realities of the role, how they got into it and – especially in light of current AI developments – where they think it’s heading next. Here are some notes.
No set path into the role
The CPTOs were from a range of backgrounds, and they had really interesting career journeys. Broadly, two were from a product background and two from an engineering background (including one who started out working on building planes) but the theme that really came out was being people who solve problems. People who take ownership, and are adaptable, and as a result get additional responsibilities.
You don’t need both backgrounds
I asked the panel what was hardest to pick up about the discipline that wasn’t their background. One note was that with technology, no-one wants to own it, they are happy that you are taking care of it. But with product, suddenly everyone in the business wants a piece of it.
Interestingly though, no-one had a specific example that was a blocker. Prior to this discussion I had been speaking with a CPO who felt that the lack of an engineering background would be a blocker to the role, but the panel agreed that this was not the case. It’s not about being able to do all the things, it’s about creating the systems that allow people to be successful, as per any role where you don’t have all the backgrounds (CEO for example!).
One of the panellists who had come directly from a CPO role explained that key was building trust with the engineers, which doesn’t have to depend on literally being able to do their job, but on really listening to what they say and demonstrating that you’ve taken it on board.
Picking the right second-in-command is of course crucial; the senior person who has the background or depth of understanding that you don’t.
What about the healthy friction?
One of the advantages of having a CPO and a CTO working alongside each other is the (ideally) healthy friction and challenge that leads to better outcomes. I asked the panel if they missed that and if so, where they found that challenge.
The overall consensus was no, they did not miss it; the trade-off in being able to make faster decisions, think more holistically about value, and have ownership of the whole area feels definitely worth losing that peer relationship, and the panel agreed that in any case, not every experience of working alongside a peer to co-lead product and technology does meet that constructive ideal.
However, there are some disadvantages to being the sole person in the seat that you need to mitigate. You can become an echo chamber, so you do really need to seek out that challenge, and make sure it is someone with the courage to stand up to you.
You can also end up making decisions too quickly for the organisation. When you have a product or tech counterpart, the work you do selling your idea to them is good practice for the questions your teams may ask, and allows you to work through the details of the answers before going wider. It also gives people time to catch up. When you are working solo you need to build in mechanisms to do those things.
Keeping the trade-offs internal
One panellist noted that as a CPO, it is possible to think relatively linearly; quarterly plans rolling up into half-year and annual goals. However, as a CPTO, they feel like it is more like a Rubik’s Cube: every decision affects multiple horizons at the same time. It becomes your responsibility to balance long-term platform investment against near-term customer value, or immediate commercial outcomes against future optionality.
These time horizons need to be balanced even when there are two people in post and can form part of the healthy friction in a well-functioning CTO/CPO relationship; having them both in one role makes it easier to focus on creating an environment where good decisions can be made across different time horizons.
Similarly, another panellist noted that because as CPTO they were responsible for the whole platform, they had a lot of autonomy. The rest of the exec team are less interested in dictating what they do as long as they stay within budget.
These both demonstrate a difference for the exec team in having this role. Where there are two people in the role, some of these trade-offs will surface and need to be addressed by the CEO or rest of the exec team.
You may need a lot of airtime at the exec table
When one person is the CPTO they may end up really hogging the floor in exec discussions and at offsites, etc. For example, here’s why we need additional investment in engineering; also, here’s why we need additional investment in security; also, here’s why we need additional investment in data, etc.
One panellist responded to this point by saying they often bring in their team to speak to those things, which can work depending on your environment. But it still can be the case that you end up needing to take a lot of airtime. This can also be challenging if, for example, the board get to know you initially as someone with a clear plan for security, who then also is the person bringing innovation; this can be difficult for some boards to get their head around.
In any case, however this works, it’s really important for the CPTO to know the CEO has their back, otherwise there could be a risk of speaking less than is needed.
Is the CPTO role the future?
The original conversation that sparked the panel was a discussion about whether AI levels the playing field for execs taking on extra areas. Specifically with regard to CPTO roles, but also more widely for all exec roles.
None of the panellists could see a scenario where they would go back to a role where they led only product or technology, AI or not.
However, we all agreed that adaptability is the most important skill for all exec roles, especially with the current rate of change. CPTO is the role currently most needing to adapt to take advantage of AI advances, but we predicted CMO would be next, with COO (for example supply chains, logistics) and CFO not far behind.
For all roles, as well as adaptability, other crucial skills include being able to mobilise people and move fast. Judgement and a product understanding is crucial: we’ve all seen companies finish their backlog but not a lot of companies actually delivering new value using AI, and that is because understanding what to build is the real distinction.
Will there be fewer roles at the exec table?
Sparked by a question from the audience, we also discussed what the future structure of the exec team might be. We didn’t have a clear answer: there are lots of ways to structure the exec team depending on what’s important to the business, and the CEO needs to decide where to reduce friction by having one person cover multiple functions, and where to introduce it.
There are some roles where depending on scope there is potential conflict with CPTO, for example Chief Transformation Officer or Chief AI officer. The latter reminded a couple of us of the situation several years ago where many organisations had both a Chief Technology Officer and a Chief Digital Officer. That potentially creates a situation where both are working on the same area, but one with less ability to effect change.
One role that seemed likely to be created from the CPTO merge is CISO; security is even more important now and some panellists felt it was likely to warrant a separate exec role.
Thank you to a great panel
We covered a lot more areas and it was really great to have their collective wisdom in the room. Thank you to Christina Scott, Georgie Smallwood, Jo Wickremasinghe and Tiama Hanson-Drury for a brilliant discussion.
Taste, Judgment and Trust in the AI Era
Last week I had a really enjoyable conversation with Joe Bignell on his podcast, Joe’s room.
Some of the things we talked about:
- The value from AI doesn’t just come from adoption, it comes from changing how your organisation operates around it. Now that coding has got so much faster, we can see clearly that coding was never the bottleneck; competitive advantage comes from where AI is embedded in your organisation and how well you integrate it.
- The phrase I find most useful is: AI amplifies, it doesn’t augment. It can give you a huge boost where you’re already strong, but it won’t manufacture the expertise, product thinking or leadership you’re missing. Taste, judgement and critical thinking are all still required.
- The importance of not outsourcing your thinking, but how easy it can be to do so.
We also discussed some books I recommend and lots more. You can listen to the episode on Spotify.
Three AI principles every exec leader needs to understand
It’s no longer defensible for CEOs and boards to outsource understanding AI to their technology execs. I partnered with CxAI on a post about the three key principles that will enable execs to build that understanding. The post is below.
This week, we’re shifting gears.
Not to what AI can do for consumers and businesses, but to a more uncomfortable question: as an executive or board member, are you asking the right questions about AI?
Executives are approving budgets, signing vendor contracts, and sitting through AI strategy briefings. Yet in the UK, only 9% of businesses have actually adopted AI in any meaningful way (see our last post for details). And according to Deloitte, 66% of boards have little to no knowledge of the technology they are asked to fund.
There’s a gap between sponsoring AI and understanding it and that gap can be expensive.
Before strategy, before tooling, before any budget is spent, there’s one skill that separates executives who lead AI initiatives from those who just fund them: knowing what to ask.
For this post, we partnered with Anna Shipman, a Chief Technology Officer with 20+ years delivering technology strategy, including at the Financial Times, the Government Digital Service, and most recently at Kooth, an AIM-listed Digital Health company. She writes about technology and leadership in her blog so subscribe if you find this interesting.
(Skip to the end if you want to see Anna’s top questions to ask)
What AI literacy actually means at the executive level
It doesn’t mean getting a computer science degree. It doesn’t mean taking classes or tracking every product launch. The pace of AI development makes that impossible, and that’s not your job.
What it does mean is understanding the principles that govern how this technology works, well enough to govern responsibly, challenge assumptions, and ask the questions your organisation can’t afford to skip.
Anna identifies three principles she considers non-negotiable for any executive making AI decisions today:
- AI is non-deterministic: you’re managing probabilities, not certainties
- The economics have flipped: it’s no longer about what you build, but what you buy and what that costs you long-term
- Competitive advantage is in integration: how you embed AI matters far more than which AI you use
1. AI is non-deterministic
The AI systems most companies are deploying today operate on statistical representations of language rather than grounded semantics. They don’t truly understand meaning or “know” things the way humans do. They are sophisticated, powerful pattern-matching engines, trained on historical data, that generate plausible outputs based on patterns they’ve seen before. Furthermore, those outputs will differ every time, even with identical inputs, because AI is non-deterministic.
The implications of this are significant:
- They can’t distinguish between truth and convincing-sounding fiction. AI systems are prone to hallucination, confidently generating plausible-sounding but inaccurate or fabricated information. Hallucination rates vary significantly by industry and use case. It is possible to improve accuracy by employing checks and including more training data however these all come with significantly increased cost.
- Bias is coded into the system. Training data reflects historical patterns, including discriminatory ones. AI will reproduce and amplify these patterns with confidence.
- They don’t predict unprecedented situations. Models trained on historical fraud data, for example, will miss novel fraud techniques.
This is a feature of how the technology works, not a bug that will eventually be fixed. It is possible to improve accuracy with more training data, better fine-tuning and human review but these improvements come with significantly increased cost. You can’t eliminate AI errors entirely. You can only decide the level of uncertainty your business is prepared to tolerate.
Here’s the mindset shift that matters:
Traditional software is deterministic. If your input is X, your output will always be Y. Code quality, testing, and QA aim to eliminate bugs entirely. You release software when it’s “done.”
AI is probabilistic. If your input is X, your output will probably be Y, with a confidence level of Z. You release when the error rate is at a level your business can tolerate. A model that’s 95% accurate might transform your fraud detection, be catastrophic for medical diagnosis, or be perfectly acceptable for customer service FAQs, depending entirely on the cost of being wrong.
Risk tolerance is a strategic decision. Governance of that risk is essential and regulation is catching up as the EU AI Act and emerging frameworks require demonstrable oversight. Note also that Article 4 of the EU AI Act requires providers and deployers of AI systems to ensure a sufficient level of AI literacy among the people working with those systems on their behalf.
2. The economics have flipped
AI costs are now more like running a factory than buying software, continuous operational costs, not a fixed asset that depreciates.
Traditional software is typically modelled as high upfront build costs, low ongoing maintenance, with marginal costs approaching zero as you scale.
AI needs constant tending. While traditional software degrades gradually over time due to technical debt and advances in technology, the maintenance required for AI is far more active:
- Models drift. Performance erodes continuously without intervention. The world changes, but your model was trained on old data. Fraud patterns evolve. Customer preferences shift. Language changes.
- Data drifts. The data you feed the model in production starts looking different from training data.
- The underlying concept drifts. The relationship you’re modelling changes. A pandemic, for example, disrupted all retail forecasting models overnight.
AI models carry ongoing operational costs that scale with usage (compute and tokens), plus active maintenance, plus vendor dependency.
Given these costs, you might think building your own models makes sense. But foundation models have fundamentally changed the build-vs-buy debate. Prior to 2022, companies built proprietary models for competitive advantage. Now we have foundation models such as GPT-4, Claude Opus and Gemini, large-scale AI models trained on massive datasets that provide general-purpose capabilities out of the box. Training a frontier model now typically requires tens to hundreds of millions of dollars in compute, data, and specialised talent. GPT-4 alone is estimated to have cost over $100M to train; Gemini Ultra approached $200M. By contrast, adapting existing models through fine-tuning can cost from a few hundred to a few thousand dollars for many use cases, often reducing costs by 60–90%.
However, this creates a different problem, namely ongoing operational costs and strategic dependency on model vendors who control pricing. Once you’ve built critical operations around their models, switching becomes prohibitively expensive and vendors know it. The pricing you see today reflects the land-grab phase. This creates a different class of risk with ongoing operational cost exposure and structural dependency on model vendors. CloudZero’s 2025 State of AI Costs report highlights how organisations are rapidly increasing AI spend yet only around half can confidently measure ROI. Once core workflows are built around external models, switching costs kick in and businesses are exposed to cost volatility, opaque pricing models, and expanding usage-based spend. With spend in some cases rivalling traditional Engineering organisation expenditure, effective governance of AI operating costs is essential.
3. Competitive advantage is in integration
GPT-4, Claude, and Gemini are available to everyone. Most AI capabilities are “commoditising” rapidly, improving for all players at roughly the same pace. The technology itself isn’t your moat.
Yet for many organisations, the response looks something like this:
Competitive advantage will come from where AI is embedded in your organisation and how well you integrate it.
Data matters, but is unlikely to be your moat on its own. As we covered in a previous post on data strategy, clean, structured, accessible data is a prerequisite for AI to work at all. How intentionally you design your data integration will be a significant driver of competitive advantage. A compelling example is Walmart, who have invested in building a semantic layer over their own proprietary data creating a more defensible moat rather than simply plugging into ChatGPT.
Advantage sits at the application and organisational layer. Which workflows you redesign, which decisions you automate, how you integrate AI into day-to-day operations, how quickly you learn and iterate. This is where the real gains are made. The biggest wins often come from changing your operating model entirely.
Human-in-the-loop beats full automation for most use cases. AI can make individuals 30–50% more productive on certain tasks, but human-AI collaboration consistently outperforms either on their own. Humans can catch AI errors, while AI can scale human expertise combining forces to produce better results in what is termed diagnostic complementarity in this study. It’s worth noting that a decade on from Geoff Hinton’s infamous prediction that AI would eliminate radiologists entirely, there are more radiologists than ever.
We’ve heard from many CTOs that even where the speed of coding has been significantly accelerated, overall productivity hasn’t necessarily followed because coding was never the bottleneck. The organisations that will win are those who understand where their own velocity is actually constrained, and can align speed, governance, and learning accordingly.
Without intentional integration, AI will simply amplify the organisation you already have. It will not fix structural dysfunction.
Understanding AI is no longer optional
In the past, CEOs and board members could delegate understanding of these issues to their technology executives. This is no longer an option.
Fortunately, it’s now easier than ever to build this basic understanding with literacy by using AI itself to help you learn.
Start with these questions, that Anna has set out below, get real answers and you’ll govern AI investments with the same rigour you apply to everything else.
The questions to ask by principle
1. AI is non-deterministic: you’re managing probabilities, not certainties
Proposed investments What’s the acceptable error rate, and can this system deliver it? What’s our fallback when the AI is wrong? What does accuracy improvement cost – is the business case still viable?
Accuracy claims How is accuracy being measured, and does it align with business impact? (Overall accuracy can hide catastrophic failures in edge cases)
Deployment & operations What’s our process for monitoring accuracy over time? How often will we retrain the model, and who owns that? Do we have human review in place for high-stakes decisions?
Bias & fairness What’s in the training data – does it encode historical discrimination? If this system disadvantages a protected group, can we show we took steps to prevent that?
Accountability Who owns this system end-to-end — not just deployment, but when it fails? If regulators ask us to explain an AI decision, can we? What’s the incident response plan if this fails publicly?
Vendor relationships What visibility do we have into how third-party AI works and what biases it contains? What’s our recourse if their model produces discriminatory outputs under our brand?
2. AI costs are variable and unpredictable – your financial models need to adapt
Vendor dependency What happens if our AI vendor increases pricing 3x? Have we modelled that scenario? Are we locked into this vendor, or do we have realistic alternatives?
Model drift What’s our process for monitoring when model performance degrades? How often will we need to retrain or update models, and have we budgeted for that?
Strategic reality What happens to unit economics if usage grows 50x? In 2–3 years, could AI operational costs rival engineering headcount costs?
Workforce choices Have we made a deliberate choice — growth ambition or cost optimisation? Does the people strategy align with our business objectives?
Team capability What skills do we need more of, and what skills become less critical? Are we investing in training existing teams, or assuming AI replaces expertise?
3. AI doesn’t create competitive advantage, your data and execution speed do
Competitive positioning Given competitors have the same foundation models, where specifically does this create advantage for us?
Data as differentiator Is our data genuinely unique at scale, or table stakes everyone in our industry has? Have we invested in data infrastructure to actually use this data?
Organisational velocity Where is our organisation genuinely constrained by legacy systems vs. slowed by bureaucracy? What would it take to create a team that moves at startup speed while maintaining core systems?
Execution vs. technology How does our speed of iteration compare to competitors? Can we ship, learn, and improve faster?
This post originally appeared on CxAI.
Engineering Productivity in 2026: Where AI Actually Pays Off
Earlier this week I was on a panel with some excellent peers discussing AI and engineering productivity. We discussed how to measure engineering productivity; tactics for driving adoption; how this might change how we structure our teams and the impact on junior engineers, among other topics. Here are my notes.
Photo (c) Matthew James
Some of the most interesting themes that we discussed were:
- AI amplifies, it doesn’t augment. Where there is strength it can really boost this, but where there is weakness it also amplifies this.
- This means strong software engineering skills, especially around technical architecture, are more important than ever. Agents are good at executing tasks but they do not have judgement about system design, and will follow the path of least resistance, so in a poorly structured codebase this will make things messier, at pace.
- One skill that will be ever more important is systems thinking. One audience member shared that he’d recently been to a talk about where the next generation of systems thinkers might come from and the answer proposed was gamers, where systems thinking is crucial to success.
- We’ve seen some brilliant productivity gains; for example, one of our panellists had challenged his team to find features that previously would have taken two weeks and deliver it in a day and they found a few. That doesn’t mean productivity has overall sped up 10x but shows where big step changes can be made.
- We also talked about this in light of other changes in our industry over the years and noted similarities, for example previous moves that have aimed to remove software engineers from the equation, like COBOL and CASE tools. In each case, the need for software engineering thinking and skills grew, even as the day-to-day work changed.
- This relates very much to our thoughts around juniors and even mid-level engineers. Software engineering as an industry has always had a lot of change, which is one of the things that makes it so interesting. People who are open to change and learning new skills will be able to develop, so encouraging that attitude and systems thinking is where our focus for the next generation of senior engineers needs to be.
- We talked about measuring productivity. This is far from a solved problem in engineering currently, and while many metrics have merit – we talked about DORA and Core 4 among others – there isn’t agreement. We did agree that lines of code has never been a good measure of productivity and it still isn’t now. I shared my view that measures of productivity will move further up the stack and be much more related to outcomes and what is actually delivered. We even floated the possibility that it could become closer to ARR.
- Interesting ideas were shared around how this might impact teams, including making them much smaller, maybe 2 engineers per team, and doing more with the same number of people. We also talked about how this can help with onboarding so potentially making it easier to flex the size of teams. One huge benefit of this work has been a renewed appreciation for documentation, as the AI agents need it. Finally!
Thank you to my fellow panellists Claire, Mike and Sandro, and Alan for facilitating the event. It was an extremely interesting discussion and I’m sure it’s not the last one we’ll be having on this topic!