How should you think about CTO CPO CPTO roles and their convergence at your company? It is a question growth-stage companies have wrestled with for as long as these roles have existed. We saw this convergence happen with the SaaS boom over the past 15 years. But with AI, the CTO CPO CPTO role convergence question is playing out again in exec team meetings, board meetings, and across many sectors. It tends to generate strong opinions quickly, and those opinions are often shaped more by what worked at someone’s previous company than by what the current situation actually requires. What follows maps the real trade-offs, so the call you make is grounded in your context, not someone else’s.

At Hoola Hoop, we have watched this debate play out across our portfolio companies for the better part of a decade. For us, this is not a question AI invented. At our quarterly CTO and CPO leadership roundtables, we have had CPTOs speak directly to what the role demands, what the unique challenges are, and where it can break down. The patterns in what they describe, across different companies, team sizes, and sectors, are consistent enough to say that something meaningful is happening to these roles, not just to the individuals in them.

AI has changed the terms of the conversation, and speed is only part of it. The shift is more fundamental: the boundary between “what to build” and “how to build it” is dissolving. Product leaders are building functional prototypes using tools like Cursor and Claude Code and submitting pull requests directly to engineering repositories. Engineers are shaping UX decisions and product direction from day one, not after requirements land in a backlog. AI is not just making individuals faster, it is eliminating the handoff between roles, turning sequential process into continuous, shared problem-solving. We have written in more depth about how AI is reshaping the CTO and CPO role and what it means for how teams are structured. For the CTO CPO CPTO question, the implication is significant. The issue is not about optimizing the handoff between product and engineering, it is about whether the traditional separation still maps to how your work actually gets done.

How the CTO and CPO Roles Were Designed

The traditional separation between CTO and CPO made sense for a specific era of technology development. The CTO owned the technical foundation: the how, core architecture, infrastructure, engineering velocity, security, and the team capable of building and maintaining all of it. The CPO owned the user-facing strategy: the why, roadmap, prioritization, market fit, and the voice of the customer inside the organization.

Each role had a clean mandate. The CPO determined what mattered to users and, as a result, what the company should build. The CTO figured out how to build it. For a long time, those mandates were distinct enough to justify two separate leaders. Build cycles were long. The distance between an engineering decision and a customer outcome was wide enough that two people could stand on either side of it without stepping on each other’s toes.

That distance has collapsed. Product-led growth, platform business models, and full-stack engineering have been closing the gap for the better part of a decade. When the product itself becomes the primary acquisition and retention mechanism, every technical decision becomes a product decision. When engineers own the full-stack delivery, the leaders above them need to hold both lenses simultaneously. By the time most companies reach Series B or C, the CTO who cannot think in product outcomes and the CPO who cannot interrogate technical trade-offs are both becoming a liability.

How AI Is Accelerating the CTO CPO CPTO Role Convergence

AI has not created the underlying tension between product and technical leadership, it has removed the slack that allowed organizations to manage that tension through process. Three shifts stand out.

The collapse of the build cycle. Features that once required quarters to scope, design, build, and ship can now be prototyped in days and deployed in weeks or less. That compression means the hand-off between product thinking and technical execution can no longer afford to be a formal process with its own calendar, gate reviews, and dedicated meeting cadences. The thinking has to happen simultaneously, between leaders who are in genuine dialogue about both domains at once.

The disappearance of clean ownership. When a company deploys a large language model as a core product feature, who owns it? The CPO, because it faces the user? The CTO, because it sits on the technical stack? Neither answer is sufficient. Someone needs to own the intersection, and that person needs to understand model behavior, inference costs, data quality, user expectations, safety considerations, and product positioning all at once.

Emergent product capability from the technical layer. AI is now generating product capability that neither the CTO nor the CPO put on the roadmap. These capabilities are not coming from a user story or a product brief. They surface from the technical layer and land in the product layer. A leader who can only see one side of that process is going to miss the opportunity, or deploy it without fully understanding the implications for users.

Five Signs Your CTO CPO Structure Has a Problem

The CTO CPO CPTO role convergence debate often stays abstract until someone recognizes their own organization in it. These five patterns tend to appear before the structural role issue becomes a crisis:

The Common Thread

Each of these patterns is a symptom of the same underlying condition: the open wound between product and technical leadership is visible, and the organization is building scar tissue around it rather than closing it. The CTO CPO CPTO role convergence question gets harder to avoid the more of these patterns are present simultaneously. The cost of leaving that wound open is painful and increases with every product cycle.

What the CPTO Structure Does Well

When it works, a single CPTO removes the most common failure mode at growth-stage companies: the structural gap between what is technically possible and what actually gets built. That gap is rarely caused by bad people. It is usually caused by two leaders with different mental models, different incentive structures, and different stakeholder relationships. Those structural conditions produce friction by design. In a CPTO model, the tensions between technical rigor and product velocity live inside one person. They get resolved faster.

