Blog
What actually happens when you hold both sides — the decisions, the tradeoffs, and the things nobody writes on LinkedIn.
Latest
AI Strategy
Every product review of an AI feature focuses on what the feature does. Almost none of them focus on how the feature's quality varies across the actual distribution of user inputs — which is the question that determines whether you have a product or a demo that works on the inputs you thought of in advance.
Reading paths
Start here if you're stepping into the combined mandate for the first time.
The ongoing tensions — between people, between sides of the org, between what you know and what you don't.
The calls only you can make — what to build, what to buy, what to trust.
Sep 1, 2025
Oct 1, 2025
Dec 15, 2025
Apr 15, 2026
Mar 1, 2026
Structure, process, and the invisible forces that shape how your teams actually work.
Aug 15, 2025
Jan 1, 2026
Feb 15, 2026
Oct 15, 2025
May 1, 2025
All articles
The technology strategy review is one of the most commonly mishandled board discussions in technology companies. Either it's a tour of the technical architecture that board members don't have the background to engage with, or it's a high-level strategy presentation that generates polite acknowledgment and no useful input. The goal is to make it neither.
The organizational design where a CPTO has separate heads of technology and product reporting into the role is more common than the pure combined model. Managing those two leaders — keeping them aligned without collapsing their distinct perspectives — is the specific management challenge that makes or breaks the CPTO's effectiveness.
The performance review process in a combined product-engineering organization exposes a structural problem that most leaders patch over rather than solve: engineering and product work are evaluated on different time horizons, against different kinds of evidence, using different intuitions about what good looks like. Running both populations through the same review cycle produces reviews that are fair in form and frequently unfair in substance.
Every company building with AI needs some form of internal review process. Most of the ones I've seen either move too fast and create genuine risk exposure, or move too slowly and create a governance tax that drives engineering teams to route around it. The difference between the two is almost entirely about what the review is actually for.
Reorgs reliably produce one outcome regardless of how well they're executed: they accelerate the departure of anyone good enough to have options. The people who stay through uncertainty are the ones who can't easily leave. If you're restructuring, that dynamic is the primary risk to manage — and most leaders don't manage it deliberately.
On-call culture is invisible to most product leaders. Engineers don't complain about it in sprint reviews, it doesn't show up in roadmap discussions, and the cost is denominated in engineer wellbeing rather than in anything that makes a quarterly report. But it shapes attrition, reliability, and the engineering team's relationship with the product they're building in ways that are very much the CPTO's problem.
Most boards have a mental model for a CTO and a separate mental model for a CPO. They do not have a mental model for someone who holds both. The gap between your actual role and their framework for it will create friction in every board interaction until you deliberately close it — and closing it is your job, not theirs.
Most CPTOs underuse their staff and principal engineers. Not because they don't value them — they usually do — but because the organizational structure routes the most important problems through the management chain rather than through the people best equipped to hold technical complexity and product judgment simultaneously.
The fine-tune vs. prompt engineering debate gets framed as a technical decision. It isn't, primarily. It's a product strategy decision about where your team's time should go, what kind of capability you're building, and how defensible you want the result to be. Most product leaders outsource this to engineering and get the wrong answer.
The CPTO job description problem is real. There's no canonical template for the role, which means every search ends up being idiosyncratic — and most of the mistakes in these searches come from treating it like a hybrid of a CTO search and a CPO search rather than something genuinely different.
Product and technical roadmaps exist in a permanent state of tension that most organizations manage by pretending otherwise. The two-track planning system — where product and engineering maintain separate roadmaps that 'align' in quarterly planning — is the primary mechanism by which organizations hide this conflict from themselves until it's too late.
Most executives treat the CPTO vs. CTPO debate as a semantic annoyance. It isn't. The title you hold shapes the room you're in when critical decisions get made, the expectations your peers and board bring, and the organizational signals you send when you hire, restructure, or speak publicly about strategy.
The blameless post-mortem is one of the most important ideas in engineering culture, and one of the most thoroughly cargo-culted. Most orgs run post-mortems that are technically blameless but organizationally toothless — thorough on what happened, silent on why the conditions for it existed, and allergic to anything that might make a person feel accountable.
The traditional build-vs-buy decision rested on a few durable assumptions about what vendors provide. AI has invalidated most of them. The question is no longer just whether to build — it's what layer to build at, and that decision has a shorter shelf life than any build-vs-buy decision you've made before.
The question isn't whether you can still code. It's whether your engineers believe you understand what they're living inside of. Those are different questions, and confusing them leads to leaders who either overclaim technical depth they don't have or chronically underestimate their own authority.
Every AI vendor demo is a masterpiece of optimized conditions. The data is clean, the latency is hidden, the failure modes are never mentioned. Evaluating AI vendors requires a completely different methodology than evaluating traditional software — because the surface area of what can go wrong is orders of magnitude larger.
The matrix org is supposed to solve the handoff problem between product and engineering. It usually makes it worse. The reason isn't structural — it's that most matrix orgs never actually answer the question of who owns outcomes.
Everyone tells new CPTOs to listen first, build relationships, avoid big moves. That advice is half right and half dangerous. The first 90 days have a specific shape — and most people don't see it until they've already made the mistake.
The real stability problem isn't velocity. It's that degraded-but-not-down becomes the baseline, unmeasured and unteachable, until one day the system that was supposed to ship the thing can't.
Remote-first engineering didn't fail because people stopped working hard. It failed because the informal accountability surfaces went away and nothing replaced them. The companies struggling aren't remote. They're just less visible.
The right question isn't 'should we have a platform?' It's 'what problem keeps getting solved separately that shouldn't be?' Most platform initiatives fail because they answer the first question without ever asking the second.
The most dangerous assumption in technology organizations is that great engineers create value by writing more code. The best engineers multiply everyone else's effectiveness.
The failure mode of the combined role isn't incompetence. It's the executive who treats it like two jobs stapled together — and never quite arrives in either room.
Agile didn't fail — it got captured. The standup exists so the PM can report upward. The retro exists so nobody escalates. The real dysfunction isn't imitation agile. It's agile as organizational immune response.
Most AI product failures aren't technical. They're premature certainty — teams that decided what the AI would do before they understood what the problem actually was. The AI product advantage isn't a flywheel. It's a filter.
Technical debt isn't a side effect of building software – it's a strategic instrument that, when wielded properly, accelerates rather than impedes progress.
Engineering teams are trying to figure out if you're really technical enough to trust. Product teams are trying to figure out if you're really product enough to advocate for them. The executives who navigate this best aren't the ones who prove themselves in both — they're the ones who stop needing to.
Monthly signal from leaders navigating the product-engineering merge — real decisions, real tradeoffs, no thought leadership filler.
No spam. Unsubscribe anytime.