One thing that becomes clear pretty quickly in the Data and AI Journey is that the work is usually more connected than it first appears. What starts as a conversation about a use case or a tool often turns into a much broader encounter with the organization itself: its data, its systems, its workflows, its governance habits, its vendor relationships, its risk posture, and its ability to make coordinated decisions under pressure. That is part of why this journey can feel so different from other kinds of change.

There is often plenty of motion. New tools show up. A few teams start experimenting. Vendor conversations get more serious. Leadership wants a clearer view of both opportunity and risk. Everyone can feel that something important is underway. What is harder to tell, at least at first, is whether all of that activity is adding up to a direction.

That tension has been sitting underneath a lot of the earlier pieces I’ve published here or on LinkedIn. What If Your Data and AI Work Was One Coherent Journey? asked whether these decisions are actually connected. Seeing the Journey Clearly Is One Thing. Moving Through It Is Another. pushed on the gap between understanding and execution. Keeping the Data and AI Journey on Course made a related point: getting started matters, but staying aligned matters just as much.

Several of the other articles have been working the same territory from different angles. When Good Strategy Still Does Not Move was about organizational friction. The Data Quality Standard That Actually Matters: “Fit for Purpose” was really about being practical rather than idealized. AI Does Not Fix Broken Work on Its Own and Human in the Loop Is Not Enoughboth point back to the same reality: progress depends on operating discipline, not just interest.

People want a roadmap. What they usually have is whitewater.

And by whitewater, I do not just mean uncertainty. I mean the full environment the organization is moving through. The data itself. The systems it lives in. The workflows and processes wrapped around it. Regulatory expectations. Vendor dependencies. Security threats and malicious actors. Member or customer expectations. Internal priorities, staffing realities, and the technical debt that has built up over time. All of that is part of the water. All of that shapes how cleanly the organization can move.

A roadmap suggests a fixed path, clear markers, and the comforting idea that if you follow the directions carefully enough, the trip should go more or less as expected. The data and AI journey rarely behaves that way. Conditions change. One new vendor feature can create a governance question nobody has really assigned. One promising use case can expose a data quality issue that was tolerable until something important started depending on it. One workflow change can reveal that the organization has policy language, but not a usable intake path, not a repeatable review cadence, and not much agreement on who is supposed to decide what.

That is usually when the work starts to feel more real.

The challenge is not just that the river moves. It is that the environment is uneven. Some parts are visible. Some are not. One team may be further along than another. One function may think the issue is speed while another is still trying to establish ownership, lineage, or basic oversight. The organization is not moving through one clean channel. It is moving through a changing operating environment with different depths, different constraints, and different risks showing up at different times.

The journey framework helps because it gives shape to something many teams are already experiencing. The Navigator model lays out five phases: Discover, Stabilize, Operationalize, Scale, and Embed. It also shows progress happening across connected areas: governance and risk, data foundations, strategy and use cases, technology and infrastructure, people and operating model, and process and workflow.

I have started to think about those areas less as swimlanes on a page and more as positions in the same raft. Governance and risk is in the boat. Data foundations is in the boat. Strategy and use cases, technology and infrastructure, people and operating model, and process and workflow are in the boat too. If one position is underpowered, another is overcompensating, and a third is out of rhythm, the raft can still move. It just does not move cleanly.

That is where a lot of organizations get themselves confused. What looks like a strategy problem may really be an intake problem. What gets described as a data problem may really be an ownership problem. What sounds like a governance concern may turn out to be a process problem, a training problem, or a visibility problem. Sometimes the organization is not stuck because it lacks ambition. It is stuck because one part of the raft is trying to correct for three others at once.

You can usually see that drift in fairly ordinary moments.

A team wants to move on a use case, but nobody can say with confidence what data it depends on, who owns that data, or whether the quality issues are already understood. A vendor relationship looks routine until someone realizes AI capability is embedded in the product and nobody has reviewed the data flow, the contract language, or the oversight expectation with that in mind. A governance committee exists, but intake is inconsistent, the same questions get answered from scratch each time, and follow-through depends more on individual memory than operating rhythm.

Sometimes the friction is even more basic. A data steward is named on paper, but nobody has given the role real time, authority, or support. A board wants a clearer picture of AI risk, but reporting is assembled manually and still does not connect use cases, vendors, controls, and actual business exposure. Something odd happens in production and the organization realizes it has cyber response, vendor response, and operational escalation, but nothing that cleanly handles an AI-related incident from intake through review.

That is the kind of complexity people are usually dealing with. Not abstract complexity. Operating complexity.