The CPTO structure works best when the company’s product and technical strategy are genuinely inseparable. For an AI-native company, a developer tools company, or a company building on a fast-moving technical platform, separating product and technical leadership can create exactly the kind of schism that slows the decisions that matter most. In these contexts, the CPTO is not a compromise. It is the natural shape of the role. Leading voices in the field argue that in the AI era, the CPTO becomes one of the most critical executive roles a company can define well.

The companies that benefit most from a CPTO role tend to share a common characteristic: their competitive advantage lives at the intersection of technical and product capability, not on either side. When that is true, having two leaders who must negotiate across that intersection adds latency that a single leader eliminates.

What the CPTO Structure Gets Wrong

The counter-argument deserves equal attention. The CTO and CPO are each a genuine full-time job that requires different areas of expertise. Asking one person to hold both is often asking them to half-execute two strategies rather than fully commit to one. At scale, the gaps become critical. Security incidents, architectural decisions, and platform reliability require sustained CTO attention that a leader splitting their focus cannot always provide. Roadmap clarity, user research integration, and commercial alignment require sustained CPO attention that the same leader, pulled toward technical firefighting, will deprioritize.

There is also a governance risk that organizations consistently underestimate. When the CTO and CPO are two people, they provide the organization, and each other, with a structural counterweight and checks-and-balances. The CTO’s pragmatism checks the CPO’s ambition. The CPO’s user focus checks the CTO’s tendency to over-engineer. Removing that check requires the CPTO to internalize both perspectives and actively argue against their own instincts. This is possible, but it requires the right context and a specific kind of discipline that most leaders develop only after making costly mistakes on both sides.

The right CPTO is also genuinely rare. The number of leaders with real depth in both technical architecture and product strategy, combined with the operational experience to run both domains simultaneously, is very small. Promoting someone who is 80% CTO into a CPTO role does not create a CPTO. It can create a “CPO” gap that no one owns. Companies that have tried to merge the roles and found their CPTO struggling are not failing because the concept is wrong, the failure of the role is most likely due to not having the right person for the full scope of the job.

There is a deeper leadership dimension worth naming here. Marc Maltz at Hoola Hoop writes about the authority-control paradox at the heart of senior leadership: as formal authority increases, actual control over outcomes often decreases. A CPTO sits in what Marc calls the Crisis Zone, where formal authority over product and technology is at its peak, but outcomes depend on two large teams, competing organizational dynamics, and market forces simultaneously. That gap does not close because the title does. It tends to widen. Add to this what Marc describes as inherited baggage: step into a combined role and you inherit not just a broader job description, but the historical friction between product and engineering, the cultural patterns each team built under the previous structure, and what psychoanalyst Christopher Bollas calls the “unthought known,” the unconscious patterns that everyone acts on but no one names. Courageous role-taking, in Marc’s framing, means entering a role with realistic expectations rather than the idealized version you were sold. That discipline is especially important for a CPTO, where the gap between the job description and the lived reality tends to be widest.

What Great Leaders Do Regardless of Title

The executives navigating the CTO CPO CPTO role convergence question best, regardless of their title, share a specific capability: they have invested in genuine fluency in the domain that is not their home ground. This is not about becoming a generalist. It is about building enough literacy in the adjacent domain that the conversation between product and technology happens at the right level of specificity.

The Underlying Principle

The leaders who develop genuine cross-domain fluency, regardless of whether they hold one title or two, consistently make better calls at the intersection of product and technology. This matters with or without AI in the picture. Building that literacy is not a response to a trend. It is a core leadership discipline for anyone running a technology organization.

Questions to Sit With

If you are working through the CTO CPO CPTO role convergence question right now, these organizational questions are worth sitting with before you make a call. For anyone actually considering stepping into the CPTO role, Marc’s four questions for courageous role-taking are an equally valuable companion: do you have the tolerance and temperament for this risk zone, what inherited baggage will you encounter, and can you negotiate for the authority and boundaries you will actually need? Both sets of questions matter.

• When your CTO and CPO last disagreed on a significant, strategic decision, was it a productive tension or evidence of a structural gap?
• Is your roadmap genuinely shaped by both technical possibility and customer need, or does one side consistently dominate?
• If you had to hand a combined CPTO brief to one person on your current leadership team, who would it be? What does that answer tell you about where your biggest gap actually is?
• How is AI adoption showing up right now in the space between your technical strategy and your product strategy? Who owns that space?
• Are you designing your CTO and CPO roles for the jobs as they existed three years ago, or for what those roles require today and tomorrow?

A Final Thought

