How do you run the exception queue for an ingest gate when three engineers serve 400 developers?

## Frame the problem correctly first The naive framing is *how do three people review enough requests*. That framing loses, because the arithmetic never works and no amount of process fixes it. The correct framing is: **an ingest gate's dominant failure mode is bypass, not bad approval.** A gate that is slow does not make teams wait; it makes them vendor the code into the repository, copy files by hand, add a second source, build in an unmanaged environment, or ship a container image with dependencies baked in from somewhere else. Every one of those converts a visible, controlled path into an invisible, uncontrolled one — and it happens quietly, so you keep believing the gate works. Every design decision below follows from that. ## Push the volume away from humans Most requests are not interesting. Define classes that resolve without a person: - A newer version of a package already in the feed, from the same publishing identity, with no anomalous change in the release. - A transitive dependency that is itself already ingested. - Anything covered by an existing standing decision for that package. What should remain for a human is genuinely small: a package the organisation has never used, a release that tripped an anomaly check, or a request to skip a hold-back window. If the human queue is not small, the automation rules are wrong, and that is where to spend the effort — not on hiring reviewers. ## Put the decision where the risk is Three platform engineers cannot hold context on 400 developers' problems, and they do not carry the consequences of a bad dependency choice. The service-owning team does. So delegate the approval to them, with the platform team owning three things instead: 1. **The policy** — what classes exist, what evidence each requires, what is never allowed. 2. **The evidence** — the approver sees the diff, the publisher, the age of the release and the existing inventory without going and finding it. An approver with no evidence in front of them rubber-stamps by definition. 3. **The record** — who approved what, when, why, and until when. This is a deliberate trade: you accept more approvers of variable rigour in exchange for a queue that actually moves and decisions made by people with context. The centralised alternative is more rigorous per decision and worse in aggregate, because it is the one that gets bypassed. ## Define the timeout, not just the SLA Publishing a target response time is easy. The question that separates a real design from a slide is **what happens when nobody responds** — the approver is on holiday, it is a Friday night, the request is the only thing between an on-call engineer and a fix. There is no universally right answer, but there is a required one: it must be **decided in advance and cheap to invoke**. A common shape is a break-glass path any senior engineer can take, which grants the exception immediately, notifies loudly, and creates a mandatory review item. Loud and reviewed beats a locked door, because the locked door is what teaches people to stop using the door. What you must not ship is an approval path with a single named human and no alternative. That design fails every holiday. ## Time-box everything An exception with no expiry is a policy change made by whoever was quickest to ask. Every grant carries an expiry and a reason, and when it lapses the state returns to the default — the package must be properly ingested, or the exception re-argued. This matters most for the hold-back-window skip: it should be an event with a lifetime, not a permanent property of that package. The corollary is that expiries need follow-through. An expiry nobody enforces is worse than none, because it creates a false record of control. ## Measure the right things Gates get justified with block counts, which measure activity, not safety. Better instruments: - **Queue latency**, p50 and p95. This is the leading indicator of bypass. - **Auto-approval share.** Falling share means humans are absorbing volume the rules should handle. - **Exceptions granted, and how many expired without follow-up.** - **Detected bypasses** — dependencies in shipped artifacts that never appeared in the feed, or build runners talking to public indexes. Finding these is a sign your telemetry works, not that your teams are hostile. ## What to say about the three-person team Be explicit that the team's job is to build and tune the path, not to sit in it. The moment their throughput is the constraint on 400 engineers, the design has already failed, and adding a fourth engineer buys a few months at most.