The phrase “AI-native trust paradox” is doing a lot of rhetorical work this month, and much of it is misleading. Output is up. Trust is down. The headline numbers are easy to dramatize, and the conclusion offered up across LinkedIn and Slack communities is usually some version of “the industry needs more time. Let’s see where things are in a few months.” I have coached enough CTOs through the version unfolding right now to recognize what is actually going on. The AI-native trust paradox is not a paradox. It is a lag between a production process that changed twelve months ago and an operating model that has not changed at all or very little.

Why the AI-Native Trust Paradox Is the Wrong Frame

Most of what I read about the AI-native trust paradox starts in the same place. A statistic about velocity. A statistic about declining trust. A hand-wringing conclusion that the industry is figuring it out. That reading is too kind to the leaders running the orgs, because it implies the gap is mysterious. The gap is not mysterious. The reality is the team’s job changed, yet the structure around the job did not. The more useful question is not why the gap exists but who is responsible for closing it.

What engineering leaders have not absorbed is the harder, second-order question: what work does the organization now exist to do at all? If a team is no longer primarily authoring code, then “engineering” has quietly become a different job. The AI-native trust paradox is what surfaces when leaders run the new job using the operating manual for the old one. Frame it that way and the answer stops looking like a research problem and starts looking like a familiar operator problem, the kind any seasoned CTO has run a version of before.

None of this means tooling quality is irrelevant. Better models absolutely reduce review burden and improve local correctness. But even perfect local correctness would not solve the organizational problem underneath this shift. An engineering organization still has to define accountability, evaluation criteria, architectural stewardship, and system-level judgment. Those are management design problems, not inference problems.

Four Reframes Underneath the AI-Native Trust Paradox

If I had ten minutes with a CTO who wanted to get unstuck, I would start with four reframes. Each is a sentence. Each carries a large structural consequence underneath, and each is the kind of thing senior engineers know is true but have not heard a leader name out loud yet.

What I’d Do First In The CTO Chair

I get some version of “where do I start” almost every week from CTOs trying to get out from under the AI-native trust paradox. The honest answer is not glamorous and does not involve picking a tool. Three moves, in order.

What this looks like in practice: a CTO I work with leads a 150+ person engineering org at a late-stage infrastructure company. When we rewrote the senior and staff engineer JDs together, the hardest conversation had nothing to do with AI tooling. It surfaced a recently promoted engineer whose output was almost entirely code volume: pull requests with no written rationale, no explanation of tradeoffs, nothing a teammate could use to understand or push back on a decision six months later. Under the old definition he was a strong performer. Under the new one he was operating invisibly. The rewrite forced a calibration conversation the leadership team had been quietly avoiding, and within a few weeks the broader team had noticed the change in how reviews were being run.

What the Data on the AI-Native Trust Paradox Actually Says

I am suspicious of articles that bury the evidence, so here is the data worth holding in mind while running the three moves above. I am putting it late on purpose: if I led with it, this piece would read as a summary of someone else’s research instead of the operator argument I came to make.

19 of 219 is not a tooling story. It is a leadership story about which documents got rewritten and which did not. Model quality will improve. But organizations waiting for model improvement alone to resolve the trust gap are waiting for a tooling fix to solve a management-design problem. The resolution comes from the redesign that follows the production change, which is the same work that has closed every prior productivity-shift gap in engineering.

A Final Thought

The AI-native trust paradox will not be resolved by a vendor demo, an offsite, or a smarter review agent. It will be resolved by CTOs running the org-design playbook they already know, applied to a job that changed under them while they were focused on the tooling. The mechanics are not new. The harder part is the honesty required to admit the work changed, and to say so out loud before the documents catch up.

Two earlier pieces sit directly next to this one. The continuous product roadmap article covers the cadence side of the same operator problem. The AI-native team topology piece covers the structural side. Read together, they describe the same shift from three angles, and the AI-native trust paradox is what shows up when none of them are being attended to.

Leigh Newsome

Partner, Hoola Hoop · CTO Coach

Leigh Newsome is a Partner at Hoola Hoop and a CTO & CPO coach with 25 years of experience scaling product and engineering teams. He has worked with a wide range of startups and global enterprises, including Avid, Digidesign, WPP, and Kantar/Millward Brown, and successfully led TargetSpot (backed by Union Square Ventures, Bain Capital Ventures, and CBS) through its acquisition to Radionomy Group (Vivendi). When he’s not coaching CTOs, you’ll find him teaching digital audio to graduate students at NYU, building audio and signal processing applications, or flying fixed-wing aircraft, but never all three at once.