The CTO CPO CPTO role convergence debate will not be settled by an org chart. It gets resolved by the quality of the relationship between the leaders holding those roles, and by the individual investment each of them makes in understanding the domain that is not their primary one. AI has made that investment more urgent. The pace of change in the technical layer is now fast enough that a CPO who treats engineering as a black box is navigating with incomplete information. The pace of change in user expectations is fast enough that a CTO who treats product as someone else’s responsibility is building something that will need to be rebuilt.

Whether your company has two leaders, one combined leader, or is still working through the decision, the underlying work is the same: build genuine technical-product fluency at the senior leadership level. Create the conditions for fast, high-quality decisions at the intersection of both domains. And recognize that this intersection is where most of the highest-stakes choices in today’s technology company are being made.

This is exactly the kind of challenge that looks different from the inside than it does from the outside. The leaders who navigate it best are rarely the ones with the strongest view about how it should be structured. They are the ones who have built the kind of executive fluency that extends well beyond their primary domain. If you are doing that work in parallel on the relationship side of the house, the principles in Managing Up as a CTO or CPO are closely related. The same investment in understanding what the people across the table actually need from you applies in both directions, and the skills compound.

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.

Agentic AI governance has become a defining challenge for leaders in 2026. Dell Technologies recently changed its word of the year from “agentic” to “governance,” which is a small signal worth paying attention to. The industry’s most forward-thinking leaders are not debating whether AI agents are capable. They are asking whether organizations are capable of running them responsibly, at scale, without losing control of outcomes.

The numbers behind that shift are significant. Gartner predicts that over 40 percent of agentic AI projects will be canceled by end of 2027 due to escalating costs, unclear business value, or inadequate risk controls. Accelirate’s analysis of the governance crisis points to poor data foundations and ungoverned deployments as the root causes. What successful companies have in common is worth paying attention to: they built governance infrastructure before they needed it, not after.

A large part of what is making that gap worse is “agent sprawl.” Companies, especially startups, that are hungry to move fast and frustrated by slow procurement cycles, are independently spinning up AI agents outside of any centralized governance framework. Each team means well. In aggregate, what they create is a patchwork of ungoverned autonomous systems, each with its own tool access, its own cost exposure, and its own failure modes, with no CTO able to see the whole picture. Agent sprawl has moved from a technical concern to a board-level risk topic in the space of twelve months.

Agentic AI governance is not a compliance exercise. It is the leadership infrastructure that determines whether your agents remain useful tools or become autonomous sources of risk your organization cannot trace or contain.

Why This Is a Different Kind of Engineering Problem

What makes agentic AI so powerful is also what makes governing it fundamentally different. Traditional software systems do what they are programmed to do. When something goes wrong, there is a decision log, a code path, or a config change to point to. Agents operate differently. They reason, act on incomplete information, and chain decisions together in ways that are not always fully predictable from the inputs. That is what makes them capable of compressing days of engineering work into minutes. It is also what requires a different control architecture.

When an agent fails in production, it rarely presents as a crash or outage. Instead, it manifests as a confidently made but subtly incorrect decision that can be repeated across many transactions before it’s detected. By the time it surfaces, the blast radius is substantial and the causal chain is hard to untangle. Traditional audit trails weren’t built for this. Neither were escalation processes.

Take MCP, Model Context Protocol, a standard that connects AI agents to external tools and data sources: databases, repos, communication channels. Every MCP server you provision to an agent is a capability expansion and a blast radius expansion, often without the access review you would apply to a human team member requesting the same permissions. I’ve seen platform teams find that MCP server sprawl is one of the primary mechanisms through which agent sprawl actually happens. Access accumulates informally until no one can tell you what your agents are actually capable of doing. Governing which agents access which MCP servers, under what conditions, and with what audit trail, is becoming a core platform engineering necessity.

There’s also a hidden governance trap. When IT responds too strictly to these risks, AI development doesn’t cease, instead it goes underground. Teams find workarounds and ungoverned experiments run in personal cloud accounts. The organization ends up with the worst of both worlds: an official AI posture that appears controlled, and a shadow AI ecosystem that is invisible and entirely ungoverned. The CTO’s governance challenge isn’t just about preventing unsafe agents from running. It’s about designing a framework permissive enough that teams don’t bypass it entirely.

Here’s How Agentic AI Governance Breaks Down

Below are a few patterns that are starting to emerge more broadly, including themes from our Q1 2026 CTO Roundtables. These aren’t hypothetical, they’re already playing out in real-world systems.

What connects all of these is a version of the same challenge: governance infrastructure designed for systems that do exactly what they are told. Agents do not operate that way. They reason under uncertainty, take action based on incomplete context, and compound decisions in ways that could be hard to predict in advance. The organizations getting this right have accepted that difference and redesigned their controls accordingly, rather than assuming the old frameworks would carry over.

What Good Agentic AI Governance Looks Like

Governance is not a brake on AI capability. When done well, it is what makes capability sustainable. The organizations moving fastest are not the ones that skipped governance, but they are the ones that built it early enough to scale on top of it:

Good governance is not about limiting what agents can do. It is about creating the infrastructure that lets you trust what they do. Trust is not a feeling. It is a property of a system with provenance, accountability, and meaningful controls. Build those, and speed follows. Skip them, and you are not moving fast. You are accumulating a debt that arrives all at once when something goes wrong in production.

The organizations moving fastest with AI agents are not the ones that skipped governance. They are the ones that built it early enough to scale on top of it.

When an Agent Gets It Wrong: Accountability Frameworks for CTOs

One of the toughest questions in agentic AI governance is accountability: when an agent makes a mistake such as harming a customer, exposing sensitive data, or disrupting a business process… who is responsible? This isn’t a philosophical debate. It is a practical challenge that CTOs will face increasingly as agent deployment scales.

The answer needs to be decided before the mistake happens. After the fact, accountability diffuses, timelines blur, and the post-incident conversation focuses on symptoms rather than the structural question of who has ownership. Agentic AI governance requires establishing accountability frameworks prospectively, as part of the development and deployment process, rather than reactively when something breaks.

A practical way to think about this is in three layers:

1. Ownership of the agent’s design: its scope, the tools it can access, and the constraints that shape its behavior;
2. Ownership of deployment: how it’s approved, tested, and rolled back; and
3. Ownership of outcomes: ongoing monitoring, escalation paths, and decisions about expanding or tightening autonomy based on what happens in production.

Without clearly defined owners at each layer, governance defaults to shared responsibility which, in practice, means no actual ownership at all.

A Governance Audit Worth Running

These are the questions I find most revealing when I work with CTOs on this. They are worth sitting with honestly rather than answering quickly:

• If your most consequential agent made a significant error today, could you immediately reconstruct exactly what it decided, what information it acted on, and which tool calls it made? If not, you do not yet have the observability layer that governance requires.
• Who in your organization is accountable for each agent’s design, deployment, and outcomes? Are those accountability assignments written down and agreed across engineering and product, or do they exist only as assumptions that have never been tested?
• Have you applied least-privilege principles to your agents’ tool access? Does each agent have only the access it requires for its current task, or has tool access grown incrementally because restricting it felt like friction?
• Where in your agentic workflows does human review add genuine value, as opposed to the appearance of oversight? Have you designed those checkpoints deliberately, or did they emerge as a default response to governance anxiety?
• What governance metrics are you tracking alongside your engineering metrics? Do you know your agents’ decision quality, escalation rate, retry frequency, and cost per completed workflow? Or are you only looking at throughput and latency?

Governance Is Also a People Problem

One dimension of agentic AI governance that rarely shows up in formal frameworks is the human aspect. As agents assume more of the execution work, engineering roles are being redefined. Engineers who once wrote the code are now designing systems that orchestrate agents to do that work. That’s a different role and one that demands strong judgment, broader technical insight, and a clearer understanding of where risk actually concentrates.

This shift from writing code to AI orchestration does not always happen smoothly. Engineers who have built careers around hands-on implementation are being asked to think at a higher level of abstraction essentially defining guardrails, validating outputs, and designing exception paths rather than building logic from scratch. Some adapt quickly, but others find it disorienting. The governance framework a CTO builds needs to account for this transition, not assume that the team already knows how to think in these terms.

The CTOs navigating this well treat it as a team structure and culture challenge alongside a technical one. That means investing in how engineers develop judgment about agent behavior, not just skills in agent tooling. It means building review processes that help engineers develop intuition about where agents fail gracefully and where they fail badly. It also means making space for the more deliberate thinking that good governance design requires, even when shipping pressure pushes in the opposite direction.

The CTOs who get agentic AI governance right understand that governance and velocity are not in tension. Governance is what makes velocity sustainable. Provenance, accountability, and policy enforcement are not constraints on what agents can do. They are the infrastructure that allows organizations to trust what agents do well enough to give them more responsibility over time. If you are navigating this and finding that the standard playbooks don’t quite map to the complexity you’re dealing with in practice, you can explore how Hoola Hoop approaches these challenges in more depth here.

Leigh Newsome

Partner, Hoola Hoop · CTO Coach & Advisor

Leigh Newsome is a Partner at Hoola Hoop and a CTO coach and advisor 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.

The AI ROI board conversation is now one of the defining pressure points for CTOs and CPOs in 2026. According to Kyndryl’s 2025 Readiness Report, which surveyed 3,700 senior business leaders, 61% say they feel more pressure to prove AI ROI now than they did a year ago. That number does not surprise me. What surprises me is how many technology leaders are still walking into that conversation underprepared, armed with metrics that felt compelling twelve months ago and now fall flat the moment a board member asks what it means in revenue terms. To help address this, we’ve guided CTOs and CPOs across our portfolio and hosted two CTO Roundtables in March 2026, titled “CTO: Off The Record – What We’re Not Saying About AI,” providing a forum to explore the challenges and best practices for framing AI ROI.