The Discover phase is where the work gets honest enough to be useful. An organization stops relying on instinct and starts building a clearer picture of what is already happening, where the real gaps are, and where the pressure points actually sit. This is often where teams realize the inventory is incomplete, vendor AI use is only partially visible, key workflows are still being understood through conversations rather than documentation, and important dependencies live mostly in people’s heads.

Stabilize is where structure starts to hold. Policies get adopted. Roles become clearer. Committees and charters stop being abstract ideas and start becoming part of how decisions are made. Data stewardship starts taking shape in a more durable way. This is also where organizations start finding out whether they actually mean what they wrote down. A policy is one thing. A working intake path is another. Naming a steward is one thing. Creating the conditions for stewardship to function is another.

Operationalize is where the work begins to leave evidence behind. Governance meetings happen on a cadence. Vendor reviews are no longer one-off scrambles. Reporting has a pattern. Intake becomes more consistent. Data quality and lineage are treated as living responsibilities rather than cleanup work that only happens after something goes wrong. It may not look dramatic from the outside, but this is usually the point where the organization starts depending less on heroics and more on operating rhythm.

Scale is where hidden weaknesses stop staying hidden. It is one thing to manage a few use cases with a lot of personal attention. It is another to show that the same discipline can hold across a broader portfolio, more vendors, more data domains, and more operational settings. This is where inconsistent classification, uneven vendor oversight, weak reporting, or automation that outruns governance starts to matter more. It is also where technical and non-technical leaders need a more shared picture of what is strong, what is brittle, and what needs to be reinforced before the organization adds more speed.

Embed is where the work starts feeling less like a special program and more like part of how the organization runs. Governance is not treated as a side effort. Data quality is not treated as a once-a-year concern. New use cases come through defined intake by default. Policy review, oversight, and operating accountability are part of the normal calendar. The river does not go flat, but the crew knows the water better, and the corrections are smaller because the habits are stronger.

Maturity also gets easier to talk about when it is framed this way. Too often, maturity turns into a score people want to defend. A more useful question is simpler: what can this organization actually sustain well right now? That tends to produce a better conversation because it leaves room for ambition without pretending every team should be in the same place or every gap should be solved at once.

It also makes the next move easier to see. Sometimes the next right move is an inventory. Sometimes it is a charter. Sometimes it is a cleaner intake gate, better lineage visibility, clearer ownership, or a more usable reporting cadence. Sometimes the issue is not control design at all. It is shared language, better board understanding, or tighter coordination across teams that are all trying to help in different ways.

That is one reason guidance matters differently on this journey than it does in a lot of other initiatives. A good guide does not show up with a generic map and insist the river should behave. A good guide helps the team see where it is, what kind of water is coming next, which position is working too hard to compensate for another, and what progress it can make without creating strain it cannot yet absorb.

This journey is not only about building capability. It is about building judgment.

If I were trying to make this practical for a leadership team, I would start with a few plain questions.

  • Do we have a usable view of the environment we are actually moving through, including data, systems, workflows, vendors, regulatory obligations, and security exposure?
  • Can we name the AI and data use cases already in play, including the ones that came in through vendors or informal team experimentation?
  • For a priority use case, can we trace the data source, owner, steward, workflow, approval path, and reporting expectation without reconstructing it from memory?
  • When something new shows up, do we have a lightweight intake and triage path, or do we improvise every time?
  • If something goes wrong, do we know who classifies it, who escalates it, and what evidence gets captured?
  • Are we relying on a few people to keep the raft straight, or do we actually have a rhythm the organization can sustain?

Those questions matter because they tell you more than whether the organization is interested. They tell you whether it is under control.

If the environment is still mostly understood through conversations, the work is probably earlier than people think. If the structure exists but intake, cadence, and follow-through are still uneven, the harder task is not another strategy session. It is operational discipline. If the basics are holding and the challenge is broader consistency across use cases, vendors, and workflows, then the conversation has shifted again. The point is not to force every organization into the same pace. It is to understand what kind of water it is actually in and what kind of move that makes possible.

The organizations moving well are not necessarily the ones making the most noise. Often they are the ones learning how to strengthen the right position at the right time, how to keep the crew in rhythm, and how to preserve trust while the river keeps changing around them.

By this point, most organizations do not need to be convinced that data and AI matter. The more useful conversation is about reading the water accurately, seeing where the drift is really coming from, and deciding what kind of control-building move comes next.

When you look at the organizations around you, what gets misread most often: the phase they are in, the capability that is actually weakest, or the amount of current they are already trying to manage?