Your Work Is Waiting for a Decision Nobody Owns

Consider a roadmap review where the same integration appears as active again. The engineers have prepared two options. Product wants the broader scope. Architecture needs agreement on a shared interface before either option goes ahead. Someone has arranged another discussion, but nobody in that discussion has the authority to settle the trade-off.

The team picks up other work. At the next review, the delivery manager is asked for a revised estimate.

An estimate still needs an assumption about which option will be chosen. Until someone makes that commitment, asking the team to refine its forecast leaves the source of uncertainty untouched. The item has an assignee, yet the decision holding it up has no usable owner.

Decision latency is the elapsed time between a work item needing a decision and an authorized person making a usable commitment. It becomes hidden work-in-progress when ownership, evidence, or escalation rules remain unclear.

A usable commitment lets someone act. It might authorize a smaller release, reject an option, or stop the work. An agreement to discuss the issue again leaves the delivery question open.

A busy team can leave the commitment unresolved

In the integration example, starting other work is understandable. Engineers should not sit idle while leaders debate scope. But the unfinished item remains in the delivery commitment, and the next forecast must account for its unresolved choice. Activity elsewhere tells the delivery manager little about when this item will move.

There is empirical reason to examine that gap. Drury et al. (2012) identified decision obstacles in agile teams, including unwillingness to commit, conflicting priorities, and missing ownership or authority. Reported consequences included delayed work accumulating in backlogs and weaker strategic focus. Their qualitative study describes a recognizable problem; it does not tell us how much delivery time a decision consumes.

That distinction matters when a roadmap slips. Kula et al. (2022) examined schedule deviation in a large software organization and found a broader set of interacting factors. Dependencies and team familiarity helped explain variation, while practitioners also identified requirements refinement, organizational alignment, and politics as influential. The study did not isolate product or architecture decision waits.

My reading is that a delayed decision deserves investigation before another round of estimation. It should not become the default explanation for every late delivery. An unresolved dependency or missing technical evidence may explain why nobody is ready to commit. The diagnostic needs to distinguish those conditions from a request that has simply been passed around.

Give the owner a decision they can actually make

Putting a name on the integration ticket would be a weak repair if that person still needed permission from everyone else. Ownership needs a defined commitment and enough authority to make it. Otherwise, the named owner becomes the person responsible for chasing replies.

For the hypothetical integration, separate the questions. Product might have authority to narrow the release scope. Architecture might retain authority over changes to the shared interface. If those choices conflict, identify who settles that conflict and what information they require. Asking a committee to "approve the integration" hides these different responsibilities inside one vague request.

Delegating everything to the team would create another problem. A local choice about a shared interface affects work elsewhere. Compliance obligations or difficult-to-reverse changes may also justify review beyond the team.

Moe et al. (2021) found a mixture of control and autonomy in two large telecom software organizations. Teams were partly self-managing, with centralized decisions and mandatory processes alongside dialogue and community-based alignment. One case involved teams and experts in alignment decisions through a community. These cases give no basis for assuming that maximum autonomy produces the best delivery outcome.

I would use the consequences of a decision to set its boundary. A reversible choice within an agreed interface could stay with the team. A change that forces several teams to migrate needs wider agreement. In either case, people should know what they may decide and where an exception goes. The governance requirement remains visible instead of emerging after implementation has started.

Trace one wait before changing the operating model

Start with a single delayed item that still matters to a delivery commitment. Salin (2025) proposes representing software decision processes as value streams. That provides a useful way to examine how a request reaches a commitment. It does not establish that drawing a map improves lead time. The trace below is a diagnostic experiment, rather than a proven treatment.

Record the trigger first. What happened that made a decision necessary, and when? In the integration example, it might be the discovery that the proposed scope requires a shared interface change. Starting the clock at the eventual review meeting would omit the earlier wait.

Then write the commitment in a sentence someone could accept or reject. "Review architecture" is an activity. "Approve this interface change for the smaller release" names a choice. Record the authorized owner beside it, including anything outside that person's mandate.

Next, identify the evidence needed to make that choice and who holds it. An unanswered compatibility question is a real dependency. A request to repeat information already available deserves a different response. Keep the distinction visible so that pressure for speed does not turn necessary analysis into a supposed process failure.

Finally, reconstruct the handoffs and elapsed wait. Note where the request moved, whether anyone returned it for clarification, and what activates escalation. "We will chase it" leaves both timing and authority unresolved. Specify when an unanswered request moves to someone who can resolve the conflict, while preserving required safety and compliance checks.

The trace should fit beside the work item. A separate reporting system would add maintenance before you know whether the diagnosis is useful.

Change one boundary and watch what happens next

Use the trace to choose a small change. If nobody can settle the scope conflict, assign that authority explicitly. If required evidence arrives through serial requests, try gathering it in parallel. Where the same low-risk choice repeatedly waits for approval, test agreed guardrails that let the team decide within a defined limit.

Observe several comparable decisions before keeping the change. Look at the wait alongside subsequent rework and the affected items' end-to-end delivery time. A quicker approval followed by a costly reversal gives a different answer from a quicker approval that lets work finish safely. Other dependencies may change during the experiment, so a shorter cycle time alone does not establish causation.

Avoid ranking people by decision speed. That would give them a reason to commit before the evidence is adequate or delay acknowledging that a decision is needed. The useful unit of investigation is the waiting work and the conditions around it.

At the next delivery review, choose one stalled commitment. Write down the exact decision that would let it move, then ask the proposed owner whether they can make it within their mandate. If they cannot, resolve where that authority sits before requesting another delivery date.

References

Drury, M., Conboy, K., & Power, K. (2012). Obstacles to decision making in agile software development teams. Journal of Systems and Software, 85(6), 1239–1254. https://doi.org/10.1016/j.jss.2012.01.058

Kula, E., Greuter, E., van Deursen, A., & Gousios, G. (2022). Factors affecting on-time delivery in large-scale agile software development. IEEE Transactions on Software Engineering, 48(9), 3573–3592. https://doi.org/10.1109/TSE.2021.3101192

Moe, N. B., Šmite, D., Paasivaara, M., & Lassenius, C. (2021). Finding the sweet spot for organizational control and team autonomy in large-scale agile software development. Empirical Software Engineering, 26(5). https://doi.org/10.1007/s10664-021-09967-3

Salin, H. (2025). Building a decision landscape model for software development: From empirical insights to formal theory. In Proceedings of the 20th International Conference on Software Technologies (pp. 15–26). SCITEPRESS - Science and Technology Publications. https://doi.org/10.5220/0013457300003964

AI disclosure: AI was used to help create this article. Responsibility for the published content remains with Nico Thümler.