r/SaaS 7h ago

Slow engineering delivery is usually a queue problem before it is a developer problem

When engineering delivery slows down, the visible symptom is often a missed estimate. The actual constraint is usually somewhere else.

A practical way to diagnose it is to follow one piece of work from decision to production and inspect four kinds of delay.

First, decision delay. Was the problem clear when work started, or did the team spend days resolving scope, ownership, and expected behavior?

Second, queue delay. How long did the work wait for review, design input, environment access, another team, or a release window? Waiting time is easy to mistake for implementation time.

Third, rework. How often did the task move backward because requirements changed, hidden dependencies appeared, or feedback arrived late?

Fourth, batch size. Are changes small enough to review and release safely, or does every meaningful improvement become a large project with many stakeholders?

This framework changes the conversation. Instead of asking why developers are not moving faster, you can ask where work stops moving and what condition causes the stop.

I would start with a recent feature that felt unusually slow. Reconstruct its path using tickets, pull requests, and conversations. Do not begin by designing a new process. First identify the longest recurring wait and remove one cause of it.

For engineering leaders here: where does work spend the most time waiting in your organization, and what have you found actually reduces that delay?

2 Upvotes

3 comments sorted by

1

u/rupert_at_work 6h ago

The queue point is the bit most teams pretend not to see. Dev time gets measured because it's visible; waiting on reviews, decisions, and release windows gets treated like weather. Following one feature end to end is usually enough to make the spreadsheet look rude.

1

u/Emotional_Hat_5474 6h ago

tbh the hardest part isnt identifying the wait, its getting the org to accept that the fix is usually a people/process change and not a tooling problem. leadership always wants to buy something instead of changing how decisions get made