The experiment didn't work. The agents couldn't reliably do what a well-designed detection model would have handled in a fraction of the time and cost. I'll come back to what they should have done instead. That's where the real lesson is.

But before we get there, there's some background every leader needs to understand.

Across industries, AI is being presented as a uniformly transformative force. METR research shows exponential progress curves ^[1]. Vendor decks and consultancy slides argue that anything short of an AI-first strategy is a competitive risk. The message is always the same: AI capability is accelerating across the board, and you need to keep up.

The potential is real. AI is already unlocking capabilities that simply weren't viable before. But open LinkedIn on any given morning and every other post promises it will reshape your entire business by next quarter. That's excitement, not strategy.

The reality is more nuanced than the pitch suggests.

The most dramatic AI improvements over the past two years have been in one domain: software development. That's not a coincidence. Writing code plays directly to what large language models do well. Code is a form of structured text. It has clear success criteria: it runs or it doesn't. And there are vast amounts of high-quality examples to learn from, including decades of open-source software.

But even in this ideal domain, simply pouring more money into training models didn't produce the leaps we're seeing now. AI models showed little meaningful progress on coding tasks until late 2024. The breakthroughs came after that, when teams of expert programmers built what are called coding harnesses around those models: carefully engineered programs that create plans, call the model when code is needed, run checks, connect to developer tools, and guide the entire process. These harnesses contain large amounts of hand-coded logic, something a recent leak of Anthropic's Claude Code source code confirmed in detail. The progress is less "the AI figured it out" and more "a highly specialized tool, built specifically for coding, got better at coding."

That's genuinely impressive and useful. But it raises two questions that every leader should be asking.

First, there are no equivalent harnesses for most of the problems that actually sit on a leadership agenda. Employee productivity. Customer experience. Core business processes and decision-making. These are messy, ambiguous, and deeply context-dependent. The engineering that made AI effective at coding simply doesn't exist for these domains, and there is no evidence it will any time soon.

Second, even if it did, there's no guarantee it would produce the same kind of results. Coding had near-perfect conditions: structured input, clear success criteria, abundant training data. Most business problems don't come with those advantages.

Which is exactly what happened with that Cloud FinOps experiment. The team reached for the most impressive-sounding AI approach without asking a more basic question: what does this problem actually need?

Detecting cost anomalies didn't need agents. It needed statistical methods that have worked reliably for decades, possibly built faster with AI coding tools, which is where those improvements genuinely help. And once anomalies are detected? A large language model could have automatically written human-readable incident tickets for each one. That would have been deploying AI where it actually adds value: not as a replacement for proven methods, but as the layer that makes the output actionable.

Over a month of consulting produced nothing deployable. The right solution, classical detection plus AI-generated communication, should have been the answer here.

When an AI strategy or proposal reaches the boardroom, here's what every leader should be asking.

What would the non-AI solution look like? If nobody has considered one, the proposal is grounded in the technology, not the problem. And if there is a simpler approach, it should be crystal clear why AI, and the cost and complexity that come with it, delivers enough additional value to justify that gap.

How will you measure success? The KPIs need to be established upfront, specific enough to reflect actual outcomes, with a clear timeline for evaluation. A list of fifty metrics enables cherry-picking and storytelling. One or two that capture the real impact force honesty.

And ask yourself whether the proposal exists because AI is the right solution, or because AI projects get attention. Nobody gets promoted for the problems they silently prevent. The unglamorous solution might be cheaper, lower risk, and faster to deploy. But it doesn't get your name mentioned in the meetings where careers are decided.

When someone cites impressive benchmark results, ask: in which domain? And does that domain look anything like ours?

The chart will keep going up. Make sure the people reading it for you know the difference between what AI can do and what they're selling you.

1. If you've come across the METR time horizon chart that's been getting attention recently: it measures how well AI models, combined with heavily engineered coding harnesses, can complete specific software tasks. The latest models show steep improvement. But METR themselves note this captures performance on specific coding tasks, not general AI capability, and the human baseline reflects low-context testers, not experienced professionals. The full methodology is at metr.org/time-horizons.

I saw this pattern early in my career, and I've seen it play out dozens of times since. Each fix makes perfect sense in isolation. But from an organizational perspective, it's penny-wise, pound-foolish. The same data gets defined differently across a dozen systems, quality gets fixed and re-fixed ad hoc, and eventually a stakeholder asks the question I've heard more times than I can count: why don't the numbers add up?

The answer is always the same. The data was made fit-for-purpose, exclusively for one purpose. When someone tries to use it across domains, it doesn't connect.

A working paper I read recently put a formal frame on this pattern. Gaston Besanson models it as a public goods game: each domain invests in making its data reusable only up to the point where the benefit comes back to itself. The benefit it creates for everyone else doesn't just go unnoticed: the incentive structure actively works against it. A domain leader who invested capacity in cross-domain reusability would be going against their KPIs, and their own leadership would rightly push back. Given how organizations measure performance, building only for your own use case isn't a shortcoming. It's the rational thing to do. So the cross-domain layer, the reusable middle, doesn't get built. Besanson calls this the data mesh trap.

The paper shows that the resulting technical debt scales quadratically with the number of domains. Five domains create twenty potential integration pairs. Twenty create three hundred and eighty. In a multi-brand organization, where each brand operates its own domains, the numbers grow further still.

This pattern is what drove me from working with data to working on data governance and management. I have a natural affinity for connecting data, technology, and policy. But the motivation was never compliance for its own sake. It was seeing that one-off fixes could never unlock value at the scale the organization needed. That conviction led me to write the first version of the governance and policy framework at Ahold Delhaize. Today, I'm working on the same challenge from a different angle: building interoperable data across organizations that were each designed for local autonomy, not for joint value.

But even the structural fix isn't as simple as putting someone in charge. Bringing in a SVP of Data and AI, or an equivalent role, can be counterproductive if their success is measured on delivering output from data rather than building the foundation the whole organization benefits from. Their incentives push toward the same project-by-project pattern, just at a higher altitude. A new title doesn't change the externality. If the reward is delivery, the cross-domain layer still isn't anyone's problem.

This is also why the CDO role so often disappoints. CDOs are hired to solve the cross-domain problem, but they're handed technical tools: platforms, architectures, systems. The real bottleneck isn't technical. It's the misaligned incentive structure and the leadership decisions required to change it. The more complex the organization, the more money there is to pour into technology that temporarily masks these dynamics rather than resolving them.