The frustration being voiced in CTO communities right now is specific: technology leaders who made thoughtful, responsible AI investments during the 2023-2025 buildout period are now being asked to retroactively justify those decisions in financial language they were never tracking. The goalposts moved. And for many, the conversation feels unfair because the technical work was genuinely good.

But boards are not wrong to push. The AI ROI board dynamic reflects a real and legitimate shift in expectations. AI is no longer a speculative bet on future capability. It’s a significant line item in operational budgets, and boards are right to expect that spending to connect to outcomes. The question is how CTOs and CPOs build that case, credibly and on their terms, rather than having the conversation forced on them in a format they didn’t design.

Why the Old Metrics No Longer Work For AI ROI

When AI adoption was in its early stages, organizations tracked what they could measure: the percentage of engineers using Copilot, the number of AI features shipped, the volume of user interactions with AI-powered capabilities. These metrics made sense at the time. They showed momentum. They demonstrated that the organization was moving.

Boards and investors are done with momentum metrics. The AI ROI board expectation in 2026 is near-term business outcomes: revenue impact, cost reduction, and cycle time compression. CFOs, not chief AI officers, are increasingly being positioned as the accountability layer for AI returns, which means CTOs and CPOs now find themselves in conversations that require a different kind of fluency. The shift is not cosmetic. It requires a fundamentally different way of thinking about how AI investment gets measured and reported.

The Hidden Cost Problem in AI ROI

There is a specific version of the AI ROI board challenge that is hitting CTOs right now, and it deserves its own treatment. The cost side of the AI ROI equation is moving. Not incrementally, but significantly and repeatedly. Tools like Cursor, Claude Code, and GitHub Copilot have all shifted pricing models in the past twelve months, and the shift from seat-based licensing to usage-based billing has caught a large number of engineering budgets off guard.

The dynamic is this: a CTO budgets for a fixed number of AI tool seat licenses, a predictable, defensible number to put in front of a CFO. Then agentic usage scales up. An engineer running a long Claude Code session or a Cursor agent working overnight isn’t consuming a seat license. They’re running up a consumption bill. The cost structure of these tools is fundamentally different from traditional software licensing, and many organizations discovered that difference in their quarterly cloud and SaaS reconciliation rather than during budget planning.

This creates a specific AI ROI board problem. You cannot build a credible ROI case when the cost baseline keeps moving. Boards and CFOs are reasonable to question a return calculation built on a cost denominator that looked very different six months ago and may look different again in six months. The CTOs who are navigating this well are doing two things: they’re tracking AI tooling costs at the consumption level, not just the license level, and they’re building their ROI narrative with explicit assumptions about cost trajectory rather than treating current spend as a stable baseline. Acknowledging the volatility, with a clear framework for monitoring it, builds more credibility than presenting a clean number that a CFO can easily challenge.

Five AI ROI Board Patterns That Are Holding CTOs Back

Across the CTOs and CPOs I coach, I see the same patterns emerging when the AI ROI board conversation goes poorly. Recognizing yours is the starting point:

### The Common Thread

Every one of these patterns has the same root cause: AI investment was treated as a technology program when it needed to be treated as a business investment from day one. That doesn’t mean the technical work was wrong. It means the measurement and narrative infrastructure wasn’t built alongside it. The good news is that building that infrastructure now, even retroactively, is possible, and it changes the AI ROI board conversation significantly.

What Good AI ROI Board Preparation Looks Like

The CTOs I’ve seen handle the AI ROI board conversation well share a set of practices that distinguish them. None of these are complicated. All of them require doing the work before you walk into the room:

### The Underlying Principle

The AI ROI board conversation is fundamentally a trust conversation. Boards trust technology leaders who demonstrate that they understand the business implications of their investment decisions, who track what matters to the business rather than what’s easy to measure, and who can hold uncertainty honestly while still giving the board a clear enough picture to make decisions. Technical credibility gets you into the room. Business fluency keeps you there.

The CFO Partnership: Your Most Underused Asset

One pattern stands out as particularly underused among the CTOs I coach. The CFO-CTO relationship around AI has historically been adversarial: the CTO advocates for investment, the CFO scrutinizes the returns, and the conversation happens at budget time. That dynamic is shifting, and the CTOs who recognize it early are building a significant advantage in the AI ROI board conversation.

CFOs are now being positioned, internally and by their boards, as the primary accountability owners for AI returns. That’s a significant shift. It means CFOs have both the mandate and the organizational standing to be genuine allies in building the ROI narrative. A CTO who treats the CFO as a gatekeeper to be managed is missing the opportunity. A CTO who brings the CFO in as a partner in designing the measurement framework, building the ROI narrative, and presenting to the board is creating shared accountability that benefits both parties.

