Why accountability breaks down, even when everyone has a job description.

A customer’s problem passes through three departments. Each team completes its part. Each manager can explain why the remaining issue belongs somewhere else.

The customer has accidentally purchased a guided tour of the organisation chart.

If your business has clear roles but recurring gaps in delivery, another reminder to “take ownership” may achieve very little. This article examines the relationship between responsibility, authority and outcomes, and what DeaconOps would investigate before rewriting everybody’s job description.

1. How everyone can do their job while the outcome fails

Imagine a relay team where each runner’s target is to reach the end of their section. Nobody is measured on whether the next runner receives the baton.

There will be some excellent individual times and a surprising amount of equipment on the floor.

Departmental responsibilities often describe activities rather than a complete customer outcome. Sales confirms the order, operations schedules it and customer service answers enquiries. Problems emerge when nobody is accountable for resolving the exceptions between those stages.

I’d map ownership around the outcome as well as the individual tasks. Who notices that delivery has stalled? Who can coordinate a response? Who confirms the customer’s problem is actually resolved?

A task can be completed correctly while the wider obligation remains unfinished.

2. Separate responsibility, authority and accountability

Telling someone they own dinner is unhelpful if they cannot use the kitchen, choose the menu or buy ingredients. Accountability becomes particularly adventurous when the oven belongs to another department.

The same mismatch appears in management roles.

Responsibility concerns the work someone undertakes. Authority concerns the decisions and resources they can control. Accountability concerns being answerable for an agreed outcome. Organisations use these terms differently, so agree their meaning explicitly.

When a manager is answerable for a result but cannot influence its main dependencies, the arrangement needs attention. That may require clearer decision rights, an escalation route or a different allocation of ownership.

It does not necessarily mean giving one person unrestricted control. The requirement is a workable relationship between what they must achieve and what they can influence.

3. Find decisions that nobody can clearly make

A routine exception arrives. Four managers offer views. Everyone is consulted, nobody decides and the customer waits while the organisation enjoys a rich exchange of perspectives.

Participation and decision authority are different things.

Bain’s RAPID framework is useful here because it distinguishes recommending, providing input, agreeing, deciding and performing. Those roles prevent consultation from becoming an indefinite search for unanimous enthusiasm.

A small business does not need to attach a framework to every minor choice. Start with recurring decisions that delay delivery or keep returning to senior management.

For each, establish who decides, whose input is essential, what constraints apply and who carries the decision into practice. A recorded decision without an implementation owner can still leave the original work untouched.

4. Examine where ownership disappears between teams

“I’ve emailed them” is a description of an action. It is not confirmation that the issue has reached somebody equipped to resolve it.

Otherwise, a delivery company could classify parcels as delivered when the driver waves in the general direction of the street.

Transfers need a shared understanding of what is being passed, when it is accepted and what happens if it is incomplete. Ambiguous interfaces create bouncing work and defensive reporting.

I’d examine delayed cases across departmental boundaries and compare the sending team’s completion criteria with the receiving team’s acceptance criteria. Differences often explain why both believe the other has ownership.

Our article on business handovers develops this practical side of accountability.

5. Use responsibility charts to support a conversation

A RACI chart can clarify a confused situation. It can also become a colourful spreadsheet that everyone agrees with until the first difficult decision.

The letters do not enforce the arrangement.

RACI distinguishes people doing the work, those accountable, those consulted and those informed. Its usefulness depends on whether the chosen roles reflect actual authority, availability and dependencies.

Use a real recurring problem to test the chart. If the nominated accountable person needs permission from three others before acting, the document may conceal the ambiguity rather than resolve it.

I’d also check whether responsibility is realistic alongside existing commitments. Naming someone who has no usable capacity is not an ownership solution. It is a future explanation for delay.

6. Make escalation a defined operational process

Some businesses treat escalation like a smoke alarm: important, noisy and occasionally triggered by toast.

When everything receives the same urgent treatment, genuinely consequential issues compete with routine requests.

An effective escalation process specifies the trigger, recipient, information required and expected response. Thresholds might concern customer impact, time, uncertainty, risk or a decision outside delegated authority.

Escalation should transfer a decision or secure support, not simply copy more people into the conversation. Define who continues managing the work while that response is awaited.

Keep exceptions visible and review repeated escalations. If the same decision needs senior intervention every week, it may belong within an improved delegation boundary rather than an increasingly busy escalation log.

7. Support ownership with evidence and workable conditions

A manager cannot own performance they cannot see. Nor can a team resolve an issue simply because the word “accountability” appears in bold on a presentation.

They need usable information and a practical route to act.

Agree the outcome, available measures, review rhythm and response when performance moves outside expectations. Include the quality and customer consequences of decisions, not only the number of items passed onwards.

This makes accountability more than retrospective explanation. It becomes an operating arrangement that helps people recognise a problem and respond while there is still time.

At DeaconOps, I’d examine the decisions, handovers and measures together. Altering one without the others can preserve the same gaps under a new job title.

8. Test whether ownership works in practice

Choose one recurring exception and follow it through. Ask the people involved who decides, who does what next and who confirms completion.

If you receive several incompatible answers, you already have something concrete to investigate.

A useful improvement makes that journey more reliable without centralising every choice or introducing excessive approval. Check decision time, repeated escalations, returned work and unresolved customer issues before and after the change.

DeaconOps’s Improvement Projects can help redesign these arrangements and put them into practice. Where the underlying problem is unclear, an Operational Diagnostic can establish where ownership is failing.

Start a conversation if responsibility looks clear on paper but work still falls between teams.

Questions about operational accountability

Do we need one person accountable for every task?

The important point is clear ownership at the level of the outcome or decision. Adding administrative owners to every small action can create unnecessary complexity.

Does clearer accountability remove the need for collaboration?

No. Cross-functional work still needs collaboration. Clear roles explain how contributions become a decision and a completed outcome.

Can a job description solve an ownership problem?

It can help, but it must align with decision authority, information, capacity and the way teams work together. The document alone cannot supply those conditions.

---

About the author

Dean Cain is the founder of DeaconOps, with more than 15 years’ experience across operational delivery, leadership and regulated environments. Read about the DeaconOps approach.