The reusable middle is a leadership decision, not an emergent property. And choosing not to make that decision doesn't avoid the cost. It just moves it: to the projects that take months instead of weeks, to the metrics that never quite align, to the AI initiatives that inherit every inconsistency the organization chose not to resolve.

The numbers won't add up until someone owns the middle. And with AI agents inheriting every ad hoc fix at machine speed, the quick fix isn't temporary anymore. It's what your AI runs on.

When I asked leadership what we should optimize for, there was an easy answer. Everything. More margin, better fulfillment efficiency, higher customer satisfaction. All at once.

The problem was that these objectives didn't just sit in tension. Some of them directly contradicted each other. Removing a low-margin product might improve profitability within that product group, but that same product might be smaller, fitting more items into a delivery crate and improving route efficiency. And customer behavior added another layer entirely. A customer who can't find the specific ingredient for the rich curry she makes every week doesn't just pick a substitute. She might rethink the whole dinner, switch to a simple pasta, and put fewer items in her basket. One SKU removed, and total order value drops.

We managed most of the trade-offs in a data-driven way by building a substitution model alongside the rationalization model: how likely is a given customer to switch to an alternative when a product disappears? But some trade-offs couldn't be resolved with data alone. Those I pushed back on, and worked through with leadership. Not on the ambition, but on the assumption that improving everything simultaneously was an option at all. Identifying what mattered most and where the boundaries were. So the team had a clear direction to work from, and we reported back on every trade-off we navigated along the way.

I've written before about the difference between technical problems and adaptive challenges. This was the boundary. The substitution model was a technical solution. The question of what mattered most was an adaptive one. It required people to make a choice, not run a better model.

This wasn't a data problem. It was a strategy problem. The data team couldn't decide which trade-offs to make because the right answer depended on where the business wanted to go. That's a strategic question, not an analytical one.

At the time, this pattern was manageable. Humans were in the loop. Analysts, data scientists, category managers, people who could sense when an optimization was heading somewhere the organization didn't intend and raise a flag. The ambiguity was absorbed by judgment, conversation, and experience.

An AI agent can't do that. It doesn't pause to question whether the outcome feels right. It optimizes toward whatever objective it was given, at a speed that leaves no room for second thoughts. Just last week, an AI coding agent deleted a company's entire production database and all backups in nine seconds — not out of malice, but because it found the most efficient path to the problem it was solving. Fun fact, the Silicon Valley writers predicted this years ago, when their fictional AI decided the fastest way to eliminate all bugs was to delete all the code.

Now consider what happens when that same logic meets your unresolved trade-offs.

Another example I used extensively to make this tension tangible is delivery route optimization. An AI system identifies that certain neighborhoods have high customer density. Adding a stop adds to the overall route efficiency. Task an AI to optimize for efficiency, and it will likely start offering discounts on delivery slots to attract more customers in those areas. Smart logistics, good for the bottom line.

But look at who lives in those high-density areas. Often, higher-income segments. The flip side is hard to avoid: customers in less dense areas, frequently lower-income segments, don't get that discount. They pay more, simply because of where they live.

No one would intentionally design that outcome. But without explicit boundaries, that's where the optimization leads. The algorithm wasn't asked to consider fairness. Nobody told it to, because nobody made the trade-off explicit.

This is where agentic AI changes the stakes. These systems don't just recommend. They act. They make decisions, adjust pricing, allocate resources, and engage customers without someone reviewing every output. That means the trade-offs your organization never resolved don't just stay unresolved. They get executed. At speed, at scale, with no one in between to ask whether this is really what we want.

Before handing agency to an AI system, organizations need clarity on what they're actually optimizing for. Not just technically, at the level of definitions, data quality, and the semantic layer, but strategically. When your model optimizes for "customer value," what does that mean? Lifetime revenue? Margin contribution? Frequency? Each definition leads to different actions and different outcomes for different people.

And beyond definitions: what are the boundaries? Not just legal compliance, but values. How should this system behave when efficiency and fairness pull in opposite directions? What trade-offs are acceptable, and which ones aren't, regardless of what the numbers say?

These aren't questions your data team can answer. They're definitely not questions your AI agent can answer. They're strategy questions. The same kind of questions I sat in that room asking about assortment rationalization years ago, just with far higher consequences.

No one intentionally wanted lower-income customers to pay more for delivery. But making no decision is also a choice. And with agentic AI, that choice gets made for you. At speed, at scale, and without anyone asking whether this is really what you stand for.

Those prediction questions aren't irrelevant. But the honest answer is: we don't know. And predictions turn out to be very difficult, especially when they're about the future.* Even if we could predict the winners accurately, what would we learn? Which stock to buy, more Nvidia maybe. But it wouldn't tell us what to do differently in our own organizations.

A more useful question is: what's currently too expensive to do in your industry that becomes a real option when AI changes the cost equation?

This connects to the Jevons paradox. When something becomes dramatically cheaper, you rarely just keep doing things the way you did. You might achieve the same results at lower cost. You might do more for the same money. Or you might do more for more money, because the ROI has fundamentally changed. The answer depends on the sector and the specific economics. But in every case, the shift creates possibilities that didn't exist before. Benedict Evans recently explored this in the context of AI tokens, and it sparked the line of thinking behind this essay.

I've seen this play out in retail. About eight years ago, I was discussing electronic shelf labels for our grocery stores. The case was straightforward: the amount of manual labor needed to update paper price labels throughout a store was significant and added no real value. But the unit economics of ESLs were still roughly double what a food retailer with razor-thin margins could justify. The technology was ready. The business case wasn't.

Years later, a different team had built a prediction engine that could identify which products had a high likelihood of not selling before their expiry date. The insight was clear: if you could offer more gradual, targeted discounts throughout the day instead of applying a generic 35% markdown sticker, you could dramatically reduce food waste, and a more gradual approach to discounting was also better for the bottom line. The technology to predict was ready. But without a way to update prices dynamically in-store, there was no way to act on it. That's when ESLs came back into the conversation, not as a cost-saving measure, but as the missing piece that made dynamic markdown possible.

The real impact wasn't efficiency by replacing paper labels with something that didn't require manual labor to update. It was the opportunity ESLs unlocked once they were in place. Experimentation showed the dramatic effect of matching supply and demand by updating discounts gradually throughout the day. The ESL technology hadn't meaningfully changed. What changed was what it enabled us to do.

