First 90 Days as a CPTO: What Actually Needs to Happen

The standard onboarding advice for senior executives sounds reasonable until you’re actually in the seat. Listen. Build trust. Don’t make big moves. Understand the culture before you act. Fine. But the CPTO role has a specific pressure that makes patient observation genuinely costly, and most people figure that out after they’ve already spent their goodwill in the wrong rooms.

Here’s what I mean. When you arrive as a standalone CTO or CPO, you own one side of a known tension. Your counterpart exists, has a perspective, and will push back. The system is, in some broken way, in equilibrium. When you arrive as the CPTO — with both product and engineering reporting to you — you step into a role where the previous equilibrium is already gone, or never existed, or was the reason they created your job. The org is watching to see if you’ll reproduce the old dysfunction or invent something better.

Passive listening for 90 days, in that context, reads as uncertainty.

What the first 30 days are actually for

Not relationships. Diagnosis. There’s a difference. Relationship-building implies a social calendar — coffees, intros, telling people you’re excited to be here. Diagnosis means sitting in sprint reviews, reading the last six months of incident reports, pulling the roadmap and asking when every item on it was last reprioritized and by whom.

The question I kept asking in my first month wasn’t “how do things work here?” It was “where does accountability go to die?” In every organization I’ve joined, there’s a specific handoff — between product and engineering, between strategy and execution, between customer feedback and backlog — where ownership becomes genuinely unclear. That’s the seam the org is built around. Find it fast, because everything else is downstream of it.

Incident reports are underrated as an onboarding tool. They tell you what the system actually values, not what the slide decks say it values. An incident report that documents a three-hour outage with “no action items assigned” tells you about accountability culture. A post-mortem that names a systemic architectural problem, flags it as a known risk, and then shows up in a later incident report with the same root cause — that tells you about prioritization culture and the power dynamics around technical debt.

The 30-to-60 day trap

Around day 40, you’ll feel the pull to start fixing things. Resist the temptation to fix the visible thing — the team that seems demoralized, the roadmap that’s obviously overcommitted, the process that everyone complains about in the hallway. The visible problem is almost never the real problem. It’s a symptom that’s been socially acceptable to name because naming it doesn’t threaten anyone.

What you should be doing between day 30 and 60 is building the shared frame. That means enough structured conversations — with your direct reports, your peers, and frankly the skeptics — that you understand whose version of reality will collide with yours when you start moving. The person who seems most aligned in one-on-ones is often the first person to sandbag a decision when it goes to a broader audience. You need to know where that pressure comes from before you’re standing in front of it.

Day 60 onward: signal your actual model

By day 60, the organization has already formed a view of you, whether you’ve done anything deliberate or not. What they’re watching for is: does this person understand both sides, or are they really a product person who can manage engineers, or an engineer who learned to fake product instincts? That question will define whether your combined org actually integrates or quietly preserves the old silo while giving it a new reporting line.

The clearest signal you can send isn’t a reorganization or a strategy deck. It’s how you run a single difficult conversation that crosses the product-engineering seam. A prioritization debate where a technically important refactor competes with a customer-facing feature. A staffing decision where the strongest available engineer would be far more valuable on infrastructure than on the visible product work. How you navigate that — whether you can hold both lenses simultaneously and explain the tradeoff honestly — tells people more about your model than anything you’ll say in an all-hands.

By day 90, you should have made at least one decision that disappointed someone on each side. Not to prove balance, but because the integrated view genuinely produces different outcomes than optimizing for either side alone. If everyone is happy with you at 90 days, you haven’t started doing the job yet.