The queue was the product

We spent years optimising how fast engineers could build a form. The expensive part was never the building. It was the waiting, and nobody owned that.

Ask any product team where their time goes and they will tell you about estimation, or scope, or technical debt. Reasonable answers. Mostly wrong.

Here is a thing I measured that I could not stop thinking about afterwards. A product analyst needed one extra field on an internal form. The actual work, frontend, backend and tests, was about a day and a half of engineering. The change took three weeks to reach production.

The gap is not incompetence. Every hour in it is defensible. Triage happens on Tuesdays. The sprint had already been planned. The frontend engineer who knows that surface was finishing something else. The backend contract needed a second person. Review needed a third.

Nobody was slow. The queue was slow, and a queue is not anybody's job.

What optimising the wrong thing looks like

For years the industry's answer to this has been to make the building faster. Better frameworks, better tooling, better component libraries, and now AI assistants that write the code outright.

All of that compresses the day and a half. None of it touches the nineteen days.

I find this genuinely funny in a bleak way. We have collectively invested an enormous amount in the smallest term of the equation, because it is the term that is legible. You can measure how long a build takes, you can demo a faster build, you can put a faster build in a keynote. Queue time is diffuse. It shows up as everyone being reasonably busy.

The uncomfortable version of the fix

If the queue is the cost, the fix is not to speed up the queue. It is to let the work skip it.

Which means the person who wants the change makes the change. Not "files a better ticket", makes it. That sentence is uncomfortable for engineers, and it should be, because the naive version of it is genuinely bad: unreviewed code from someone who has never operated a service, going straight to production.

So the real work is not the AI assistant. The real work is building the thing that makes it safe: typed contracts so the interface cannot drift, generated schemas so two people cannot implement different assumptions, component tests that fail loudly, micro-frontend boundaries so a mistake damages one surface instead of the application, and an engineer who still reviews every pull request.

Do all of that and the analyst ships in a day. Skip any of it and you have replaced a slow, safe process with a fast, unsafe one, which is worse than what you started with.

The part that surprised me

I expected the hard part to be the tooling. It was not. The hard part was teaching people who had never worked in a repository what a branch is, why a red pipeline means stop, and that software is something you operate rather than something you finish.

That is not a technology problem and no model release will solve it. It is teaching, and it takes months, and it is the actual bottleneck behind almost every "AI will let anyone build software" claim you will read this year.

The tools arrived. The literacy did not, and nobody is shipping a version of that.

What I would tell you to measure

If you want to find your own version of this, do not measure how long things take to build. Measure the wall-clock time from someone wanting a change to that change being live, and then subtract the engineering hours.

Whatever is left is your queue. It is almost certainly the largest number in your process, and it is almost certainly the one nobody has been asked to improve.