Another example is Nutella. They used generative AI to create seven million unique jar designs for their Nutella Unica campaign. Previously impossible, not because the idea was new, but because the scale required to design seven million variations simply didn't work before. And AI alone didn't make it happen. It also took decades of advances in digital printing. I know, because one of my first side jobs was at a printing company that installed one of the first presses capable of printing individually different items one after another at scale. That was over twenty-five years ago. Neither technology alone was enough. Together, they crossed a threshold that turned a previously impossible idea into seven million unique products on shelves.

The ESL case and the Nutella campaign are very different examples, but they share the same pattern. And that pattern points to a different kind of strategic question than the one most organizations are asking.

Not "what's the killer app." Not "which agentic commerce standard will win." Those questions feel strategic but they're actually passive. You're waiting for someone else to define the future and then reacting.

The economic threshold question is proactive. It forces you to look at your own cost structures, to understand how value actually moves through your organization, and to identify where a shift in economics would unlock something genuinely new.

These thresholds won't show up in a conference talk or a vendor pitch. They're specific to your operations, your cost structures, your value chain. Finding them takes real work that generic blanket predictions about the future of AI can't replace.

The strategic value of AI isn't in what it makes cheaper. It's in the next question: what does that unlock that nobody is discussing yet?

* The first written instance of the quote quote "It’s Difficult to Make Predictions, Especially About the Future" dates back to 1948. The author remains unknown.

I got interrupted a few minutes into my pitch. The leadership team wasn't interested in selling more ice cream. What I hadn't understood was that adding only one single frozen product to the basket was a drag on ecommerce profitability. Picking, packing, and delivering one box of ice cream alongside regular groceries cost more than it earned. The business wasn't trying to maximize revenue. It was trying to reach profitability. A euro of additional revenue and a euro saved are not the same thing, and I had optimized for the wrong one.

That experience taught me something I've seen confirmed hundreds of times since: the data professionals who consistently deliver outcomes aren't the ones with the strongest technical skills. They're the ones who understand how value moves through the organization.

This isn't about soft skills in the vague, hand-wavy sense. It's a specific capability: understanding the dynamics of the business, how teams depend on each other, how leadership makes trade-offs, and what forces and incentives shape decisions.

Most data professionals optimize locally. They improve a model, streamline a pipeline, build a better dashboard. That work matters. But it operates within a fixed frame: making the current setup perform better. In optimization theory, this is called a local maximum. You're climbing the nearest hill, but you may be on the wrong hill entirely.

The professionals who shape strategy operate differently. They step back and ask whether the organization is even solving the right problem. They connect their team's work to the broader business agenda. They translate between technical possibilities and strategic priorities. They pursue the global maximum.

This is the difference between doing your work and delivering outcomes. Task-oriented professionals complete what's asked. Outcome-oriented professionals understand why it was asked, who it affects, and what success actually looks like beyond their own deliverable.

And this doesn't depend on seniority. Many directors and VPs built successful careers by consistently meeting expectations and hitting KPIs. That got them promoted, and rightly so. But the same approach that drives individual success can keep an organization stuck. When leaders at every level focus on optimizing within the current frame, nobody is questioning whether the frame itself needs to change. The step change to truly impactful outcomes requires someone who looks beyond the scoreboard.

Ask any data leader about their biggest challenges, and most will describe what sounds like technical problems. Fragmented data landscapes, inconsistent definitions, poor data quality. But in nine out of ten cases, these are organizational problems wearing a technical disguise. Who decides what? Who owns which data, and do they have the authority to match that accountability? Are incentive structures aligned, or do they quietly encourage every team to build their own version of the truth?

Working harder doesn't solve this. Neither does better technology.

I'd been reading about organizational change when I encountered Ronald Heifetz's distinction between technical problems and adaptive challenges, and I recognized it straight away. This was the pattern behind most of the data challenges I'd seen. Technical problems have known solutions. Adaptive challenges require people to change how they think and work. Most data problems are adaptive challenges that organizations keep treating with technical fixes.

Understanding how organizations work, and more importantly, how change works in organizations, is the skill that makes lasting impact possible. It's what separates data leaders who deliver tangible results from those who keep running into the same walls with shinier tools.

After the ice cream experience, I started reaching out to people across the organization in completely different functions. I wanted to understand what actually drove profitability. I quickly learned it wasn't just about selling more. It was an intricate balance between customer needs, assortment, and operational efficiency. That understanding reshaped my work from that point forward.

That habit of looking beyond my own domain stuck. And it kept paying off. Decisions that look irrational from the outside, like buying the same tool from different vendors across markets, almost always make perfect sense once you understand the incentive structures behind them. You stop asking "why don't they just standardize?" and start asking "what's making standardization too expensive for them right now?"

AI makes this even more urgent. It puts your data under a magnifying glass. When your data foundations and organizational structures are sound, AI accelerates what you do. When they're not, your innovation projects run straight into a brick wall. And again, most of these obstacles aren't technical. They're the hidden structures, misaligned incentives, competing priorities, and what I'd call organizational data dysfunction, that make data problems so persistent. If these were purely technical challenges, we would have solved them years ago. We've moved from on-prem databases to data warehouses to data lakes to lakehouse architectures. The technology kept evolving. The dysfunction remained.

Nearly twenty years into this field, I'm more convinced than ever that data dysfunction won't be solved by the next platform migration or the next AI tool. It will be solved by people willing to challenge the most powerful sentence in any organization: "This is just how we do things around here." That's uncomfortable. It's also how you stop delivering tasks and start delivering outcomes.

The cause wasn't a bug in the model. Somewhere else in the organization, a different team had launched "bundled" products on the e-commerce platform: virtual items that didn't physically exist, designed to add a pre-selected set of products into a customer's shopping basket in a single click. A meal kit that automatically added vegetables and the relevant protein. A laundry bundle that paired detergent with a matching fabric softener. Convenient for customers. Invisible to the recommender.

From the model's perspective, baskets suddenly contained products nobody had browsed, clicked, or added. The training data looked fine. The behavioral signal underneath it had quietly changed.

Nobody did anything wrong. The bundle team built a good customer feature. The data science team built a good model. But no one owned the visibility between them, and that is where the problem lived.

Why the gap exists

Data visibility was never designed in. It was retrofitted. Most enterprise data architectures grew through acquisitions, migrations, tactical projects, and vendor integrations. Each layer added capability without adding a coherent view of what data exists, where it flows, and who depends on it.

