A digital playbook for the modern data and AI executive

CHAPTER 1

What is a Modern CDAIO

A Chief Data and AI Officer used to be a defensible, if narrow, job: own the data warehouse, enforce a governance policy, keep the BI team fed with clean tables. That job still exists inside the modern role, but it is no longer the job. A modern CDAIO is accountable for a wider claim — that the organization's data and AI capability shows up as a measurable line in the P&L, not as a line item in an IT budget.

This shift did not happen because data got less important. It happened because the tools changed faster than the role did. Ten years ago, "data leadership" mostly meant reporting: turning operational exhaust into dashboards executives could glance at once a quarter. Five years ago, it started meaning analytics: building models that could predict something useful, if a data scientist was available to build and maintain them. Today it means something closer to operations: AI agents that don't just inform a decision but take the first pass at executing it, with a human reviewing rather than doing. That is a genuinely different scope of accountability, and it changes what "good" looks like in the role.

The practical result is that a modern CDAIO sits closer to the P&L than a traditional data leader ever did. Where a classic Chief Data Officer might report progress in terms of data quality scores or platform uptime, a modern CDAIO is expected to report progress in terms a CFO already understands: hours reclaimed, cycle time compressed, error rates down, revenue protected or created. The data and AI work is still happening underneath — arguably it's harder and more technical than it used to be — but it is no longer allowed to stop at the technical layer. It has to surface as a business outcome or it doesn't count.

A second shift is who the CDAIO answers to and works alongside. The role increasingly requires being fluent in two different rooms: the technical room, where architecture, model quality, and data lineage still matter enormously, and the boardroom, where the conversation is about competitive exposure, cost of capital, and multiple expansion at exit. A CDAIO who can only speak in one of those rooms will struggle.

There's a useful way to place any organization — and any CDAIO candidate — on a maturity curve for this: Notion's AI Transformation Model, which describes four levels. At Level 1, AI is a thinking tool used ad hoc, with no organizational structure around it. At Level 2, AI becomes an assistant embedded in daily work with measurable time savings but no structural change to how work happens. At Level 3, AI becomes a teammate: agents handle recurring workflows end to end, and companies at this level typically reclaim 10 to 40 percent of team capacity in the functions where it's deployed. At Level 4, AI becomes the system itself — multi-agent orchestration, proactive workflows, governance built in rather than bolted on. Fewer than 2 percent of organizations are there today.

Most CDAIOs are hired precisely because their company is stuck at Level 1 and the board has noticed. The job, stated plainly, is to move the organization from individuals experimenting with chatbots to a company that runs meaningful parts of its operation on governed, monitored AI systems built on a real data foundation — without skipping the unglamorous data work that makes any of it durable. Skipping that foundation is the single most common failure mode in the role.

CHAPTER 2

How the Function is Evolving

The clearest way to understand why the data and analytics function is changing is to understand the two kinds of risk that now sit on every CDAIO's desk. The first is substitution risk: the probability that AI can perform the core work your company sells, at a lower cost and higher speed than your current operating model. If your company's value proposition is fundamentally "we do this task well, and clients pay us to do it," and AI can now do a credible version of that task, the economic value of your business is under direct and immediate pressure.

The second is ecosystem risk, and it's subtler because it doesn't require your own work to be substitutable at all. Even if AI cannot directly replace what you do, your customers, suppliers, and competitors are changing how they operate because of AI. If your customers are adopting AI-driven workflows and your company cannot plug into the way they now work, you become friction in someone else's system. You don't get replaced outright; you get quietly routed around. Both risks require an honest, separate assessment, and most companies have only ever thought seriously about the first one.

What makes this moment different from prior technology cycles is that the impact is not smooth. It is closer to bimodal: some companies will see genuinely transformative results from rewiring how they work around AI, and others will see almost nothing, even after significant spend. There is no gentle curve where everyone benefits a little. The determining factor is not how much a company spent on tools — it's whether the company actually redesigned its processes around AI capability, or simply layered AI onto the process it already had.

Structurally, this means the function is absorbing responsibilities that used to sit in separate silos. Data governance, which used to be a compliance-adjacent function focused on access control and privacy, now has to extend to models, AI use cases, and autonomous agents — a genuinely new governance surface that most existing frameworks weren't built for. Data engineering, which used to be about moving data from source systems into a warehouse, now has to think about context: structuring institutional knowledge so an AI system can actually use it, not just so a human analyst can query it. And analytics, which used to mean dashboards, now increasingly means agents that take the first pass at the work a dashboard used to merely describe.

None of this makes the traditional data discipline obsolete — if anything, it raises the stakes on getting it right, because AI systems amplify whatever data foundation they're built on. A well-governed, well-modeled data estate makes AI dramatically more valuable. A messy one makes AI dramatically more dangerous, because it now acts on the mess instead of just reporting it. That is the honest, unglamorous center of how the function is evolving: not that data discipline matters less because AI arrived, but that it matters more, faster, and with less room for error.

CHAPTER 3

Data and AI Strategy: Evaluation and Listening

