The CTO Bought AI for the Dev Team. Everyone Else Is Still Waiting.

The CTO bought AI for her team. That's what happened. It wasn't a policy decision to deprioritize product, QA, and support — it was the natural outcome of how AI tools came to market, how procurement works, and who owns which budget line. Developer AI tools were sold to engineering leadership with clear ROI cases, per-seat pricing, and standard IT procurement paths. The rest of the org didn't have an equivalent conversation with an equivalent vendor.

Now the engineering team has Cursor, Claude Code, Copilot, and a managed MCP server. The product team shares a ChatGPT account. QA has nothing. Support has AI bundled into Zendesk. Operations and finance are running the same workflows they were running in 2023. The result is not a technology problem — it's an ownership problem. Nobody is accountable for the AI gap outside engineering.

How the procurement gap happened

AI coding tools were marketed to CTOs and engineering VPs. The vendor conversations happened with engineering leadership. The ROI case was developer velocity. The budget approved was engineering opex. The procurement owner was engineering. The outcome: engineering has AI tools, because engineering was the buyer.

The CPO has a different budget, different vendors pitching different products, and different metrics. General-purpose AI tools are available but aren't specifically designed for product management workflows. There's no vendor with a clear "PM AI productivity" pitch the way Cursor had a clear "developer productivity" pitch. So the CPO bought nothing, or bought a generic LLM subscription that doesn't actually solve the problem.

What the CTO bought in 2025–2026:
  Engineering team (22 people):
    Cursor Enterprise — $40/seat → $880/mo
    Claude Code — $100/seat → $2,200/mo
    GitHub Copilot — $19/seat → $418/mo
    Internal MCP server — $0 (built by the team)

  Product team (5 people):
    ChatGPT Team — $25/seat → $125/mo
    (shared, used for writing assistance)

  QA team (3 people):
    Nothing AI-specific

  Support team (6 people):
    Zendesk AI (bundled in existing plan)

  Operations / Finance / Legal:
    Nothing

  Summary: the CTO bought AI for the org she manages.

The "second wave" problem

The assumption inside most organizations is that a second wave of AI adoption will eventually reach non-developer roles. The CTO bought for engineering now; the CPO will buy for product later; the CCO will figure out support AI eventually. This is a comfortable assumption that doesn't match how organizational procurement actually works.

The second wave requires someone to own the problem. It requires a budget line that doesn't exist yet. It requires a vendor conversation that nobody has started. It requires pain visible enough to create urgency — and the pain of non-technical teams not having codebase AI is diffuse, hard to measure, and doesn't create a hard deadline the way a production incident does.

Why the "second wave" of AI for the rest of the company doesn't arrive:
  -> No clear owner: CPO, COO, CMO each assume it's someone else's problem
  -> No obvious budget line: developer AI was engineering opex, rest of org is ambiguous
  -> No visible pain: non-technical roles don't have metrics that surface their gap
  -> No urgent deadline: unlike a feature request, the gap doesn't create a deadline
  -> No clear vendor: developer AI tools are specific; non-developer tools are generic
  Result: the gap persists indefinitely, getting wider each sprint

What the CPO actually needs

The CPO's problem is not writing assistance. Product managers have ChatGPT for that and it's adequate for generic writing tasks. The problem is system knowledge — understanding what's actually in the codebase, what shipped, what's technically feasible, what the current state of the system is. That knowledge lives in the codebase, and non-technical roles have no tool to access it.

"Is this technically possible" costs a week when the PM has no independent way to check. With codebase AI, that question gets answered in seconds — not by the developer, but by the PM themselves. The CPO's productivity improvement is not "better writing AI." It's "codebase access in plain language."

The CEO's role in closing the gap

Closing the AI access gap across the org requires an owner who reports to nobody in the affected teams. The CTO can't own the CPO's tooling. The CPO can't own QA's tooling. The CEO or COO is the natural owner of an org-wide AI access policy that extends beyond the functions that had natural early adoption.

The CEO's frame is not "which tools should each role use" — that's a departmental question. It's "what information access does each role need to do their job at full speed, and which roles currently lack it?" That framing leads to a cross-functional AI deployment that doesn't leave 60% of the company behind while engineering accelerates.

Kognita as the org-wide codebase layer

Kognita is designed to address the cross-org AI gap. It indexes the codebase and makes it queryable by every member of the organization in plain language — without requiring each role to set up their own developer tools, without distributing API keys, without technical prerequisites. One connection covers the whole team.

What changes when the whole org has codebase access:
  Product: writes specs with accurate system context, fewer revision cycles
  QA: knows what changed before testing, shorter cycles
  Support: checks current system behavior, fewer escalations to engineering
  Sales: answers technical customer questions accurately
  Leadership: understands what's actually shipped vs. planned
  Engineering: stops fielding questions that have codebase answers

This is a different kind of AI investment than the CTO made. It's not a per-seat developer tool with per-developer productivity impact. It's a team-wide knowledge layer with productivity impact distributed across every role that needs system context to do their job. The ROI frame is delivery cycle improvement, not developer velocity.

The conversation leadership needs to have

The leadership conversation isn't "should we buy more AI tools?" It's "did our last AI investment improve our delivery speed, or did it improve our developer speed while leaving delivery speed unchanged?" The answer for most companies is the latter. The next investment should address the functions that constrain delivery — not the function that already has the best tools.

That reframe surfaces a clearer procurement question: which roles need codebase AI to keep pace with AI-accelerated engineering, and what's the cost of the current gap in those roles? The answer is measurable — support escalation rates, QA cycle times, PM alignment overhead — and it typically makes the case for a team-wide investment more compelling than the per-developer case the CTO made two years ago.

Final take

The CTO bought AI for the right reasons. The problem is that the purchase was scoped to the CTO's org, and the CTO's org is not the whole delivery chain. Engineering velocity improved. Delivery timeline didn't improve proportionally, because every step after code writing is still running at the same pace it was before.

Closing the gap requires someone to own it and a budget frame that covers the whole delivery chain rather than the engineering cost center. The companies that get ahead are the ones where leadership recognized that the second wave wasn't coming automatically and made it happen.

The CTO bought AI for the team she manages. The CPO, COO, and CCO didn't buy AI for the teams they manage. The result is an engineering org with compounding AI benefits and a company with flat delivery improvement. That gap doesn't close until leadership owns it cross-functionally.