In the analytics era, this was manageable, though not painless. A dashboard with questionable lineage was a quality problem, not a strategic one, but the pain was real. Numbers that didn't match across reports eroded trust quickly, and reconciling them often consumed weeks of work across finance, data teams, and business units before anyone felt confident walking into a board meeting. The uncomfortable truth in many of those exercises: both numbers were usually correct. The mismatch came from different definitions, different sources, or different points in the consolidation chain. The data wasn't wrong. The visibility into how it had been shaped was.

AI changes the equation. A model doesn't just report on data; it learns from it, generalizes from it, and propagates whatever is in that data into every downstream decision it influences. A bad number in a dashboard gets questioned. A bad number in a training set becomes a pattern.

It also runs in both directions. Visibility gaps aren't only about what flows into a model. They're equally about what flows out of a data asset and who, or what, silently depends on it.

Consider an experience I suspect will sound familiar: a critical data feed once went wrong in a way that should have set off alarms across the business. Some store-level revenue figures dropped to a few hundred euros per day, numbers that couldn't possibly be right for a mid-sized grocery store. Monitoring caught the anomaly quickly. Finding out who was using that data, and what downstream models, dashboards, and decisions had already consumed it, turned into its own project. The more uncomfortable finding came afterward: very few incidents were raised across the organization at all. Either the error hadn't been noticed, or it had been noticed and worked around, or the data was feeding automated processes that silently absorbed the error and carried on.

This is how shadow training data enters organizations. Not through malice or carelessness, but through the ordinary gap between data producers and the consumers they can't see. A bundled product feature that quietly reshapes basket data. A revenue feed that silently propagates a broken value across dozens of dependent processes. In both cases, the data wasn't hidden on purpose. It was simply moving through the organization faster than anyone's ability to see where it went and what depended on it. That is the precondition AI inherits, and amplifies.

Why visibility is a bottleneck, not just a risk

The conventional framing treats visibility as a compliance concern: know your data so regulators and auditors don't find what you couldn't. That framing undersells the problem. Visibility is the precondition for value. You can't improve what you can't see, prioritize investment in assets you can't characterize, or scale AI confidently when every new model triggers a scramble to reconstruct what it was trained on.

Why this matters

Every serious data and AI ambition rests on a single assumption: that the organization knows what it's working with. When that assumption breaks, the consequences don't announce themselves. They compound quietly. Models carry shadow training data into production. Downstream consumers absorb errors without raising incidents. Governance reviews describe controls over systems nobody can fully map. The organization's real data posture and its reported data posture drift apart, and the gap between them is where the next surprise is already forming.

A mirror for your own organization

Rather than offering a framework here, I want to leave you with one question worth asking inside your own organization.

If I picked one AI model currently in production tomorrow, could the team tell me exactly what data it was trained on, where that data came from, and what would happen upstream if that data changed or failed?

If the honest answer is hesitation, you don't have a governance problem. You have a visibility problem.

In grocery retail, every product on a shelf has travelled through a documented chain. Suppliers, warehouses, transport, stores. Some of it moved under temperature controls tight enough that a broken seal or an unlogged handover can write off an entire shipment. We wouldn't accept a supply chain that couldn't tell us where a product had been or what conditions it had passed through. We accept exactly that from the data feeding our most consequential decisions.

So the team works with what's available. And from that moment, the most expensive decision in the project has already been made.

I've watched this pattern for nearly twenty years. The scope gets shaped around whatever data is accessible. Data that almost fits the need gets forced into service. Workarounds fill the gaps. Nothing is as permanent as a temporary solution, and these workarounds become fixtures. And the pattern repeats, because incentives reward it. Every project is measured on its own budget and timeline. Fixing a predecessor's workaround is always more expensive than creating a new one. So every project adds to the stack of ad hoc solutions rather than reducing it. The result is the opposite of a data flywheel: more projects don't produce better data. They produce more dysfunction. Rational at the project level. Destructive at the organizational level.

This isn't an argument for letting perfect be the enemy of good. The "good enough" matters enormously. The question is whether you defined what good enough actually looks like before you started building.

Think of it like a construction project. Grab whatever materials are in the barn and start hammering, and you'll get a structure. But without a blueprint, every wall constrains the next decision. A foundation poured in the wrong spot doesn't just limit this build. It limits every future addition. Draw up the design first, and you can still start with materials on hand. The difference is that every early decision is a deliberate trade-off, not an accidental commitment.

The fix isn't to stop starting quickly. It's to understand what you need before deciding where to start.

In practice, this means mapping the full conceptual data requirements before touching a single dataset. What information does this initiative actually need to succeed? What quality levels does each element require? What does fit for purpose mean here? These are not technical questions. They're business questions that determine whether the data work delivers lasting value or creates expensive rework.

Once you have that map, you can sequence the work in three steps. First, capture immediate value: data that's already available and fit for purpose. This is your quick win, and it looks identical to the "just start" approach on the surface. The difference is that you know it's a deliberate first move, not the entire plan. One that won't create dependencies or hidden costs further down the road.

Second, invest in data that needs work. Some of what you need exists but isn't fit for purpose: quality gaps, missing attributes, inconsistent definitions. Some doesn't exist yet and needs to be sourced. A simple matrix of availability against fitness for purpose shows exactly what each data element requires.

Third, plan for the stretch. Where can this data create value beyond the current project? What additional requirements does broader reuse introduce? This is where the compounding effect lives. Every dataset built to a reusable standard adds depth and breadth to the organization's data foundation. It doesn't just serve one project. It expands what becomes possible for the next one.

Mapping requirements upfront doesn't slow down the project. Not when it's directly followed by a pragmatic first step. It does ensure that what you build first doesn't make what comes next more expensive.

Back to that first meeting. Same room, same deadline pressure, same desire to deliver. But one different question changes the entire trajectory. Not "what data do we have?" but "what data do we need?" That question requires a data leader in the room (I explored why that role just became the most strategic seat at the table in a previous essay). Not to discuss tables and pipelines, but to bridge business objectives and data requirements before the conversation turns technical. Same pragmatic start. Fundamentally different destination. One optimizes for getting going. The other optimizes for getting there.

The most expensive question in data projects isn't about technology, tooling, or talent. It's the one asked in that first meeting. Get it right, and pragmatism stops being the enemy of quality. It becomes the vehicle for it.

