Chapter 16
The Department of No
The Utopia of the Agentic Enterprise, Part III. Headcounts and Headquarters
Unless you work in the IT department yourself, you probably know the experience. You need something changed or connected. Fast, because you’re changing your business and need that workflow or form changed to put this idea on rails. The answer comes back slowly and wrapped in process: a form to fill out, which asks a lot of questions that don’t apply to your case and generally feel like an excuse not to do something. And if you work in IT, you wrote the form, and you had your reasons.
Those reasons go back to the 1980s, when the British government’s Central Computer and Telecommunications Agency wrote down how to run IT services, in books eventually called ITIL.1 The private sector adopted it as the standard for running IT departments. So a company anywhere in the world that wants a new field in its CRM today runs into a process written for a British government agency.
The inheritance shaped IT departments into something specific: compliance functions. Their job is to manage downside risk: don’t lose data, don’t go down.
The form you were handed is the product of what Crozier called the bureaucratic vicious circle.2 Rules are introduced to protect people from arbitrary demands, which is exactly what an IT department needs when every business unit wants something by Friday. But the rules can’t cover every case. So the cases they don’t cover become the department’s power. And the frustrated business units respond by demanding more rules, which the department writes, and which protect it further. The form asks questions that don’t apply to your case because it was written for the last case that went wrong, and the one before that.
If you think about it, what organisations call “IT” is really two functions sharing a budget, a reporting line, and a name. One manages downside risk: keep the systems running and pass the audit. The other is supposed to pursue upside potential: co-design AI-enabled business processes. The first rewards stability and keeping costs down, the second needs investment and some tolerance for failure. Both report to the same person, who knows which of the two will get them a phone call in the middle of the night.
In operational terms, a modern company is a set of databases representing the states its processes can be in. The ERP schema defines what transactions the business can execute. Change a field or add a state, and you change what the company can do. By managing these core databases, the IT department maintains the organisation’s working model of itself.
AI in these systems acts on them: it reads states and makes decisions that change what the next state will be. So it matters which mandate gets to respond: under the first, AI is an infrastructure problem to contain, under the second, a capability to co-design.
IT also does a third kind of work that neither mandate owns. In Graeber’s terms it’s duct taping, patching faults that ought not to exist, like the script that reconciles two systems nobody was allowed to merge. Agents make that kind of patch cheap enough for any business unit to build its own, and IT inherits each one the first time it breaks.
Compliance Wins the Budget
When both functions share a budget, the compliance mandate wins, because its failures are visible and its metrics are clear.
An outage produces an incident report within the hour. Meanwhile, an AI-enabled process redesign waits unstarted in someone’s backlog, and nobody writes an incident report about that. The workflow it would have changed runs as it did three years ago, and the CFO reviewing the IT budget sees what was spent, not what was never earned.
Credit and blame are also uneven. Nobody has ever thanked IT for the email working that morning. When it doesn’t, the blame is immediate and personal.
Co-creation makes this worse. When IT helps with an AI-enabled process redesign that succeeds, the business unit takes the credit. When it fails, IT owns the failure. It takes no lack of ambition to see that co-creation adds blame and no credit, only one post-mortem.
Nobody outside the engineering team hears about the integration failures that didn’t happen, because failures that didn’t happen make for a very short status report.
On the books, the people who prevent them are a cost in the overhead line. Their work is knowing which systems connect to which decisions, and which single points of failure aren’t on any org chart, possibly including themselves. That is co-creation work, and much of the rest depends on it.
Cost-centre accounting was designed to make costs visible, and it does that very well. Prevention it can’t see at all. So when the next cost-reduction exercise comes round, their positions are among the ones that could be eliminated to meet the target. The savings are in the next quarter’s report. The loss comes later, when a project needs knowledge nobody left on staff has, and that knowledge is then bought back by the day from a consultancy.
An IT department has a backlog the business side has never fully seen: platform upgrades deferred year after year, and “temporary” integration layers that now carry core processes.
So when the business side brings IT an AI initiative, IT doesn’t see a greenfield opportunity. It sees another diversion that will push the platform migration back another quarter, and it knows exactly who will be held accountable for that migration when the legacy system finally breaks.
The business side experiences this as obstruction, and from where they stand, it is. But IT is dealing with the consequences of commitments the business itself demanded and then deprioritised, and is now asked, once again, to defer its own recovery plan to take on more.
Asking IT for a Yes
IT operates on annual budget cycles. A project that starts mid-year with no budget allocation competes with work that’s already committed and already behind schedule. Framing an AI initiative as an “innovation opportunity” signals to IT that the requester hasn’t understood the constraints, or has just come back from a conference. Framing it as an extension of work already on the roadmap gives IT a category it can approve within its existing governance.
IT needs defined scope: “we need the CRM to accept a new field that captures AI-generated lead scores, with these access controls, by this date.” It can feel petty from the business side, but specificity is how IT protects itself from scope creep.
IT needs the business to own the process change. When the workflow changes, someone on the business side has to define the new process and answer for the outcomes. When that owner doesn’t exist, IT is left holding responsibility for a business change it didn’t design and can’t control.
And IT needs the attribution to change. If the quarterly review credits sales for the AI-assisted pipeline improvement but doesn’t mention IT’s contribution, the incentive structure hasn’t changed. IT has taken on more work, and the budget line still treats it as overhead.
When a business case for AI-enabled process redesign is evaluated as an IT expense, the IT budget can’t carry it. The cost of the initiative is a line item that somebody has to defend every year. The cost of not doing it has no budget code, so nobody ever has to defend that.
Not every AI initiative requires IT’s involvement. A marketing team testing AI-generated copy on non-production data isn’t creating integration risk, only more copy. Treating every AI experiment as an enterprise integration project guarantees that nothing moves until the queue clears.
The test is whether the work touches the core systems: the databases, integrations, and workflow engines that define what the company can do. When it does, IT’s involvement is the only way to avoid creating integration debt that IT will be asked to clean up without having designed for it. When it doesn’t, the business has legitimate autonomy to move at its own speed.
Shadow IT exists because the queue is longer than the business can wait. It becomes dangerous when it touches production data or bypasses security controls that exist for reasons the business side hasn’t been briefed on. The difference between productive autonomy and damaging shadow IT is whether the experiment can be abandoned without consequence if it doesn’t work.
Internal apps built with coding assistants can fail that test. An app put together in an afternoon looks easy to abandon, and for the first few weeks it is. Then a team starts running its month-end on it, and nobody switches it off because nobody is sure what still depends on it. That kind of “temporary” layer may well have started its career the same way. Every internal app, however it was built, needs a named owner and a date by which it is either adopted properly or retired.
Under the forms, IT’s real work is knowing which systems connect to which decisions, and which “temporary” layer the orders run through. An agent can read the integration code and draw that map faster than anyone, and the map shows where the tape is. Taking it off is the platform upgrade that keeps being deferred.
Checklist
- Does the initiative touch production data, integrations or workflow engines, or does it run on exported data you could walk away from?
- Will it create dependencies IT has to support without having designed for them?
- Is the request framed in terms IT can approve, such as risk reduction, compliance or work already on the roadmap, with a defined scope, a named business owner and shared credit?
- What does your request push back in IT’s backlog?
- Who has quietly prevented integration failures in your organisation, and is their role counted as overhead?
- Which patches have business units built with agents or coding assistants, and who does IT call when one breaks?