The supplier was blamed for years, turns out it was us

At Lloyds Direct, warehouse staff had a target time to unpack each pallet. They kept missing it. Stock arrived jumbled, items in the wrong order, the whole process slower and more frustrating than it needed to be. Pallets that should have been straightforward to unpack turned into a puzzle every time.

For years, the assumption was that it was a supplier problem. The supplier was packing the pallets badly. It was plausible, it explained the symptoms, and nobody questioned it seriously because the explanation was good enough.

It wasn't the supplier.

Tracing it back

When we actually investigated, we found the problem was in how our system was interfacing with the supplier's API. The way we were requesting and organising pallet configurations was generating layouts that made physical unpacking harder than it needed to be. The items weren't jumbled because the supplier packed them badly. They were jumbled because our software was telling the supplier to arrange them in a way that didn't account for how they'd actually be unpacked at the other end.

The system worked. The API did what it was told. The supplier packed what was specified. But nobody had connected the dots between the configuration our software generated and the physical reality of a person standing in a warehouse trying to unpack it against the clock.

Getting the engineers on the floor

We got the engineers to go to the warehouse and try to unpack a pallet within the target time themselves.

They couldn't do it.

Standing in front of a pallet and failing to hit the target made the problem real in a way that reports, metrics and meetings about warehouse efficiency hadn't. It took about ten minutes.

When you've personally experienced how frustrating a process is, you fix it differently. You don't file a ticket and move on. You understand the urgency because you felt it. And you're more likely to solve the root cause rather than patching a symptom, because you've seen the full picture.

What should have happened

Once the team understood the problem properly, the fix needed to be two-sided. We needed to change how the system interfaced with the API so pallet configurations were optimised for unpacking, not just packing, with items arranged in the order they'd be shelved and grouped by location in the warehouse. We also needed to question whether the targets were realistic to begin with, given that the engineers themselves couldn't hit them under real conditions.

We found the root cause. We knew what needed to change. But the company decided there were other priorities, and the API change never got made.

Getting engineers onto the warehouse floor and having them try the job themselves surfaced a problem we'd misattributed to the supplier for years. The API change wasn't prioritised, but we had at least stopped blaming someone else for a problem our own software had created.

Dogfooding on the warehouse floor

Using your own product is only the start of dogfooding. Installing the app, clicking around and seeing if anything breaks barely scratches the surface.

Real dogfooding closes the gap between the people who build the system and the people who live with its consequences. It means experiencing the time pressure, frustration and workarounds your users deal with because the tool doesn't do what they need.

At Lloyds Direct, the relevant context was the warehouse floor. The engineers had to try to hit the target with a pallet of jumbled stock in front of them, and that experience turned a three-year-old "supplier problem" into an obvious software fix.

The pattern

Every team I've worked on has had at least one problem like this. A long-standing issue that everyone has a theory about, but nobody has properly investigated because the current explanation is comfortable enough.

The fix is almost always to go where the work happens, watch it, try it yourself if you can, and talk to the people doing it every day. Listen especially closely when what they're saying contradicts the data or the official narrative.

If anecdotes keep surfacing that contradict the metrics, the measurement might be wrong, not the anecdotes. In the warehouse, the metrics said the supplier was the problem. The people doing the work knew something else was going on. They were right. We just weren't listening.