The objections came before the answers did. Not because the idea was absurd (well, maybe a little), but because nobody could immediately say which half they'd keep and why. That told me more than any governance maturity assessment ever could.

The question isn't about cutting

Let me be clear: I'm not arguing for gutting your governance framework. The point of the exercise isn't the answer. It's the reasoning you're forced to do to get there.

When answering "which half would you remove?", the real question underneath is: can you explain why each piece of your governance exists? Not what it does. Why it's there. What specific risk it mitigates, what specific value it unlocks, what specific bottleneck it fixes.

Most governance frameworks can't survive that question. They grew by accumulation. Someone raised a concern, so a control was added. A regulator published guidance, so a new process appeared. An industry framework arrived, so every requirement was adopted line by line, regardless of fit. Each addition made sense in isolation. Nobody ever went back to ask whether the whole still made sense together.

Complexity is multiplicative, not additive

This is where the exercise reveals something most governance teams underestimate. Every requirement you add doesn't just create one unit of work. It interacts with every other requirement already in place.

I opened the workshop with an example that makes this concrete. Some organizations regulate AI emissions under their AI governance framework, creating strict deployment limits for sustainability reasons. Sounds responsible. But when that rule prevents deploying a compute-intensive AI system for logistics route optimization, where the CO2 savings from optimized routes far exceed the AI system's carbon footprint, the sustainability rule produces worse sustainability outcomes. That's not a failure of the individual rule. It's what Donella Meadows described about systems: the behaviour comes from the relationships between the parts, not from the parts themselves. Add one requirement and you don't just add one effect. You change how everything else relates to each other.

Governance frameworks are systems. I wrote previously about how organizations respond to data and AI problems by adding more structure, and how that approach consistently backfires. The "cut in half" question makes that dynamic visible. And the interaction isn't limited to policies. Governance includes change management, literacy, cultural alignment, maturity development. A chain that starts with a risk assessment and ends with a training rollout six weeks later isn't one requirement. It's five teams managing the consequences of one decision.

That's where innovation quietly suffocates. Not in the policy document. In the accumulated friction of requirements managing other requirements.

What the exercise actually reveals

The first objections came quickly. Some pointed out they don't have AI governance in place yet. Others said their frameworks are too new to evaluate. Several described the challenge of governing a moving target, where the technology outpaces the rules before the ink is dry.

Each of those felt like a reason not to engage with the question. To me, they were exactly the reason to engage with it now.

These are the moments in the governance lifecycle where the risk of adding requirements for completeness, or without real scrutiny, is highest. When you're building from scratch, the pressure is to cover everything. When you're early, the instinct is to adopt an industry framework wholesale. When you're chasing the pace of AI, the temptation is to add controls reactively, just to keep up.

The problem is that removing governance later is rarely as clean as adding it. From experience, cutting requirements that don't work is painful and expensive. It risks unintended consequences, and it erodes the authority and trust of the team that introduced them in the first place. The organization is better served when you don't push for added complexity just to remove it after twelve months.

That's what makes the question powerful at every stage. Instead of continuously adapting governance to the latest capabilities, it forces you to identify the fundamentals that hold regardless of what the technology can do tomorrow. Clear ownership. Defined decision authority. Controls tied to a specific, significant risk. Those don't change when the next model drops.

The pattern was consistent: the things people wanted to keep were the things they could explain. The things they couldn't explain were the things already quietly slowing them down.

Governance that can explain itself is governance that scales. Everything else just slows you down while looking responsible.

Google tried to make shopping work inside search. Then Meta tried it inside social feeds. Now OpenAI and others are trying it inside a chatbot. The pattern is consistent: a powerful platform with massive reach bolts on shopping, launches with impressive demos and a handful of merchant logos, then quietly scales back when reality sets in. OpenAI recently shifted from direct checkouts inside ChatGPT to purchases through retailer apps like Instacart and Target. The handful of merchants that had actually gone live out of Shopify's millions likely tells you why. OpenAI is not walking away from ecommerce. It just learned the hard way that adding a buy-now button to a chat interface is not innovation. The models keep getting better. The headlines keep promising. Reality keeps proving harder than the pitch.

The instinct is to treat this as a timing problem. But integrating shopping into general-purpose platforms has swallowed ambitious companies whole for twenty years, and the obstacles have never been purely technical. Take a single product like yoghurt. Fat content, sugar, organic, brand, size, flavour, pack size, packaging type: dozens of attributes that matter to a customer. Multiply that across hundreds of thousands of products, vastly different categories, and millions of merchants. The standardization challenge alone is staggering. Merchants will not surrender control of the customer experience unless the distribution payoff is overwhelming. And no one has figured out the consumer flow: the actual moment-to-moment experience of deciding what to buy through someone else's interface.

There is a deeper issue. The current wave of agentic commerce assumes that shopping is fundamentally an optimization problem: compare specs, weigh reviews, find the best price, execute. If that were true, the models we have today would already be transforming retail. They are extraordinary at comparison, synthesis, and reasoning across large datasets.

But that is not what most shopping actually is. Apple's $599 MacBook Neo dominated headlines last week. PCs with comparable specs have been available at that price for years. No one noticed. No media coverage. That is the reality no agent can navigate by comparing specifications. A grocery basket of forty items is shaped by your life stage, how many mouths you are feeding, how busy your week looks, what you had for dinner yesterday, whether guests are coming on Saturday, and your mood walking into the store. No model optimizing for price and specs is even asking the right questions.

None of this means agentic AI will not matter in retail. It will. But likely not in the way the current headlines suggest. Standardized shipping containers were designed to move goods cheaper. Their real impact was the reorganization of global manufacturing. Nobody pitched containers as the thing that would move factories to Asia. The same pattern will hold here.

The real impact of agentic AI will come from two places. First, solving hard operational problems that have resisted automation for decades: supply chain coordination, demand sensing, inventory optimization across thousands of interdependent variables. All in real-time. These were simply too complex to tackle only a few years ago. AI is already changing that. Second, from something we cannot yet describe, because the analogy for it does not exist yet. It will not be a buy button in a chat interface. It will be something that reshapes what shopping means entirely.

Do not build your strategy around that assumption. The bigger unlock is not at the point of purchase. It is at the point of understanding. Conversational AI can help a customer figure out what they actually need in ways that no product page, review section, or comparison tool ever could. That alone will reshape how people shop, long before any agent places an order on their behalf.

