Ticket Ops
also called Ticket-Driven Operations
An operating model where teams obtain infrastructure and change by requesting it from another team, making that team a queue.
Worth naming as an antipattern because it is the default state most platform efforts are trying to escape, and because it is rarely anyone's decision — it accretes.
Its cost is dominated by queueing rather than by work. A request that takes twenty minutes to fulfil routinely takes four days to be fulfilled, and the difference is the queue. That delay then changes behaviour in ways that are worse than the delay: teams batch requests to reduce round trips, which makes each change larger and riskier; they over-provision because asking again is expensive; and they route around the process entirely where they can, which is how shadow infrastructure appears.
The seductive failure is optimising the queue rather than eliminating it — better forms, tighter service levels, more staff. This improves the experience of a model that does not scale, and it consumes exactly the engineering capacity that would have built the automation.
The diagnostic: what fraction of tickets are requests the requester could safely have fulfilled themselves inside a guardrail? In most organisations that fraction is the large majority, and it is the platform backlog written out in full.