The practical entry point is straightforward. Before your next board preparation cycle, set up a 90-minute working session with your CFO specifically focused on the AI ROI measurement question. Agree on what the relevant business outcomes are, which metrics you can attribute directly versus indirectly, and how you want to frame the three-horizons narrative together. Do this well before the board meeting, so you’re not negotiating the framing under time pressure. The CFO who walks into a board meeting having co-built the narrative is a very different ally than the CFO who sees the slides for the first time in the briefing.

Questions to Sit With

If you’re a CTO or CPO heading into an AI ROI board conversation in the next quarter, these are the questions worth working through honestly before you walk in:

• Can you isolate your AI investment on its own cost line, clearly enough that a board member could verify the number with your CFO and get a consistent answer?
• Are your current AI metrics connected to business outcomes, such as revenue, cost reduction, or cycle time, or are they primarily adoption and usage metrics that measure input rather than impact?
• Does your CFO know your AI ROI narrative as well as you do? Could they present the financial side of it credibly without you in the room?
• Have you separated the three horizons explicitly: near-term efficiency returns, structural improvement in the next 12 months, and longer-term competitive positioning? Or are you presenting them as a single undifferentiated story?
• When a board member asks what the AI investment returned, can you answer in a way that a CFO would sign off on? If not, what would need to change in your measurement or framing to get there?

A Final Thought

The AI ROI board conversation is not going to get easier. As AI spending grows and board scrutiny increases, the expectation that technology leaders can account for their AI investments in business terms will only intensify. The CTOs who build that fluency now, before it becomes a crisis conversation, will have a significant advantage over those who continue to hope that momentum metrics will carry them through.

What I find most consistently true, coaching technology leaders through this, is that the ROI conversation is rarely the problem. The problem is the infrastructure behind it, the measurement systems, the CFO relationship, the ability to translate between technical and financial language, that was never built. Building it is not a board-meeting sprint. It’s a discipline that develops over quarters.