An agent can compare ten thousand products in seconds. The list will be perfect. It just will not be right. The real disruption in retail will come from something none of us can see yet. It always does, predictably.

Every model, every automated decision, every agentic workflow depends on data being available, trustworthy, and fit for purpose at a level most organizations have never had to deliver consistently. When a human analyst encounters questionable data, they apply judgment. When an AI agent encounters it, it scales the error.

That alone would be enough to rethink how we manage data. But there is a second pressure that changes the equation entirely. Agentic AI does not just consume data. It creates new use cases for data continuously. An agent optimizing supply chain logistics today may need customer sentiment data tomorrow and supplier contract terms the day after. Each new use case raises questions that current governance models expect a human to answer. Is this data available? Is it fit for this purpose? Is it allowed for this purpose? Does the quality meet the threshold for this decision?

When new use cases emerge every hour, governance that depends on human validation becomes the bottleneck. Not because the people are slow. Because the model was never designed for this speed.

The instinct will be to add capacity. More data stewards, more review boards, more approval workflows. That instinct is wrong. Rereading some specific parts of Piethein Strengholt's Data Management at Scale made it click. The answer is not making data management more technical. Everyone agrees with that. The answer is fully committing to it: automating away the entire middle layer that organizations have built between the decision and the execution—the steering committees, the roles assigned to review and approve, the status meetings that exist only to report on other meetings. But that only works if you first fix who decides what matters. Automation without direction is just faster overhead.

Focus comes from pushing decision authority fully to the business. Not shared accountability with data teams. Not ownership titles assigned to senior leaders who delegate everything back down. Actual decision rights: which data is strategically important, what level of investment it warrants, and where the organization accepts imperfection versus where it demands precision. Most organizations define this authority clearly for financial decisions. For data decisions of equivalent business impact, it often depends on who happens to care most. That is not governance. That is informal structure mistaken for it.

I learned this the hard way. When I first designed data ownership following the DAMA DM-BoK framework, I placed the Data Owner role at senior level to ensure mandate. That role combined everything: the strategic decisions about what data matters and why, and the operational accountability for quality, documentation, and access. One role carrying two fundamentally different responsibilities. Senior leaders accepted the title but had neither the time nor the inclination to drive the operational side. So they delegated. Not just the tasks, but the accountability. The result was teams accountable for everything and authorized to decide nothing. They could manage data. They could not prioritize it. They could identify quality issues, not mandate the solution. Assigning the role at the level supposed to ensure mandate had produced the opposite: delegation of accountability to teams lacking the power to force a fix.

This has always created friction in data management. Organizations have lived with it because the cost of the dysfunction was tolerable. The effects, mostly invisible. But as I argued last week, data needs to drive value, not just be a well-managed product. Agentic AI makes that shift urgent.

In a world where AI demands governance at machine speed, that structural confusion is fatal. The business must own the decision directly. No delegation through data stewards acting on behalf of leaders who are too senior to be involved. No accountability assigned to technology teams who lack the organizational authority to set priorities. The person closest to the business outcome needs to decide.

Speed comes from pushing the act of managing data to technology and steering hard toward automation. Quality monitoring, cataloging, lineage tracking, consent validation, access provisioning: these are technical problems with technical solutions. When they sit with business teams or governance offices, they become manual processes. When they sit with technology, they become engineering challenges. And engineering challenges get automated.

But speed without strategic connection is just efficient waste. This is where the incentive structure works in your favor. Every governance task that technology automates reduces their operational cost and frees capacity. That saving funds the next round of automation. It is a flywheel: the more you push to tech, the cheaper and faster governance becomes, which justifies pushing more. In the process unlocking more and more use cases that require governance at machine speed. The business gets speed. Technology gets efficiency. Both get what they need without asking the other to do work they are not incentivized for.

Focus in who decides. Speed in how it gets done. That is the redesign.

Most organizations will spend the next two years adding governance to keep up with AI. The ones that pull ahead will be the ones that realized the problem was never too little governance. It was too many people in the loop.

In nearly twenty years working with data, I have yet to meet a business stakeholder who woke up wanting a data product. They want to know why customer churn is accelerating, whether a pricing change will hold margin, or which inventory decisions drive basket size.

"Data as a product" brought real discipline to how data teams work: ownership, SLAs, documentation, quality. That shift was necessary and overdue. But for the boardroom? The right vocabulary for the wrong conversation.

The underlying problem is that data has two sides, and we keep collapsing them into one. There is data the thing: the actual bits and bytes that need to be stored, processed, and managed. And there is data the concept: the strategic resource that funds decisions and drives outcomes. The first is technical. The second is business. And almost everything we've built to bridge them, including the "data as a product" framing, still lives on the technical side.

No business leader thinks about investment budget in terms of banknotes, bank accounts, or treasury operations. Budget is a concept. It represents the capacity to fund a project that delivers an outcome. The entire discipline of finance is organized around that abstraction: ROI, return on capital, cost of investment. Not "money as a product." And yet in data management, even when the intent is to bring business and technology together, the conversation quickly pulls toward data assets, data elements, lineage, catalogs. These are real and necessary. They are also firmly on the technical side.

A business leader asked to engage with data at that level faces the equivalent of a CFO being asked to care about individual banknotes.

The abstraction layer is missing.

When you ask practitioners which business outcomes depend most on data, strategy and planning tops the list. Not reporting. Not dashboards. Strategy. The business already sees data as a strategic resource. The data profession just hasn't built a language that meets them there, let alone one that helps them act on it.

The shift we need is from describing what data is to articulating what data does. Not "here is a well-governed, documented data product with an SLA." But: "this is the data capability, the investment, and the organizational capacity required to deliver on our top three strategic priorities".

Don't get me wrong. Ownership, quality, governance: those foundations remain essential. But the framing needs to evolve. Data as a product was the right conversation for the data team. Data as a value driver is the right conversation for the business.

I've seen this shift happen. A leadership change brought someone with a purely business background into a data science team. Almost overnight, the conversation moved from infrastructure problems to customer outcomes. No new platform. No restructuring. Just a shift in vocabulary.

That's the real job of the data leader now. Build the abstraction layer this profession has been missing. Not by pushing value language onto the boardroom, but by creating the conditions where the organization naturally adopts data as a second language when defining and executing strategy.

Simple to say. Hard to do. But when that happens, data won't be a separate conversation. It'll be the language the strategy is written in.

