The team that gets blamed is rarely the cause

When I started work at a private multi-specialty hospital, I asked the same question in every department: why are things slow? Everyone had an answer, and the answers were consistent. Discharge was slow because doctors signed late. Bills were wrong because of the billing desk. Medicines were late because of pharmacy.

Each explanation pointed to the last team involved before the patient felt the delay. Tracing the work upstream revealed a different cause in all three cases.

Three delays, three wrong explanations

Take discharge first. A patient is told they can go home, and then waits. The obvious suspect is the doctor, because the doctor's signature is the visible gate. The data showed something else. The wait sat in pharmacy and billing clearance, and that work only began after the decision to discharge had been made. The doctor was not late. Everything that followed the doctor started late.

Billing was the same shape. Invoices went out wrong, patients disputed them, and the billing desk took the blame. When I traced the billing workflow from service delivery to invoice, the errors were already in the record before billing saw it. Charges were being entered late or incompletely on the ward. The billing team was faithfully invoicing bad data.

Medication delays were pinned on pharmacy. The cause was stock gaps and slow procurement, one step behind the dispensary. Pharmacy could not dispense what had not arrived.

In all three cases the cause sat one or two steps upstream of the team that took the blame.

Why the blame lands in the wrong place

The pattern was understandable: each department could see its own work more clearly than the handoffs around it.

• A delay is felt where the work stops. That is where patients complain and where managers look, so the team standing at that point becomes the explanation.
• The step that created the problem finished hours earlier. Whoever entered an incomplete charge has moved on to the next patient long before the invoice is disputed.
• Each team sees mostly its own part. The ward does not see the invoice and billing does not see the ward, so neither can easily connect cause to effect.
• Process documents describe the intended hospital. I learned early that the place ran differently from how its documents said it did.

How I found the real causes

I had not worked in this organisation before, so I could not rely on what I already knew. I used three sources and trusted none of them alone.

1. Time on the floor. I spent time with clinical, pharmacy, administration and procurement staff, mapping how requests, handoffs and supplies moved.
2. Workshops and journey mapping. I ran sessions with physicians, nurses, pharmacy, administration and procurement, and mapped the current state of patient flow and billing across all of them, inpatient and outpatient.
3. Operational data. I combined what staff described with the data, and used the data to find where delays really occurred, which was not where people assumed.

The three sources worked together. Operational data showed where time was lost; staff observations helped explain why.

Walk the work backwards

The method I took from this is simple to state. Start where the delay is felt. Then walk the work backwards, one handoff at a time, and at each step ask what this team needed that it did not have. Keep going until you reach the first step that could have prevented the problem. Fix that step.

For discharge, the first preventable step was the moment discharge was planned. Pharmacy, billing and admin clearance now start then, and run alongside the clinical steps. For billing, it was the point of service. Charges are captured there under agreed rules, and checked automatically before the invoice is raised. For medication, orders are checked for risk before dispensing, and stock levels are visible before a medicine runs out.

None of these fixes asked the blamed team to work faster. I also chose to redesign the workflows before automating anything, because automating a broken step makes the same mistake faster.

Show the blamed team the data first

There is a human side to this. Billing and finance were wary of automation, which is reasonable for a team used to being held responsible for errors. Before proposing any change, I showed them the error data. It showed that the errors began upstream of them.

That changed the conversation. Billing could help address the source of the errors instead of defending the current process.

Department heads were a different problem. Each was protecting their own priorities. I turned the competing requests into one prioritised backlog, judged against patient and operational impact, and ran regular demos so every department could see where its request stood and why.

What changed

Process and patient wait times fell by 50%, measured at four points: discharge decision to the patient leaving, outpatient registration to seeing a clinician, prescription to dispensing, and service delivery to final invoice. Billing errors fell by 70%. The rollout reached 100% compliance with safety and regulatory standards across departments.

I set baselines against the existing manual processes before making changes. That gave leadership a way to assess the results and decide what to support next.

What I carry into product work

• When a metric is bad, I look upstream of the team that owns it before I look at the team.
• I treat the process document as a hypothesis and the floor as the evidence.
• I take the data to the people it concerns before I take it to their managers.
• I measure the whole pathway, because a fix in one step can move the wait to the next.

I look for the same pattern in software. A support delay may begin with an unclear product flow; a delivery delay may begin with changing requirements. Before judging the team at the end of the process, I trace what reached them.