Say a support team’s pilot drafts responses well enough that the team wants it answering billing questions end to end. To do that it needs to read the billing system and post adjustments. The support executive who sponsored the pilot now needs agreement from finance, which owns the ledger, and from security, which owns the access rules. Nobody in that conversation reports to anyone else in it, and a pilot that worked for months turns into a negotiation.
Inside a function, AI initiatives move because one executive can decide everything the work touches. The pilots that get picked first are the ones that fit inside a single budget and a single risk owner, which is sensible, and it also means the boundary problem comes up late, after the easy wins are done and the money is committed. The work that’s left crosses functions, and that changes the problem from a technical one into a question of who decides, and companies rarely have a ready answer for it.
An order runs through sales, operations, finance and support before it’s fully done, and each function owns its step. Nobody owns the whole thing, so a model that automates it end to end needs an owner the org chart doesn’t have. A lot of the value sits in workflows like this, and a program that runs function by function tends to leave them for later.
The same splits keep coming back. Technology ownership belongs to whoever runs the system, outcome ownership to whoever’s number moves, and those are different people with different incentives. A data pipeline that four functions would use sits in nobody’s budget, so it doesn’t get built, and each function funds a smaller private version instead. And when a shared system gets something wrong, nobody has written down which function takes the loss.
A function that automates its own step can improve its own number while pushing work downstream. A faster intake that produces messier data looks like a win in the intake report and slows everything after it. Deciding which local win gives way to the larger one is a call no function makes about itself, so it has to be made above them.
I think decisions like these are what the CEO is for in a transformation. Model choices and tool standards have owners already, and so does any workflow that lives inside one function. A CEO who signs off on everything becomes the slowest step in the program, and the actual job is narrower: assign the owner where the org chart doesn’t produce one, fund the shared assets no single budget covers, set the risk line where the loss would touch more than one function, and decide which local target comes second.
The rest of the executive team runs it. Most of these conflicts should come up and end inside the COO’s cross functional cadence without moving up. The CIO looks after the shared platforms and the rules for what systems may do inside them, while the CFO counts the value and owns the funding path for the assets nobody wants to pay for alone. Legal draws the regulatory lines early, which is cheaper than auditing them late, and functional executives keep owning their outcomes, including the ones a shared workflow now produces. The CEO gets what’s left, meaning the calls none of those people can make about each other.
When a boundary decision stalls, the CEO sees it as technical delay. The integration is ‘taking longer than expected’ and the data access is ‘in review’. Behind it there’s usually an unsettled call. It sits between two people who each think the other should make it. A CEO who keeps reading slow integration reports should ask, for each one, whether the delay is engineering or a call nobody has made yet.
I think sponsorship without decisions is just ceremony. A CEO can fund the program and give the kickoff talk, and the transformation can still have no owner for the hard decisions. Name the last boundary decision the sponsor made that one of the functions argued against. If there isn’t one, the sponsorship is a signature, and the program is running on whatever the functions can agree among themselves.
None of this needs a special forum. In an ordinary operating review, a CEO can ask which workflows cross functions and who owns each one as a whole. Who pays for the data and the infrastructure everyone shares. Whose number absorbs the loss when a shared system gets something wrong. And which local target is allowed to fall so the company comes out ahead.
The org chart covers most of what a transformation raises. It has no place for an argument between two functions that don’t report to each other, and the useful AI work keeps producing that argument. Those calls are the CEO’s, whether the program routes them there or not.