When delivery feels slow, the instinct is usually to look at execution. Are engineers shipping fast enough? Are PRs taking too long? Are releases getting stuck?

But if you trace the work end to end, the slow parts are often somewhere else. Most of the friction sits in the gaps between the steps, not in the steps themselves. Below is a rough field guide to where it tends to show up.

1. Vague tickets

Tickets that are enough to start, but not enough to finish. Descriptions are thin, acceptance criteria are incomplete, edge cases are missing, and it's unclear who owns which decisions.

Engineers pick up the work and then ask questions, wait, make assumptions, adjust later. The work moves, but with interruptions. From the outside, it looks like slow delivery. From the inside, it's ongoing clarification.

2. Design that's still evolving

Implementation starts while design is still being worked out. Partially ready, details finalized along the way.

Layouts change mid-implementation, flows get adjusted, components are reworked. Even when iteration is intended, the target keeps moving during execution.

3. Decisions that don't get captured

A lot of decisions happen in chats or quick calls. They don't make it back to the ticket or any durable doc.

The next person asks again, or assumes something different. Over time, teams end up depending on whoever remembers, instead of shared context.

4. Broad alignment without clear ownership

To reduce ambiguity, teams sometimes pull in architecture reviews and larger stakeholder groups. Sometimes this helps.

Other times, many people are involved, decision ownership is unclear, and nothing gets written down. Decisions take longer or stay partially unresolved.

5. Code that needs updating mid-flight

Logic shifts, scope expands a little, an assumption turns out to be wrong. The change itself is usually small, but it pulls the engineer back into a part of the code they thought was done.

This rework rarely shows up in estimates, but it adds up.

6. PRs waiting on review

The work is technically complete, but it's not moving. And when review comments come in, they often surface gaps from earlier in the process. Design questions, edge cases, assumptions. Which means more code updates, and another round of waiting.

7. Undocumented operational steps

Even after merge, the path to production has its own friction. Infra and config changes often need their own review, and the steps for that aren't always well documented. They live with whoever has done it before.

So work pauses again. Not because deployment is inherently complex, but because no one knows where to look.

8. Scheduled release windows

Code can sit in staging for days waiting for the next scheduled deploy. Not because anything is broken, just because that's the cadence.

This one is easy to miss because it doesn't feel like friction in the moment. It feels like "that's just how we ship."

9. Priority changes mid-flight

The cross-cutting one. Priority can shift at any stage. Something more urgent comes in, the team pivots, and whatever was in flight gets paused or worse gets trashed completely.

The pattern underneath

Most of these aren't about coding. They're about decisions that weren't written down, questions that had to be asked twice, context that lives in someone's head, interruptions that pull a team out of flow.

When delivery looks slow, it's worth checking whether the team is actually executing slowly, or just working through gaps that were left earlier. A lot of the time, it's the second one. And those gaps tend to be easier to close than execution speed is to improve.

The goal isn't to move faster. It's to remove the things that are slowing teams down for reasons that aren't really about the work itself.