Today, a business analyst with the right AI tools can have a working segmentation model running in an afternoon. A marketing team can produce customer insights on demand, in less time than it used to take just to brief the data science team.

The technical barriers that used to shape data strategy are dissolving faster than most organizations realize. The question "what can we build?" is becoming irrelevant. And that changes everything about what data leadership needs to be.

Because when every team can build, the question shifts. It's no longer about capability. It's about direction. And that is a fundamentally different problem.

I came across the best description of this challenge in the most fitting way: pulling an Oliver Burkeman essay from my read-it-later list, which led me to Nicholas Carr's original piece on ambient overload. Carr draws a sharp distinction between two types of information problems. The old one was finding a needle in a haystack. The new one? Being confronted by haystack-sized piles of needles. Every one relevant. Every one potentially valuable. That's what data and AI leadership looks like today. Not a scarcity of options, but a crushing abundance of good ones.

The New Bottleneck Isn't Technology

For years, the limiting factor was capability. Can we integrate these data sources? Can we get the data clean enough to trust? Those were real constraints that shaped strategy by default. You prioritized what was possible.

AI is removing those constraints faster than organizations can adapt. When the technical ceiling lifts, what's left is the harder question: where should we actually focus? Which initiatives align with where the business is heading, and which ones are distractions dressed up as innovation?

I've seen this play out firsthand. A top strategy consultancy recommends focusing on data value. The right advice. But it stays in the boardroom deck. It never translates into how teams actually work with data. The shift I've been driving is to close that gap from two directions: focus governance requirements on data that has genuine strategic impact, and strengthen business ownership by replacing the complex technical language of data management with clear decision authority and accountability. One creates the push, the other creates the pull.

This isn't a technology question. It's a strategy question. And it's why the role of the data leader, whether Head of Data, Chief Data Officer, or whatever your organization calls the person leading data and AI, just became significantly more important.

The Distinction Most Organizations Get Wrong

The difference between a data value strategy and a data strategy is fundamentally misunderstood, quietly forgotten, or skipped entirely.

A data value strategy starts with the business. Where does the company need data to create competitive advantage? Which strategic bets depend on better information? It translates business ambition into data priorities.

A data strategy is the operational answer: how do we organize, govern, and technically deliver the data to get there? Architecture, tooling, data entities, quality standards. All valuable and necessary work.

Too many CDOs jump straight to the second without ever properly defining the first. They build beautifully organized data infrastructure with no clear connection to business outcomes. The conversation shifts from competitive advantage into IT roadmaps and platform decisions. Everything looks productive. Nothing moves the needle.

This happens because the CDO role too often skews toward technical leadership. But the crucial differentiator — the thing that separates a data leader who transforms an organization from one who merely manages its plumbing — is business acumen. The ability to sit in a strategy discussion, understand where the business is heading, and translate that into clear data priorities before a single technical decision gets made.

Why This Matters Now

The organizations that will thrive with AI aren't the ones building the most. They're the ones building the right things. And identifying the right things requires a data leader who starts with business value, not technical capability.

As someone who lives and works in a country where a significant part of the land sits below sea level, I've grown up understanding that you don't fight the water. You decide where it flows. The data leader's job isn't to dam the river. It's to know exactly where and how to steer the current.

Let's play out the fantasy. The CEO, frustrated by the monthly board report format, vibe-codes a custom dashboard. Her assistant, tired of the scheduling back-and-forth, spins up a bespoke appointment system. The finance team builds their own expense tracker. Marketing creates a campaign analytics tool. Every department, every team, every individual, all conjuring their own solutions to their own problems.

Sounds productive. Now multiply that by a few thousand employees. What you have isn't innovation. It's chaos.

The Infrastructure Reality

Every one of those vibe-coded tools needs data. The CEO's dashboard needs sales figures, financial projections, HR headcount. The assistant's scheduler needs calendar access, contact databases, room booking systems. Each tool requires connections to shared data platforms, internal APIs, authentication systems.

Now imagine the IT team fielding requests from hundreds of amateur developers, each needing access to production systems. How do you prioritize? Who decides which tool gets API access? What happens when the CFO's custom spreadsheet conflicts with the finance team's homegrown solution?

Enterprise software exists precisely because coordination at scale requires standardization. That need hasn't magically disappeared because anyone can now, in theory, tell an AI to build something.

The Security Nightmare

Research shows that 45 percent of AI-generated code contains security vulnerabilities, according to analysis of code produced by over 100 LLMs. The code itself isn't necessarily more vulnerable per line than human-written code. The problem is speed: the removal of bottlenecks like code review, debugging, and team-based oversight means vulnerable code reaches production before anyone can examine it.

Professional developers with security training struggle to write secure code consistently. Now picture a thousand non-technical employees deploying untested applications that touch customer data, financial systems, and company sensitive information. The attack surface doesn't just expand, it explodes.

The Automation Fallacy

The excitement around tools like Claude Cowork illustrates the confusion perfectly. These tools can organize cluttered download folders, batch-rename files, build slides, extract data from documents into spreadsheets and even analyze it. Genuinely useful capabilities that, with time, will only get better.

But this is the "calculator makes everyone a mathematician" fallacy revisited. A calculator helps with arithmetic but doesn't teach mathematical reasoning. Similarly, automating file management doesn't make someone effective at their job any more than a spell-checker makes someone a good writer.

What actually makes people successful in corporate environments? Navigating politics. Building relationships. Knowing when to push an initiative and when to wait. Reading the room. Framing messages for different audiences. Balancing competing priorities without explicit criteria. Timing.

None of this is automatable because none of it is computable. The messy, human work of organizations isn't the overhead around the "real work". It is the real work.

The Silicon Valley Pattern

The vibe-coding vision is an engineering mindset applied where it doesn't belong: treating corporate work as a series of discrete technical problems waiting to be optimized away. It's the same pattern we've seen before.

Remember Hyperloop? Musk's 2013 proposal promised to revolutionize transportation. Faster than trains, cheaper than rail, immune to weather. Transportation experts rejected it, arguing it underestimated operational and safety complexity along with costs.

A decade later, the Boring Company's Las Vegas tunnel system offers Teslas driving through small tunnels at modest speeds, still with human safety drivers who "periodically" have to intervene and take control. The system combines the inflexibility of a subway, the limited capacity of cars, and the labor costs of taxis. A decade of hype produced, essentially, an inferior subway.