For CTOs and CPOs, managing up to the CEO is often the leadership skill they were least prepared for. The problem rarely looks like a problem at first. You’re delivering. Your team is shipping. The CEO seems satisfied. And then, often suddenly, something shifts. You find yourself out of sync. Decisions begin to happen without your input, with your CEO working around or beneath your role to move things forward. Your strategic proposals don’t land the way you expected. The CEO seems to be operating from assumptions about your team that aren’t accurate, and you’re not sure how that happened.

What I’ve observed, across a lot of these relationships, is that the breakdown rarely starts with a single incident. It accumulates through a pattern of missed expectations, ones the CTO or CPO didn’t even know existed.

Why Managing Up to the CEO Is Hard for CTOs and CPOs

The CTO and CPO roles sit in a uniquely difficult position when it comes to managing up. Unlike a CFO or CMO, whose domains are reasonably legible to most CEOs, your world, whether that’s engineering architecture, technical debt, or product strategy, is opaque in ways that matter. The CEO can’t easily assess whether your team is performing well, whether the risks you’re describing are serious, or whether the timeline you’ve committed to is realistic.

That opacity creates a relationship that depends almost entirely on trust. And trust, in this context, relies on a very specific kind of communication: the ability to translate what’s happening in your world into language that connects to what the CEO cares about most.

Most CTOs and CPOs are never taught how to do that translation well. So they default to what they know: status updates, technical briefings, roadmap reviews. These feel thorough, but they often miss the point entirely.

Five Patterns That Erode the Relationship

These are the patterns I see most consistently when CTOs and CPOs struggle with managing up to their CEO:

The Common Thread

None of these patterns stem from incompetence or bad intent. They develop because most CTOs and CPOs are never given a map for managing up. The encouraging thing is that all five are addressable, not through dramatic behaviour change, but through more deliberate communication habits applied consistently.

What Strong Managing Up Looks Like for CTOs and CPOs

The CTOs and CPOs who excel at managing up to their CEO aren’t necessarily the ones doing the best technical work. They’re the ones who’ve developed a specific set of communication habits that make their work legible, their risks visible, and their judgment trustworthy.

The Underlying Principle

Across all five habits, there’s a consistent thread. The CTO or CPO who manages up well isn’t trying to impress their CEO. They’re trying to make the CEO’s job easier. That shift in intent changes almost everything about how you communicate upward.

A Note on Timelines and Commitments

The timeline question deserves its own attention because it’s where managing up most often breaks down for CTOs and CPOs. “When will it be done?” is one of the most loaded questions a CEO can ask, and almost nobody answers it well.

The wrong answer is false precision: a specific date given under pressure that becomes an anchor in the CEO’s mind, surfaces in board conversations, and lingers long after you’ve forgotten you ever said it. Evasion is no better: “it depends,” “we’re still scoping it,” or an answer so hedged it communicates nothing.

The right answer is confident uncertainty. Something like: “Based on what we know today, we’re targeting the end of Q2. The biggest risk to that is X, and here’s how we’re managing it. I’ll give you an updated view in three weeks when we know more.” This gives the CEO what they actually need: a planning horizon, the key risk, and a date when they’ll have better information. It also models the kind of thinking that builds credibility over time.

The same principle applies to scope. When a CEO asks “can we add this feature?” the answer almost always involves a trade-off. The CTO or CPO who says “yes, and here’s what moves” is far more useful than the one who says “it’s complicated” or, worse, says yes and quietly absorbs the cost into the team.

Questions to Sit With

If you’re a CTO or CPO thinking honestly about managing up to your CEO, these are worth working through:

• If your CEO had to describe to the board what your team accomplished last quarter, what would they say? Is that what you would say? If there’s a gap, that’s a communication gap, not a performance gap.
• When did you last raise a meaningful risk to your CEO before you had a plan to address it? If you struggle to find an example, consider what that pattern is costing you in terms of trust.
• Do you have a consistent, self-initiated cadence for the CEO relationship, or does most of your upward communication happen reactively, when something is needed or something has gone wrong?
• Does your CEO understand the key constraints your team is operating under, such as the architectural decisions, the accumulated technical debt, and the hiring gaps, or would those feel like surprises if they came up in a board conversation?
• What does your CEO actually care most about right now? Not what they say in 1:1s, but the things driving their decisions. How explicitly does your work connect to those things in the way you communicate it?

A Final Thought

Managing up well doesn’t mean being political. It doesn’t mean softening hard truths or packaging bad news attractively. It means developing the discipline to communicate your world in terms that are useful to the person you’re communicating with. And it takes real courage to do it consistently: to raise the uncomfortable thing early, to push back on the unrealistic expectation, to say “I don’t know yet” to someone you want to inspire confidence in. If that’s a dimension you want to explore further, our Courage to Lead series goes deep on exactly that.