Before a CDAIO writes a single roadmap slide, there is a phase that gets skipped more often than any other step in this playbook, and it is the one that determines whether everything downstream succeeds: evaluation and listening. Most data and AI strategies fail not because the technology choices were wrong, but because the strategy was written from a technology-first premise instead of a business-first one. A strategy that opens with "we will implement a modern data lakehouse and expand our AI capability" is describing infrastructure, not outcomes. A strategy that opens with "the business needs to close deals 20 percent faster, and here is what that requires of data and AI" is describing value.

Evaluation starts with an honest maturity assessment, and it has to run on two tracks simultaneously: the data track and the AI track, because they mature at different rates and get conflated constantly. On the data track, the useful questions are structural: Is there a single, trusted system of record for institutional knowledge, or is it scattered across drives, wikis, and people's heads? Do teams operate from a shared semantic layer, or does every function define "revenue" and "active customer" slightly differently? On the AI track, the useful diagnostic is Notion's AI Transformation Model — mapping where the organization actually sits between Level 1 and Level 4 — not where leadership believes it sits, which are reliably different numbers.

Listening is the second half of this chapter's title, and it is not a soft skill exercise — it is a specific, structured activity. It means sitting with the people who actually touch data and workflows daily, not just their managers, and asking three things: where are you making decisions with incomplete information today, what manual process consumes disproportionate time relative to its value, and what have you already tried to fix this that didn't work. That third question matters more than it seems, because the failure pattern of the prior attempt tells you more about what will actually work than any greenfield planning session will.

The output of evaluation and listening should be a shared vocabulary before it's a roadmap. Business capabilities — not systems, not platforms — are the translation layer between what the business needs and what gets built. Strategy that starts from business KPIs and works backward into required data and AI capability travels through an organization intact; strategy that starts from a target architecture and tries to justify itself backward into business value gets picked apart in the first budget meeting, because it never had a business owner to begin with.

Finally, evaluation is not a one-time gate before the "real" work starts. It needs a formal trigger for re-evaluation — at minimum an annual cycle, but ideally tied to specific events: an M&A transaction, a major restructuring, or a step-change in AI model capability that changes what's technically feasible. Strategy that only gets revisited when it's obviously broken is strategy that spends most of its life quietly wrong.

CHAPTER 4

Use Cases of CDAIO Impact

Every credible AI and data use case a modern CDAIO ships sorts into one of three categories, and understanding which one you're building matters more than the specific use case itself.

The mistake most CDAIOs make is treating these three categories as a maturity sequence — start with Replace, graduate to Expand, eventually earn the right to attempt Invent. In practice they should run in parallel from the start, with different governance and different funding conversations for each.

CHAPTER 5

Onboarding a New CDAIO

Before accepting a CDAIO mandate — or in the first week after accepting one — there are six questions worth answering honestly, because they are the same questions a sophisticated investor would ask in diligence, and if the organization can't answer them, that tells you exactly what your first ninety days need to look like.

The first question is about access versus integration: what share of the workforce has daily access to AI tools, and what share of that access is actually integrated into core workflows rather than sitting beside them, unused. The second question is about proof: can leadership name three specific AI or data deployments with measurable P&L impact, and state the total financial value they've created? Most organizations cannot define financial KPIs for their AI investment at all.

The third question cuts to the heart of whether transformation has actually happened or merely been announced: which jobs have been redesigned around AI, and what does the new workflow concretely look like? Most organizations have not redesigned a single job. The fourth question is about ownership: who is the senior owner of this initiative, and does the CEO actively and visibly sponsor it, not just tolerate it?

The fifth question is foundational and often the most revealing: is institutional knowledge documented in a structured, machine-readable format, or does it live primarily in people's heads and scattered documents? The sixth question addresses the newest and least mature area: what is the plan for agentic AI, and what governance framework exists for autonomous systems that take action rather than merely generate text?

A new CDAIO who walks in and gets honest, specific answers to all six questions has inherited an organization already well along the maturity curve, and the job becomes about acceleration. A CDAIO who gets vague or aspirational answers has inherited the harder, more valuable job: building the foundation these six questions assume already exists.

CHAPTER 6

First 60 Days — Listen and Diagnose

The first sixty days of a CDAIO mandate should produce almost no visible output, and that is by design, not by delay. The temptation to ship something quickly — a dashboard, a pilot, a quick win to prove momentum — is strong, and it is almost always a mistake, because anything built before the diagnosis is complete is built on assumptions rather than evidence.

The core activity of this period is mapping, on two parallel tracks. The first is a people-and-process map: identifying, function by function, the small number of individuals — usually three to five per function — who actually touch data and workflows daily. The second track is a technical map: what data actually exists, where it lives, how reliable it is, and what's already been attempted and abandoned. Prior failed initiatives are unusually informative — every organization has tried something before you arrived, and understanding precisely why it didn't stick tells you more about the real constraints than any architecture diagram will.

A parallel activity is placing the organization honestly on the AI Transformation Model based on what you observe directly, not on what leadership believes. This almost always produces a lower number than expected, and that gap between perceived and actual maturity is itself useful information.

