IT as the Platform Team, Not the Ticket Queue

For thirty years, wanting software built meant getting in line behind IT. When the people with the problem can finally build the solution themselves, the question is no longer how fast IT clears the queue — it's what IT becomes when the queue disappears.

Somewhere in a mid-sized company right now, a finance analyst is filling out an intake form. She needs a small thing: a workflow that pulls three reports on the first of the month, reconciles them against a ledger, flags the discrepancies, and emails the exceptions to her team. She has described this to IT twice already, and she is describing it a third time in a ticketing system because that is the only door into the department that can build it. The ticket will be triaged, sized, prioritized against forty others, and placed in a backlog where it waits behind a payroll integration and a security patch, both of which matter more than her reconciliation. In four months, if nothing jumps the line, an engineer who has never done month-end close will build a version of what she asked for, from a document written by someone translating her need into a language she does not speak. It will be almost right, and she will file another ticket to fix the parts that are not.

Nobody in this story is doing anything wrong. The analyst is following the only process available to her, the engineer is doing careful work against an ambiguous spec, and IT is rationing a scarce resource the only way it knows how. And yet the whole arrangement is quietly absurd, because the person who understands the problem completely has no way to build the solution, and the person who can build it does not understand the problem. The company has organized itself so that its software gets made at the exact point of maximum distance between the need and the capability. For decades this was simply the cost of doing business with computers. It is not anymore, and the organizations that notice first are going to look very different from the ones that don't.

The queue was a rationing system for a scarcity that is ending

It helps to be honest about what the ticket queue actually is. It is not a workflow or a best practice or a philosophy of service; it is a rationing mechanism, and it exists because the ability to build software was, for the entire history of the enterprise, concentrated in a small number of expensive and perpetually oversubscribed people. When a capability is that scarce, you ration it, and a queue is how. The intake form, the triage meeting, the prioritization ritual, the backlog that never empties: all of it is machinery built around the premise that building is hard and builders are few, so every business unit that wants something built must route its desire through a central bottleneck that decides whose turn is next.

That premise held because it was true. Turning a business need into working software required someone who could read requirements, model data, wire up integrations, handle the edge cases, and ship something that would not fall over — and those people were rare, so they lived in IT, and IT became the place where every ambition in the company went to wait. The waiting bred a whole culture. Business units learned to hoard their requests into big annual asks, and IT learned to say no early and often, because a backlog that grows faster than it drains has to be defended. The relationship curdled into the one every enterprise knows: the business thinks IT is slow and territorial, IT thinks the business is impatient and naive, and both are reacting rationally to a scarcity that neither created.

What almost no one has internalized yet is that the scarcity is what is actually ending. When a business user can describe a workflow in plain language and have a system of Autonomous AI Workers actually build and run it — reading the inputs, reasoning about the exceptions, calling the systems that hold the data through the Model Context Protocol, stopping for a human at the decision that genuinely needs one — the analyst who understands month-end close no longer has to file a ticket and wait four months for a stranger to approximate her intent. She builds the thing herself, in an afternoon, because the distance between knowing the problem and expressing the solution has collapsed to almost nothing. And the moment it collapses, the queue loses its reason to exist, because you do not need a rationing system for a resource that is no longer scarce.

When building gets distributed, governing gets centralized

The reflexive fear, when you describe this to anyone who has run an IT organization, is chaos, and the fear is not stupid. If everyone can build, then everyone will build, and what they build will touch customer data, hit production systems, make decisions with money attached, and run unsupervised at three in the morning. The analyst who can spin up an autonomous workflow in an afternoon can also, in that same afternoon, wire a credential into a process that emails sensitive records to the wrong place, or grant an agent access to a database it should never have touched. The nightmare version of self-service is a thousand ungoverned automations metastasizing across the company, each one a small liability its creator does not have the training to see, and it is precisely the risk that Gartner points to when it predicts that over forty percent of agentic AI projects will be canceled by the end of 2027, naming inadequate risk controls alongside unclear value as the thing that kills them.

But notice what that fear is actually telling you. It is not an argument for keeping the queue; it is an argument for building the substrate underneath the self-service — and that substrate is the new job. Someone has to decide which systems an agent is allowed to reach and which are off limits, own the LLM Gateway through which every model call flows so that cost and data exposure stay bounded rather than sprayed across a hundred personal accounts, define where Human-in-the-Loop is mandatory so that a workflow touching money or compliance cannot ship without a gate, and hold the shared Enterprise Knowledge that keeps a hundred autonomously-built workflows consistent with each other and with the truth. None of that is building the finance analyst's reconciliation for her. All of it is building the ground she safely stands on while she builds it herself.

That is the inversion, and it is genuinely a promotion. In the queue model, IT spends its scarcest talent translating other people's requirements into other people's software — high-effort, low-leverage work, done at a permanent information disadvantage, satisfying exactly one requester per unit of effort. In the platform model, IT spends that same talent defining the guardrails, access boundaries, observability, and policies inside which the entire company can build safely — low-volume, extraordinarily high-leverage work, where a single well-designed control governs a thousand workflows the platform team never has to see. This is the shape of the autonomous enterprise as it actually arrives inside a company: not a world where IT is disintermediated, but one where IT stops being the factory and becomes the government — the difference between building every road by hand and setting the traffic laws, paving the surface everyone drives on, and making sure nobody drives into a river. The second job is smaller in volume and vastly larger in consequence, and it is the one worth having.

The hard part is cultural, not technical

The technology to do this is not the obstacle, and anyone who has watched an enterprise adopt anything will already suspect where the real resistance lives. The platforms that let business users build governed autonomous workflows exist, and the guardrails and gateways and human-in-the-loop controls are configurable today. What does not yet exist, in most organizations, is the willingness of an IT function to give up the identity it has held for a generation. Being the queue is disempowering in a hundred daily ways, but it is also a form of power — the power of the gatekeeper, the one whose no is final, the one every ambition in the company must come to and wait. Trading that for the role of platform steward means giving up the gate, and the people who have spent careers being the gate do not always experience that as the promotion it is. It can feel like a loss of control, right up until you realize that governing the substrate is far more control than approving tickets ever was.

There is a parallel loss of comfort on the business side, and it is just as real. For years, the queue let business units outsource not just the building but the responsibility: you filed a ticket, and if the thing was late or wrong, that was IT's fault, so the queue was a place to send your problem and your blame at once. Self-service ends that. When the finance analyst builds her own workflow, she owns it — its correctness, its consequences, its maintenance — in a way she never owned the ticket she filed. Some people want that ownership badly and have strained against the queue for years to get it, while others have quietly preferred a world where the software was someone else's job to get right, and for them real building power lands as a burden dressed up as a gift. The transition asks both sides to grow up at once: IT to trade the authority of the gatekeeper for the leverage of the steward, and the business to trade the comfort of the complaint for the responsibility of the builder. Neither trade is technical, and both are harder than any integration.

So the mental model worth leaving with is not "IT gets faster" or "IT does less," because both miss the actual change. The right frame is that a company has two entirely different ways to think about the ability to build software: as a scarce service to be rationed through a queue, or as an abundant capability to be governed through a platform. For thirty years only the first was available, so the queue looked like the nature of things rather than the artifact of a constraint. The constraint is lifting, and the companies that thrive will be the ones that let their IT function stop guarding the scarce thing and start governing the abundant one — not because it clears the backlog faster, but because it puts the building where it always belonged, in the hands of the people with the problem, on ground that someone finally made safe to build on.