Your CEO is making decisions about the whole business, often with incomplete information and real time pressure. The more you can make your piece of the business legible to them, the better those decisions get. That’s good for them, good for your team, and ultimately good for you.

The CTOs and CPOs who build strong upward relationships aren’t the ones who have the smoothest delivery or the most polished presentations. They’re the ones who understand that their job doesn’t stop at the boundary of their own organization, and who invest in the relationship with the same seriousness they bring to everything else.

Leigh Newsome

Partner, Hoola Hoop · CTO & CPO Coach

Leigh Newsome is a Partner at Hoola Hoop and a CTO & CPO coach with 25 years of experience scaling product and engineering teams. He has worked with a wide range of startups and global enterprises, including Avid, Digidesign, WPP, and Kantar/Millward Brown, and successfully led TargetSpot (backed by Union Square Ventures, Bain Capital Ventures, and CBS) through its acquisition to Radionomy Group (Vivendi). When he’s not coaching CTOs, you’ll find him teaching digital audio to graduate students at NYU, building audio and signal processing applications, or flying fixed-wing aircraft, but never all three at once.

That’s exactly why I do what I do. And it’s what CTO coaching is for.

What is CTO Coaching?

CTO coaching is a structured working relationship between a technology executive and an experienced coach, designed to help the CTO grow as a leader, make better decisions, and perform more effectively in their role.

It’s very different from consulting. A consultant gives you answers. As a CTO coach, I help you to develop the skills, self-awareness, and judgment to find better answers yourself.

My approach is grounded in 25 years of hands-on experience as a technology and product executive — having served in CTO, CPTO, and CEO roles across a range of growth-stage companies. What I value most about the team I work with at Hoola Hoop is that every partner and coach brings that same perspective. We’re all former operators who have navigated exactly the challenges our clients face. Not theorists. Practitioners. The guidance is concrete because the experience is real.

Who Needs CTO Coaching?

In my experience, CTO coaching is highly valuable at multiple career stages, but it tends to be incredibly impactful in a few specific situations.

Areas CTO Coaching Addresses

Effective CTO coaching covers both the technical leadership dimension and the human side of the role. In my work with technology leaders, these are some areas that come up consistently:

What Makes A Good CTO Coach?

Not all coaches are created equal. Here’s what I’d tell any leader looking for a CTO coach:

• Real operating experience in technology leadership First and most importantly, look for a coach with real operating experience in technology leadership. A coach who has never scaled an engineering team, managed technical debt under growth pressure, or navigated a difficult CTO-CEO dynamic will struggle to give you relevant, credible guidance. I’ve spent decades doing exactly that, and it’s the foundation of every coaching relationship I have.
• Someone who asks great questions, not just dispenses advice Second, look for someone who asks good questions rather than just dispensing advice. The best coaching unlocks your own thinking. A coach who just tells you what to do creates dependency, you want someone who builds your capacity to think through hard problems independently.
• Honest and willing to challenge you Third, look for a CTO coach who will be honest with you and challenge you. As a CTO, you often don’t get candid feedback from your teams or peers. A good CTO coach will tell you what you need to hear, not just what you want to hear.

What to Expect from CTO Coaching

My coaching engagements typically involve regular one-on-one sessions usually weekly or bi-weekly, focused on whatever is most pressing for you at that moment and on the goals we have set together. Sessions are confidential, which creates the space for the kind of honest conversation that’s hard to have with a direct report, peer, or investor.

I often start with an interview-based 360 review speaking directly with your peers, direct reports, and CEO. This helps get an honest, multi-perspective picture of where you are excelling and where the real development opportunities lie. Then we define 3 to 5 goals to work on. This gives our CTO coaching sessions a grounded starting point rather than relying solely on self-assessment.

From there, coaching sessions evolve to address real-time issues as they arise such as team performance challenges, a board presentation, technology decisions, a team restructure, or a conflict with the CPO or CEO. I also facilitate CTO leadership roundtables, bringing together technology leaders from across our client base and portfolio to share experiences, challenge each other’s thinking, and learn from peers who are navigating similar inflection points. Many CTOs find these peer sessions as valuable as the one-on-one coaching itself.

Leigh Newsome

Partner, Hoola Hoop · CTO Coach

Leigh Newsome is a Partner at Hoola Hoop and a CTO coach with 25 years of experience scaling product and engineering teams. He has worked with a wide range of startups and global enterprises, including Avid, Digidesign, WPP, and Kantar/Millward Brown, and successfully led TargetSpot through its acquisition to Radionomy Group (Vivendi). When he’s not coaching CTOs, you’ll find him teaching digital audio to graduate students at NYU, building audio and signal processing applications, or flying fixed-wing aircraft — but never all three at once.