By Reginal Campbell · October 22, 2026 · 6-minute read
Accountability Without Authority Is Not Delegation
I hate project management when it means being held responsible for decisions someone else has the authority to make but leaves unanswered.
Keep the team productive. Show progress. Explain the delay. But the decision that would let the work proceed remains above you, unresolved.
On a large transformation program, I led the team running the infrastructure selection track. We worked through ratings, reviews, and a final selection. We had just started work on the chosen infrastructure when we learned it was not authorized for use on the program. Without that authorization, the track could not proceed on the selected infrastructure.
Program leadership knew the selection had failed. No one had decided what to tell the client.
That decision, and how to proceed, belonged to program leadership. No one authorized disclosure. My team had no standing to make that call ourselves. Meanwhile, we were pressed to show value on a track we knew could not proceed.
For months.
The problem was never formally logged. I own my part in that. I kept the team together and kept pushing for a resolution, but I let the disclosure decision remain an ongoing conversation instead of a documented issue with an owner, a decision date, and the consequences of waiting.
The reporting did not make those months of inaction visible.
We eventually told the client and moved forward with a solution we knew had serious limitations and would not scale. I do not have a defensible number for what the delay cost in money or schedule. The cost I can name is the one I watched: a capable team with its hands tied for months, followed by a compromised solution.
A decision no one will own does not stay neutral. The program pays for the wait.
Authority retained is responsibility retained
I have seen versions of that pattern across other programs.
A program begins with a commitment, a budget, and a date. Then reality challenges the plan. Requirements are contested. Two business units want incompatible things. A technical constraint invalidates a core assumption. Each creates a decision. Some belong to the delivery lead. Others require authority that sits elsewhere.
That is not a flaw. A project manager should not have to control every business priority, funding commitment, or client relationship to lead delivery. But the people who retain those decisions have to make them.
Delegation means giving someone authority within a defined scope. It does not mean assigning them an outcome while the decisions that govern it sit unanswered above them. If leadership retains a decision, it retains responsibility for making it.
The schedule is the receipt
A program is not just a sequence of tasks. It is a sequence of commitments that depend on decisions being made in time.
An unanswered decision can make a schedule slip look like slow execution. The team carries the cost of a choice nobody made. The schedule is the receipt.
Milestones show whether work is moving. They do not show which decisions are holding it up. That takes a different set of questions:
- When was the decision raised?
- Who has authority to make it?
- When does the program need an answer?
- What happens if that date passes?
Answered together, those questions become a decision record. Here is what one should have looked like on my program. It is illustrative, written in hindsight, not the historical record:
- Decision required: Authorize client disclosure and select a recovery path.
- Decision owner: A named program leader with authority to approve disclosure and the recovery path.
- Answer required by: A specific deadline established when the problem was discovered.
- Consequence of no decision: The infrastructure track remains blocked. The current plan cannot proceed, and waiting does not change that.
Four lines. They make the pending decision, its owner, and the cost of waiting visible. “Under discussion” no longer hides what the delay means for delivery.
A green dashboard cannot make the work viable
A project manager can document that two priorities need the same people. The document does not make them compatible. They can show that a commitment no longer fits the available time or capacity. The report does not authorize a change in scope, funding, staffing, or expectations.
Someone has to choose.
That is where reassuring reporting becomes dangerous. If a stalled decision does not affect reported status, the dashboard can show progress while concealing the condition that makes the plan unworkable. The problem is not the color. It is what leadership permits the color to leave out.
When bad news is treated as a reporting failure rather than a decision requirement, delivery leaders face pressure to make the status easier to accept. That does not remove the constraint. It removes it from view.
Delivery leaders own their share
None of this excuses weak delivery leadership. I have watched project managers hold bad news a reporting cycle too long, hoping the next sprint would resolve it. I have seen workarounds accumulate until the underlying problem was hard for decision-makers to see.
The two obligations are different. Leadership owns the call. The delivery lead owns documenting and escalating the consequences of leaving it unanswered.
Raising a problem is not enough. Where a decision is needed, the escalation should name the choice, the person with authority, the date an answer is required, and what follows if no answer comes.
Bring alternatives and a recommendation when you can support them. When you cannot, say what remains unknown and what is needed to reach a defensible choice. “Bring solutions, not problems” sounds disciplined. Treated as a rule, it can teach people to withhold uncertainty until they can package it as a solution. Surfacing a material problem early, even before a recommendation is ready, is more valuable than delaying disclosure.
A documented issue would not have given me authority to tell the client. It would have made clear where the authority sat and what the program was absorbing while that authority went unused.
Resourcefulness still matters. But every workaround needs an honest account of what it does and does not solve. Keeping work moving is not the same as moving it in the right direction.
What sponsors owe their programs
Hiring someone for judgment is not enough. That judgment needs somewhere to operate.
Define which decisions the delivery lead can make. Identify who owns the rest. Establish how escalations reach those people and when an answer is needed. An escalation route that ends in indefinite discussion is not a functioning decision process.
Sponsors also owe their programs an honest review. Dates, budgets, scope, and quality matter. So do the decisions that shaped them. A program can meet its original date and deliver something the business no longer needs. Another can change its date after discovering a flaw that makes the original plan unacceptable. The date alone does not tell you whether either was well led.
The review should examine what the team knew, when it surfaced the problem, what choices were available, and whether the people with authority acted while those choices still existed. If a team failed to surface a material problem, hold it accountable. If it surfaced the problem and leadership left the decision unanswered, the review should not stop at the project manager.
On that program, my team could explain the problem and press for a resolution. We could not authorize the client conversation.
Leadership kept that authority. The team carried the wait.
About the author
Reginal Campbell writes about enterprise technology, AI governance, leadership, and the systems organizations build to make consequential decisions.