The Friday dispatch stopped looking fast when volume exposed the decisions the team had been making silently. Each reroute, exception and customer promise had depended on someone remembering a rule that nobody had written down.
The week had started with the number everyone wanted: a record of orders moved. By Friday afternoon, the number had become a wall of WhatsApp messages.
One customer needed a change of address after packing. Another wanted delivery before the weekend. A driver had reached the wrong pickup point. Someone had approved a substitution in a private chat, and the warehouse team only found out when the original item was already gone.
The team was still moving orders. That was the problem. From the outside, the system appeared to work. Inside it, people were checking three chats, asking who had approved what, and deciding whether a one-off exception should become the new rule.
Speed had hidden the work.
The decisions volume brings into view
At low volume, a founder can carry a surprising amount of process in their head. You know which customer gets a call first, which courier can handle a difficult route, and when a small delay deserves an apology before it becomes a complaint.
Then volume rises. The founder becomes the fallback for every unclear case.
The team does not need more encouragement to move quickly. They need the decisions to become visible. Which changes can the warehouse approve? Which ones need customer confirmation? When does a reroute cost more than the order is worth? Who owns the decision when the answer is not in the original workflow?
These are product decisions disguised as operational messages. They determine margin, customer trust and whether the next order can move without the same conversation happening again.
I have seen the same pattern while building products across Africa, Germany and the United States. A workflow can look efficient while one person is absorbing every ambiguity. The system appears fast because the hidden work has not yet become too large to carry.
Apollo 13 had the same shape of problem
In 1970, Apollo 13’s crew had a rising carbon dioxide problem and a supply of replacement canisters that did not fit the spacecraft’s system. The outcome was still uncertain when engineers at Mission Control in Houston worked through a way to connect what they had available to what the spacecraft could use.
Jim Lovell, Jack Swigert and Fred Haise returned safely, but the famous solution only worked because the constraint became explicit. The engineers had to reason from the materials, dimensions and instructions available to the crew. The story is documented in Lost Moon, written by Lovell and Jeffrey Kluger.
The lesson for a growing dispatch operation is smaller but familiar. When the volume rises, the work that used to live in memory, private messages and instinct becomes a constraint. You cannot improve a decision that the system does not show you.
Make the invisible decisions recordable
The first useful step is to capture the exceptions for one week. Do not begin by designing a full operations platform. Record every reroute, manual approval, substitution and customer promise that falls outside the normal path.
For each one, write down four things:
- What happened?
- Who made the decision?
- What rule did they use?
- What should happen next time?
Patterns appear quickly. Perhaps address changes are frequent enough to deserve a clear cutoff. Perhaps one person approves every courier change. Perhaps the team is protecting delivery speed by accepting work that quietly removes the margin.
This is also where a founder should separate a workflow problem from a staffing problem. Hiring another person to answer the same unclear questions increases the number of people inside the confusion. A written decision rule can remove more work than another inbox.
The same principle applies to product teams. A demo may appear fast because a founder manually fixes the data behind it. A launch may look close because one person is carrying the missing registration, approval or customer evidence. I wrote about a similar failure mode in [the mock file that would have hidden a failure]( /blog/the-mock-file-that-would-have-hidden-a-failure-and-what-it-put-at-risk-3111ce83/), where the missing work mattered more than the visible feature.
The next record should explain the last exception
Apollo 13’s workaround mattered because it converted a dangerous mismatch into something the crew could act on. Your dispatch process needs the same kind of clarity at a much smaller scale.
On the next Friday, do not only count orders moved. Count the decisions people had to reconstruct. Pick the most common one, write the rule in plain language, assign an owner, and check whether the next person can follow it without opening WhatsApp.
That is when speed starts to mean something again. The team is moving quickly because the work is clear, not because someone is quietly holding the whole system together.
Comments
No comments yet.