By day sixty, the deliverable should not be a roadmap. It should be a diagnosis: a clear, evidence-based statement of where the organization actually is, which decisions are currently being made with incomplete or stale information, and which one or two opportunities have both real business sponsorship and a plausible path to a measurable outcome within the next thirty days. Naming those one or two opportunities is the bridge into the next phase — but naming ten is a sign the diagnosis wasn't rigorous enough.

CHAPTER 7

First 90 Days — Prioritize and Commit

Where the first sixty days are about listening without committing, the next thirty are about the opposite: narrowing hard, choosing specifically, and putting your name behind decisions that will be visible and reversible only at real cost. This is the period where a CDAIO earns or loses credibility.

The central task is choosing exactly two initiatives to commit real resources to: one from the Replace category and one from the Expand category, deliberately skipping Invent-category bets at this stage. Each of the two chosen initiatives needs a named business sponsor and a specific, falsifiable outcome statement: what metric moves, by roughly how much, measured by whom, by when.

Alongside choosing the initiatives, this period is when the underlying technical foundation gets decided. The decision runs across three layers: a data layer where institutional knowledge and operational data live in structured, queryable form; a logic layer where the rules live — which processes get automated, what an AI system is and isn't allowed to do autonomously; and an execution layer where AI systems actually take action, connecting to the tools people already use.

This is also the point where governance needs its first real shape, even if it's minimal. At minimum, there should be a single place where every AI initiative gets registered — who owns it, what it does, what data it touches — before it goes anywhere near production.

By the end of this period, the organization should be able to point to two named initiatives, two named business sponsors, two specific outcome commitments, and a lightweight but real technical foundation those initiatives are being built on.

CHAPTER 8

First 180 Days — Outcome-Based Data and AI

By day one hundred eighty, the organization needs to see something real: not a slide describing what will happen, but a production workflow that is actually running, being used, and producing a measurable result against the outcome statement committed to at day ninety.

The first and most important discipline of this period is resisting the temptation to call a pilot a launch. A pilot that ran for two weeks with five enthusiastic early adopters is not evidence of anything except that five enthusiastic people will use almost anything. A production workflow needs to be judged by whether it survives contact with the people who weren't excited about it.

Equally important, and far more commonly skipped, is building a real adoption dashboard rather than relying on vendor-reported license counts. A vendor console will tell you how many seats were purchased. It will not tell you whether your finance team is genuinely using the new workflow or whether three people tried it once and went back to the old spreadsheet. An adoption dashboard worth building tracks depth, not just access: active days, task completion, which workflows are getting reused versus abandoned, and which functions have zero adoption despite having access.

The other critical outcome of this period is the first hard evidence for the business case that will justify the next round of investment. Where it worked, this becomes the proof point that earns expanded scope and budget. Where it didn't work as expected, this is the moment for honest diagnosis rather than quiet abandonment.

CHAPTER 9

The Day-to-Day Playbook

Everything in the first one hundred eighty days builds toward an ongoing operating rhythm, and this chapter is that rhythm laid out across five domains: Strategy, Operating Model, Data Management, Governance, and Analytics & AI Operations. These aren't sequential phases like the earlier chapters — they run continuously and in parallel, and a mature CDAIO function is one that's actively working all five at once, even if the emphasis shifts month to month based on where the organization's biggest gap currently sits.

Each domain below follows the same structure: what the capability actually covers, the shift from foundational to modern practice within it, a real success story, a tip, and a caution. Read them not as five separate checklists but as five dials on the same instrument panel — most operational problems in a data and AI function show up as an imbalance across these five, not a total failure in any single one.

CHAPTER 10

Bringing It All Together

Every chapter in this playbook eventually collapses into one question worth returning to constantly: are you the fastest path to a good decision, or a checkpoint people quietly route around? Every practice described above exists in service of keeping the answer "fastest path," not "checkpoint."

The data and AI functions that fail rarely fail dramatically. They fail quietly, by becoming exactly the kind of checkpoint the rest of the organization learns to work around: governance with no fast lane, strategy revisited once a year regardless of what changed, an operating model with no clear mandate. None of these failures announce themselves. They show up as slowly declining trust, measured in how often people ask for your team's help versus how often they quietly find a workaround instead.

The single clearest signal of health across all five day-to-day domains is compounding speed, not raw output. Organizations that have genuinely rewired how they work around AI and a solid data foundation don't just move faster once — they get faster at getting faster, because each production workflow and each piece of institutional knowledge captured in structured form makes the next initiative cheaper to ship than the one before it.

This compounding effect has a real timeline attached to it. AI task completion rates have been doubling roughly every seven months, which means the gap between an organization that started building this foundation a year ago and one just starting now is not twelve months of lost time — it is twelve months of accelerating advantage compounding on the other side.

None of this requires a moonshot to start correcting. It requires the discipline this playbook has tried to model throughout: listen before you build, choose narrowly and commit specifically, measure honestly even when the answer is uncomfortable, and keep the five operating domains moving together rather than letting any single one race ahead of the foundation underneath it.