Somewhere this quarter a CEO is reading next year’s budget request from the AI office they set up last year, and the request is bigger. More people, more projects. The office presents its own growth as proof that the program is working. I think, past a point, growth points the other way, and the companies that misread it end up depending on the office for good.
The office makes sense at the start. In year one the problems usually run across the whole company: every team is buying its own tools, nobody has written the rules on what data can go into which model, two departments are paying for the same vendor under different names, and the pilots that exist can’t be compared because each one measures itself differently. A small central team gets the company past that. It picks the stack, writes the data rules, builds workflows that hold up in daily use, and gives leadership one view of what’s running and what it costs. Putting the scarce skills in one team is the right call early, because the functions don’t have those skills yet and can’t hire them one at a time.
By year two the job has split in two, and the split is easy to miss because both halves look alike. One half is the system of the transformation: standards, shared infrastructure, the rules on data, the cadence that decides what gets built next and what gets retired. The other half is the work itself: the close automation in finance, the ticket routing in support, the screening support in recruiting, the pipeline drafting in sales. I think the office should keep owning the system for a while.
The trouble starts when it keeps owning the work too.
Run it that way for another year and a queue forms. A function that wants a workflow changed files a request and waits, because the people who can change it sit in another team with its own roadmap. The queue grows with every workflow the office ships, since everything the office builds becomes something the office maintains. And the function on the other side of the queue doesn’t staff for the capability or budget for it, so the judgment that comes from running the thing every day has nowhere to form inside the team whose number depends on it.
It also gets harder to say who’s accountable. When a workflow the office built misfires inside finance, finance points at the office and the office points at adoption, and both are right enough that nobody fixes anything. Adoption itself turns performative. Teams demo the tools at the quarterly review because the program expects a demo, then run the month the old way. Enthusiastic demos next to flat operating numbers are how I’ve learned to spot a program that’s being complied with rather than used.
So the work should end up where accountability for its output already lives. Finance ends up owning the close automation and paying its run cost out of the finance budget. Operations takes the routing and the exception handling. The screening support moves into HR along with the risk calls that come with it. Sales takes the pipeline drafting, and the platform underneath all of it lands with technology. When a workflow’s output is a function’s number, the function has to be able to change the workflow without asking anyone’s permission.
I think a small center should stay. Somebody has to hold the model and vendor standards, the shared infrastructure, the data boundaries, the portfolio cadence, and the escalation path for anything that crosses functions or breaks a rule. That’s a real job, and it never fully goes away. It’s also a job for a handful of people who set standards and read the portfolio, and it looks nothing like a delivery organization with a backlog and a headcount plan.
Handoffs work when the criteria are written early, in the office’s charter, rather than negotiated later under budget pressure. I think a workflow is ready to move when the function has a named owner who can modify it without a ticket, when the run cost sits in the function’s budget, when incidents route to the function first, and when the office’s remaining role for that workflow fits in one written sentence. If any of those is missing, the handoff is a slide in a reorg deck, and the queue comes back.
Which brings back the budget request. Headcount growth inside a transformation office measures activity, and the office exists to produce something else: capability inside the functions. Count instead how many workflows run without the office touching them, and how many people outside the office can change one without breaking it. An office that doubles while the functions still queue for changes is failing in a way that looks like success.
By designed to disappear I mean the office plans its own exit from day one. It opens with a charter that names what it will hand over and when. Budgets shrink as workflows move, and the people who built the workflows move into the functions with the work. After a couple of years the office is a small standards team, and the company runs its own operating layer. I think that’s the only version of an AI transformation office worth funding, and the budget request that should impress a CEO is the one that comes in smaller than last year’s.