The same clarity that helps you navigate the AI ROI board conversation also strengthens how you manage upward across the organization. If you’re thinking about how to build stronger executive relationships alongside your financial fluency, the principles in Managing Up as a CTO or CPO are directly relevant. The skills compound. And the CTOs who develop both tend to find the board conversation stops feeling like a threat and starts feeling like an opportunity.

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 (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.

CTOs aren’t asking “should we use AI?” anymore. That debate is over. They’re asking: how do we rebuild our development process around it and how do I need to lead differently?

This article is my attempt to answer that.

What Traditional SDLC Was Built For

The Software Development Lifecycle: requirements, design, development, testing, deployment, feedback was architected around a fundamental constraint: humans are the only ones who can do the work.

That constraint shaped everything. Sequential handoffs existed because one person or team needed to finish before the next could start. Sprints existed to timebox human capacity and velocity. QA came after development because writing tests and writing code at the same time was too expensive. Code reviews were async because engineers couldn’t be in two places at once.

We built an entire system of process around human throughput limitations. And for decades, it worked.

What’s Changed

Agentic AI tools like Claude Code, Cursor, Copilot, and Devin are changing more than individual developer speed. They’re collapsing and reinventing the handoffs between stages entirely. Here’s what I’m seeing as a CTO and in the organizations we advise:

What This Means for CTOs

The process implications are real, but the leadership implications are even bigger.

What Doesn’t Change

I want to be direct about this, because I think there’s a real risk of CTOs either over-correcting or under-responding to this shift.

The human things, specifically the leadership things, DO NOT go away. They become more important.

Your job as a leader is to create the conditions where higher-level thinking can actually happen, which means protecting your best people from being buried in review queues of AI-generated code.

Knowing which problem to solve, and why now, is still yours. AI can accelerate execution with extraordinary speed. It cannot set direction. Strategic judgment, customer empathy, navigating organizational ambiguity, building a team that trusts each other. None of that is on the automation roadmap.

What is changing is the ratio. More of the execution layer is being handled by agents, which means the humans in the loop need to be operating at a higher level not just reviewing code, but shaping outcomes. The exceptional engineers on your team will thrive in this environment. Those who relied primarily on execution throughput will find the transition harder.

Questions to Sit With

If you’re a CTO thinking through what this means for your organization, these are the questions I’d encourage you to work through:

• Does your development process still have handoffs that exist because of human throughput constraints rather than because the handoff itself adds value?
• Where is your human review layer, and is it optimized for catching agent failure modes rather than traditional human ones?
• Are your engineers spending more time on judgment, direction, and evaluation… or are they still primarily in execution mode?
• How are you communicating the implications of agentic development to your CEO and board, and are you bringing them along before the organizational changes become visible?
• What does “done” mean in your current process, and does that definition still hold in an environment where iteration is nearly free?

A Final Thought

The CTOs who navigate this transition well aren’t the ones who adopt every new tool fastest. They’re the ones who understand what the tools change about process, about team structure, about where human judgment is irreplaceable and redesign their organizations around that understanding.

That’s not a tooling or process problem. It’s a leadership problem.

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 (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.

The boundary between product and engineering is dissolving fast, and for CTOs and CPOs, the more consequential change isn’t in the tooling. It’s in how you structure your teams, define roles, and make strategic decisions.

This is what I’m seeing on the ground with the technology leaders I coach, and what I think every CTO and CPO needs to be thinking about right now.

The Blurring Line Between Product and Engineering

For decades, software teams operated on a handoff model: product managers defined what to build, engineers figured out how to build it, and the two disciplines met somewhere in the middle usually in a doc or a Jira backlog. That model is breaking down, and it’s happening now.

I’m seeing product leaders build functional prototypes using tools like Cursor, Lovable, and Claude Code, and submit pull requests directly to engineering repositories. Engineers, meanwhile, are shaping UX decisions, architectural strategy, and product direction from day one not after requirements are handed over.

AI isn’t just making each individual faster. It’s eliminating the friction between roles entirely, turning sequential handoffs into continuous, shared problem-solving. As a CTO or CPO, this changes what you need to lead, how you design your organization, and what you hire for. The leaders who recognize this early will have a significant advantage.

What’s Emerging Right Now

Three structural shifts are already visible in forward-thinking tech organizations:

What Won’t Change

Amid all this disruption, some things remain irreplaceable  and these are exactly the areas where exceptional CTOs and CPOs create disproportionate value. I want to be direct about this, because I think there’s a risk of tech leaders undervaluing what makes them most effective:

AI handles implementation velocity. Tech leaders handle direction. In my experience coaching CTOs and CPOs, that distinction is becoming more important, not less.

The Strategic Question Every CTO and CPO Is Facing

The honest answer is: it depends on the organization. But the direction of travel is clear. The most effective teams will likely look less like two distinct disciplines coordinating with each other, and more like a unified group of versatile builders with AI deeply embedded in how they work.

The transition won’t happen overnight, and not every company will move at the same pace. But the CTOs and CPOs who start designing for this reality now , especially in how they hire, structure teams, and evaluate performance will be better positioned to scale, move faster, and build better products.

Key Questions for Tech Leaders Navigating This Shift

If you’re a CTO or CPO thinking through what this means for your organization, these are the questions I’d encourage you to sit with:

• Are you hiring for adaptability and curiosity, or optimizing for role-specific credentials that may matter less in 18 months?
• Do your team rituals (stand-ups, planning, retrospectives) still reflect a handoff model, or a genuinely collaborative one?
• Are you creating the conditions for engineers to engage in product strategy, and for product leaders to get hands-on with prototypes?
• How are you communicating this evolving organizational design to your CEO and board and bringing them along on the journey?

Coaching CTOs and CPOs Through How AI Is Changing Their Role

These aren’t abstract future challenges. They’re decisions being made right now, in real organizations, under real pressure. And they’re exactly the kind of high-stakes, nuanced questions that CTO and CPO coaching is designed to help you work through.

At Hoola Hoop, my coaching work with CTOs and CPOs is built around the specific challenges of leading technology organizations at the intersection of AI, organizational design, and business strategy. I work with tech leaders at startups and growth-stage companies who are navigating ambiguity, scaling teams, and shaping the future of how their organizations build and ship.

Every coach at Hoola Hoop is a former operator including CTOs, CPOs, and C-suite executives who have sat in the seat. We don’t offer generic leadership frameworks. We bring real-world experience from inside the roles you’re in, and help you develop the strategic clarity, executive presence, and organizational judgment to lead effectively through periods of rapid change.

Whether you’re rethinking your team structure, preparing for a board conversation about AI strategy, or working through how your role itself is evolving — I’d love to help.

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. Leigh has worked with a wide range of startups and global enterprises, including Avid, Digidesign, WPP, and Kantar/Millward Brown. He 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.

In this executive leadership episode of EdTech Elevated, Lisa March, President and Founder of Partner in Publishing, interviews Leigh Newsome, Partner at Hoola Hoop and New York University adjunct professor. This episode focuses on scaling EdTech companies through navigating the complexities of technology leadership. Drawing from his experience as both a Silicon Valley engineering leader and executive coach, Leigh shares methodologies for CTOs and CEOs, including specialized CTO coaching programs and technology team optimization. In addition, how to prepare for due diligence and strategic technical debt management.

Furthermore, the discussion explores critical tech leadership challenges, particularly focusing on strategic outsourcing decisions, AI implementation and impact in education technology, and subsequently, conducting technical due diligence during mergers and acquisitions. Additionally, Leigh reveals effective frameworks for CEO-CTO alignment and demonstrates how Hoola Hoop’s comprehensive executive coaching and advisory services help EdTech leaders excel. Consequently, through targeted CTO coaching, leadership development, and strategic planning, Hoola Hoop consistently supports education technology executives in building and scaling successful companies.

00:06 – Introduction to EdTech Elevated

00:22 – Leigh Newsome’s Background and Role

01:31 – Leigh’s journey to CTO Leadership… and CTO Coach.

05:09 – Challenges in Technology Leadership

07:42 – AI’s Impact on EdTech

10:18 – Supporting Pre-Revenue Companies

13:03 – Due Diligence for Investors and M&A

16:45 – Outsourcing and Tech Team Management

19:20 – CEO and CTO Collaboration

25:10 – Hoola Hoop Team Overview

27:12 – Closing Remarks

Common Myths About CTO and CPO Coaching

Our Approach to CTO and CPO Coaching

What to Expect from Hoola Hoop CTO/CPO Coaching

Is Hoola Hoop Right for You?

Our coaching is ideal for tech leaders who:

• Embrace constructive feedback and new perspectives on technical and strategic challenges.
• Are dedicated to long-term personal growth and organizational technological advancement.
• Are willing to be challenged, open to measuring their success through concrete tech and product outcomes, and ready to step outside their comfort zone.

If you’re seeking a partnership that will elevate your tech leadership and enhance your company’s technological performance, let’s connect. Together, we’ll drive innovation, streamline your tech operations, and position your products for market success.

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. Leigh has worked with a wide range of startups and global enterprises, including Avid, Digidesign, WPP, and Kantar/Millward Brown. He 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.

Components of Product and Technology Due Diligence

Dispelling Common Myths

Several misconceptions surround product and technology due diligence:

Significance of Product and Technology Due Diligence

For investors and in M&A, understanding the true state of a company’s technology is vital. It helps mitigate risks, ensure alignment with future growth projections, and provide insights into whether the product and team can deliver on their promises. Ultimately, product due diligence is a strategic tool for safeguarding long-term investment value.

By conducting thorough product and tech due diligence, stakeholders can make more informed decisions, potentially avoiding costly mistakes and identifying promising opportunities that might otherwise be overlooked.

Reach out if you would like to know more about Product & Tech Diligence at Hoola Hoop.

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. Leigh has worked with a wide range of startups and global enterprises, including Avid, Digidesign, WPP, and Kantar/Millward Brown. He 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.

In this article I’ll walk through what investors and acquirers are really looking for, the most common mistakes CTOs make, and how to build a state of readiness before the request ever arrives. I also shared a detailed talk on this topic at ELC Annual 2020, including key excerpts from Hoola Hoop’s engineering due diligence playbook.

What Investors and Acquirers Are Actually Evaluating

Most CTOs assume technical due diligence is a code review. It isn’t. It’s a comprehensive assessment of whether your technology, your team, and your processes can deliver on the promises your business is making. Here’s what’s actually being examined:

Common Mistakes CTOs Make

In my experience conducting diligence and coaching engineering leaders through the process, the same failure modes come up repeatedly:

How to Prepare — Before the Request Arrives

The best time to prepare for technical due diligence is well before you need it. Here’s the framework I share with the CTOs I coach:

• Audit and document your technical debt Maintain a living document of known technical debt — what it is, why it exists, and what it would cost to address. Contextualized debt is manageable. Undocumented debt is a red flag.
• Document your architecture decisions Architecture Decision Records (ADRs) or a well-maintained architecture document show that your technology choices are intentional and understood by more than one person. This directly addresses key-person risk.
• Align R&D spend to your roadmap Be able to show clearly how engineering investment maps to product strategy and business goals. Investors want to see that spending is purposeful, not reactive.
• Prepare your technical leaders Your engineering managers and architects will be interviewed. Make sure they can articulate how decisions are made, how the team is structured, and how you manage quality and velocity. This isn’t coaching people to perform — it’s making sure your team can speak to what they actually do.
• Know your IP and security posture Document ownership of your intellectual property, your security practices, and any open source dependencies and their licenses. These are standard diligence questions that should never catch you off guard.
• Run an internal diligence exercise The most effective preparation is to conduct your own technical due diligence before an investor or acquirer does. Identify the gaps, address what you can, and build a clear narrative around the rest. This is exactly what Hoola Hoop’s engineering due diligence playbook is designed to facilitate.

Related Reading

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 (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.

At Hoola Hoop, our experience working with organizations of various sizes has consistently reinforced the importance of these foundational elements. We understand that successful technology leadership requires a balanced approach that combines technical expertise with strategic business acumen.

Want to learn more about effective technology leadership and CTO coaching? Contact our team to discuss how we can support your organization’s technical strategy and growth.

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. Leigh has worked with a wide range of startups and global enterprises, including Avid, Digidesign, WPP, and Kantar/Millward Brown. He 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.