The same row, read twice
Two parts of one job each fetched the same fact, and neither knew the other had it. The waste is invisible until you count the trips instead of the work.
Here is a thing that happens in a kitchen. The person on the pass checks the board to see which orders are still cooking. Thirty seconds later the person plating checks the same board for the same reason. Neither is wrong. Neither knows the other just looked.
On a board on the wall that costs nothing. When the thing being checked is at the other end of a slow connection, it costs the same amount twice.
We found this in our own back office this week. Opening a venue's overview page asks our system two questions in a row: first, is this person allowed to see this venue, and second, what is there to tell them about it. Answering the first means reading the venue's record. Answering the second meant reading the venue's record again, because the part that answers the second question was written separately and had no way of knowing the first part already had it in its hand.
Each of those reads is a journey across the Atlantic and back. About ninety milliseconds, every time, and one of them was pure repetition.
Why nobody noticed
Because both parts were correct. The permission check did its job. The overview did its job. No screen was wrong, nothing was missing, no error was logged. The only symptom was that the page took longer than it should, and "longer than it should" is not a complaint anybody files — you just wait.
Duplicated work of this kind is almost always the result of two things being built at different times by people solving different problems. That is not a failure of care. It is what happens when a system grows. The useful question is not who let it happen, it is how you would ever see it.
Count the trips, not the tasks
The way to see it is to stop counting work and start counting journeys.
Take your stock count. How many separate walks to the dry store does one count involve? Not how many items, how many walks. If the answer is four because four different sheets each send somebody, the problem is not that counting is slow. The problem is that one walk could have carried all four lists.
Take your opening checks. If the fridge temperature is written down by the first person in and again by the chef when they start, one of those is a journey nobody needed. Or it is a deliberate second opinion, which is a different thing entirely and worth keeping — but you should be able to say which.
What we actually changed
We could not simply hand the first part's record to the second. There is a hard limit on how much our database will return in a single answer, and the permission check's question already sits exactly at it. That route was closed before we wrote a line.
What was open was that the overview already makes one trip of its own, and it carries a list — eighteen separate questions asked together in one go. A trip carrying eighteen questions costs the same as a trip carrying nineteen. So the venue's record became the nineteenth question, and the second journey stopped happening.
Two round trips became one. On our bench, sitting next to the database, that is worth about five milliseconds and you would never spot it. From a laptop in Winchester, it is ninety.
The general version: when you find the same fact being fetched twice, the fix is rarely to delete one of the fetches. Usually one of them genuinely needs to happen. The fix is to find the trip that is already being made and put the question on it.