To the untrained eye, it might be hard to see, but this is a pinch point. The ground narrows here, and every deer moving through this stretch of woods has to come through one spot. It slows them down, and a slow deer in a known spot is exactly what a hunter wants.
Your delivery pipeline has one too. For a hunter it's the best seat in the woods. For a business it's where the work stops and the business slows down.
A lot of engineering teams put AI on one stretch of the route: writing the code. Every developer was given AI tools to go faster. Review, testing, and release stayed the same width they always were, so the extra work arrives at the narrow spot sooner and waits there longer.
That's what the posts in your feed are describing. "AI isn't making us ship faster." "AI is creating more work." Both are true, and both come from the same shape: one very fast stretch inside a route that didn't change.
I wrote about the general version of this last month in Your Team Got Faster. Your Business Didn't. This is where it sits in a delivery pipeline today.
How to find yours
Scout it the way you'd scout the woods. Follow the tracks.
Pick one change that shipped last month and trace it from the ticket to production. Write down every place it sat waiting: for a reviewer, for a test environment, for a sign-off, for a release window. Add up the waiting and compare it to the time someone spent working on it. On most teams the waiting wins by a lot, and most of it is in one or two spots.
Those spots are your pinch points, and if you're not measuring wait time, you won't see them. Work time shows up on every dashboard. Wait time usually shows up nowhere.
How to widen it
Once you know where it is, the fix depends on the spot.
- Review. Smaller changes, so a reviewer can finish one in a sitting. Automated checks that run before a person ever looks, so human attention goes to the judgment calls. Review effort matched to risk, so a copy fix and a payments change don't wait in the same line.
- Testing. Tests that run on every change without anyone asking, against an environment that's always ready.
- Release. Deploys that are routine, small, and easy to undo, so shipping isn't an event that waits for a window.
Some of that is tooling and some of it is just deciding how the work should move. Do the deciding first. Automating a bad route makes the work arrive at the pinch point faster.
There's always a next one
Clear a pinch point and the work speeds up until it hits the next narrow spot. Widen review and you may find release was waiting behind it the whole time. That's normal. There is always a narrowest spot in any flow, and the job is knowing where it is and keeping the work moving through it.
That job belongs to whoever owns the whole route, not any one stretch of it. When nobody owns it, the team gets faster at their own piece and the business doesn't feel it.
If you're seeing faster code and the same release dates, I'm glad to walk the route with you and find where the work is waiting.
Where does work sit the longest in your shop?