The Work Between Roles Is Where Delivery Goes to Die.

The most dangerous work in a project is rarely the work inside a role. Developers usually know when they are developing. Designers know when they are designing. Managers know when they are managing, or at least when they are expected to look concerned in a meeting.

The real damage usually happens between roles: after a stakeholder gives vague approval, before a Product Owner turns it into a decision, after a developer raises a dependency, before anyone names who has to remove it. That is where work becomes strangely weightless. Everyone knows about it. Everyone has touched it. Nobody owns the next move.

This is the territory of delivery problems nobody owns. It is not the dramatic failure where a vendor disappears, a budget collapses, or a launch catches fire. It is quieter than that. It is the task that stays 'almost done' for three weeks. The dependency that is 'being discussed'. The deadline that exists because someone once said a date confidently enough that everyone else became embarrassed to challenge it.

The false diagnosis

When work gets stuck between roles, teams often call it a communication problem. That sounds harmless. It also sounds fixable with another meeting, which is why it survives for so long.

Communication is rarely the missing ingredient. Most teams communicate constantly. They have standups, status meetings, email chains, chat channels, roadmap reviews, planning sessions, and enough notifications to make a healthy adult consider farming.

The problem is not that communication did not happen. The problem is that communication happened without ownership landing anywhere.

A message is not ownership. A meeting note is not a decision. A deadline no one set is just weather.

The shape of the problem

The pattern is easy to miss because everyone involved can make a reasonable case that they are doing their part. The stakeholder answered the question, but not clearly enough to build from. The Product Owner wrote the ticket, but left the hardest assumption open. The developer flagged a dependency, but did not say what decision would remove it. The manager asked for an update, but accepted a status that described activity instead of progress.

Nobody has failed loudly. That is the problem. The work has slipped into a grey zone where every role is partially involved and no role is fully accountable.

How fake progress appears

This is the stage where status updates become theatre. A task is 'with business'. A question is 'waiting for input'. A dependency is 'being discussed'. A deliverable is 'mostly ready'. Nobody is lying, exactly. They are just reporting the location of uncertainty instead of naming the person responsible for reducing it.

The team still looks busy. There are updates. There are comments. There are meetings. There may even be a dashboard with reassuring colours, because dashboards are very good at making uncertainty look organised.

But the real test is simple: did the state of the work change? If the answer is no, then the update was not progress. It was a description of where the problem is currently hiding.

If no one owns the next state change, the work is not in progress. It is parked.

The three places work disappears

1. Between request and requirement

A stakeholder asks for something. The request sounds reasonable. Everyone nods. The Product Owner captures it as a ticket. Then the team starts discovering that the request was not a requirement. It was a preference, a symptom, or a half-formed solution wearing a business hat.

This is where the first ownership gap appears. Who is responsible for turning the request into a buildable decision? Not just writing it down. Not translating it into nicer words. Actually deciding what must be true for the team to build the right thing.

2. Between dependency and owner

A dependency is raised. Another team is needed. A decision is required from finance, legal, marketing, sales, operations, or someone whose calendar looks like a crime scene. The blocker is known, but ownership remains vague.

The status becomes 'waiting for input', which is one of the most expensive phrases in delivery. Waiting is not an action. Input is not an owner. If a dependency matters, someone has to own removing it or escalating it.

3. Between deadline and commitment

A date appears. Sometimes it came from a client promise. Sometimes from a roadmap. Sometimes from leadership. Sometimes from a meeting where nobody wanted to be the difficult person, so the date survived by social pressure.

A deadline only becomes useful when it is connected to scope, capacity, and trade-off. Without those, the date is not a commitment. It is a decoration on a slide.

The stakeholder nobody is talking to

There is usually a stakeholder in this story who is not being spoken to properly. Not ignored completely. That would be easier to spot. They are being managed through fragments: a status line here, a cautious email there, a vague update in a meeting where nobody wants to open the actual problem.

This is a mistake. Stakeholders do not need theatrical confidence. They need the truth early enough to make a decision while there is still something to decide.

The longer the team protects the stakeholder from uncertainty, the more expensive the eventual conversation becomes. By the time the issue is escalated, there are fewer options, less goodwill, and more explaining to do.

The rescue question

When I see this pattern, I do not start by asking for a better roadmap. I ask a smaller question: who owns the next irreversible action?

Not who is interested. Not who was copied into the email. Not who should probably know. Who owns the action that changes the state of the work?

A useful answer sounds like this: 'Anna will confirm the scope trade-off with sales by Thursday. If sales does not respond, Mark escalates to the sponsor on Friday morning. Until then, the development task stays out of the sprint.'

A useless answer sounds like this: 'We are waiting for business feedback.' That is not a status. That is fog.

The operating discipline that fixes it

The fix is not heroic. It is a small discipline applied consistently: every unclear item must be converted into one of three things — a decision, a blocker, or a deliverable.

• A decision asks: what choice has to be made, by whom, and by when?
• A blocker asks: what is preventing movement, who can remove it, and what happens if they do not?
• A deliverable asks: what will exist at the end, who accepts it, and what does done mean?

If an item cannot be written as one of those three, it is probably not ready to be managed. It is still a conversation pretending to be work.

How to fix it this week

• Take every item reported as 'waiting', 'with business', 'under discussion', 'nearly there', or 'almost done'.
• Rewrite the status as a decision, blocker, or deliverable.
• Name one owner for the next state change, not a group and not a department.
• Add the date by which that owner will either complete the move or escalate the blocker.
• Remove any deadline that no one can connect to scope, capacity, or a trade-off.
• Tell the relevant stakeholder the real status while there is still time to choose between options.

The uncomfortable part

This kind of discipline can feel blunt at first. It removes the soft hiding places teams use when they want to be polite. It makes vague ownership visible. It exposes the difference between being informed and being accountable.

That is why it works.

Most delivery problems nobody owns are not solved by demanding more effort. They are solved by making the next owner, next decision, and next state change visible enough that the team cannot politely avoid them anymore.