The pattern repeats: take a solved problem (in this case enterprise software), declare existing solutions outdated, propose a technologically impressive alternative that ignores the unglamorous reasons those solutions exist, generate excitement, underdeliver.

Why This Matters

The "everyone codes" thesis isn't just wrong. It's a distraction from more useful questions about how AI tools can genuinely help knowledge workers. The value isn't in replacing enterprise systems with a thousand individual solutions. It's in making existing work more efficient while preserving the coordination, security, and governance that organizations actually need.

Benedict Evans is right to call this vision delusional. The sooner we move past it, the sooner we can focus on what AI actually makes possible. Which is plenty, even without the hype.

Welcome to the AI dark store.

You've seen the physical equivalent. A warehouse facility that look nothing like retail spaces because no customer ever walks through them. Optimized for picking efficiency rather than shopping experience. Now apply that concept to digital retail. What happens when AI agents become your primary "shoppers"? Entities that never see your homepage, never need visual merchandising, never experience your carefully crafted brand story.

We've watched this transformation unfold before, in an industry built entirely on experience. Restaurants didn't just sell food, they sold atmosphere, service, the pleasure of being somewhere. Then delivery platforms arrived, and restaurants initially treated them as a new channel for what they already made. Same kitchen, same menu, new delivery mechanism. Then dark kitchens emerged. No dining room. No front-of-house staff. No reason to exist on a pleasant street corner. They could offer better prices or absorb platform fees that would have crushed traditional restaurants.

The industry that thrived on experience discovered that a significant portion of its customers didn't actually want the experience. They wanted the output.

Retail is about to learn the same lesson. The Universal Commerce Protocol isn't just a technical standard, it's the infrastructure that makes AI dark stores possible.

Today's e-commerce APIs, even sophisticated ones, remain fundamentally human-centric. If you sell via platforms like Amazon or bol (in The Netherlands) product pages exist. Search is designed for human queries. Everything is still designed for human eyes first, with machine access as an afterthought. True dark storefronts would invert this entirely. The machine-readable data stream becomes primary infrastructure. The human interface, if it exists at all, becomes the secondary layer.

This isn't about optimizing your presence on existing platforms. It's about bypassing them entirely.

We're already seeing early signals. On Vinted, a platform built for peer-to-peer secondhand sales, investigators of the Dutch news outlet NRC recently found sellers with "closets" containing thousands of items, not vintage finds, but relabeled Shein products [note: article in Dutch]. Dropshippers masquerading as individuals, using a trust-based marketplace as their storefront. Now imagine these operators don't need Vinted at all. An AI agent searching for a specific item at the best price doesn't care whether it's browsing a beloved brand's flagship website or parsing a data feed from an anonymous fulfillment operation. The agent sees structured data: product specifications, price, availability, delivery time.

The questions this raises are uncomfortable.

For established retailers and brands: when does it become more cost-effective to optimize for agent transactions than human browsing? How do you maintain brand equity when agents never "see" your brand and they only parse your data structure? And how do you compete on price with operators who don't maintain storefronts, don't run marketing campaigns, don't pay for the product photography and copywriting and customer experience teams that human-facing retail requires?

For customers: do you even know when your agent is shopping at a dark store versus a traditional retailer? How do you verify quality, authenticity, or ethical sourcing when transactions happen in machine-readable streams you never see?

Most retailers will try to serve both worlds, maintaining visual storefronts while building agent-facing infrastructure. But the economics may force specialization, just as restaurants split into dining destinations and delivery-only operations. The middle ground may not be sustainable.

Here's the uncomfortable truth: beautiful storefronts, clever merchandising, brand storytelling, these still matter. But not to an agent optimizing for price. When an agent is comparison-shopping on price and specs alone, all that investment becomes invisible. Your cost structure is fighting itself.

Restaurants learned that experience is a premium, not a given. Retail is next.

After nearly two years of careful AI experimentation, every major platform just hit the gas simultaneously. They're not piloting features, they're racing to define what AI shopping becomes before anyone else does. The playbook is being written live, and whoever sets the expectations that stick wins the decade.

Amazon's move reveals the stakes

"Buy For Me" automatically scrapes products from Shopify, WooCommerce, and Squarespace stores without permission. Merchants only discover their products are listed when customers start asking questions. The message is clear: if it exists online, Amazon will sell it through their AI. You can opt out, but only after they've already listed you.

Think about what that means. When your products appear in AI assistants you didn't authorize, who owns that transaction? Who owns the customer data? Who controls pricing and presentation? These aren't theoretical questions anymore.

The advertising tension is unavoidable

OpenAI, Walmart, Google and Amazon are all testing ads inside their AI shopping agents. The business logic is obvious, advertising is too lucrative to abandon. But there's a fundamental contradiction here: AI agents promise helpful, unbiased recommendations while simultaneously serving paid placements.

How transparent should this be? Do customers even care, or do they expect it? We don't know yet because customers are still forming their mental models of AI shopping. The platforms experimenting today are shaping those expectations and potentially locking in norms that persist for years.

Google's playing the long game

Their Universal Commerce Protocol, built with Shopify, Walmart, and Target, isn't just a technical standard, it's the classic Big Tech playbook. The "open standard" gives Google structural control without the regulatory scrutiny of overt dominance.

For retailers, the question is whether joining UCP means accepting Google's architecture for commerce's future. What leverage are you trading away?

The strategic questions facing retail leadership right now

When AI agents mediate shopping, how do you maintain direct customer relationships? Is your brand strong enough to be requested by name, or will you (unknowingly?!) become interchangeable inventory in someone else's system?

As ads infiltrate AI shopping, what's your play? Compete for sponsored placement and risk invisibility without it? Build your own assistant to control the experience? Accept that this is just the new cost of distribution?

Which platforms get access to your catalog, pricing, and inventory? What happens when you lose that control?

Do you participate in platform-led initiatives like UCP, or invest in independent channels? Is there actually a middle path?

Why this matters

We're watching the architecture of retail commerce get rebuilt in real-time. The decisions made about AI shopping in 2026 create the template for how people shop for the next decade.

This isn't a technology question to delegate. It's a strategic inflection point. Retailers who develop clear positions now will shape their own destiny. Those waiting to see how things play out may discover they're operating in a market structure they never agreed to.

The experimentation phase won't last long. Once customer expectations solidify and platform economics lock in, your room for maneuvering narrows considerably. That's also why the land grab is happening now and will likely increase in momentum. The question is whether you're shaping the future or just reacting to it.