Every working morning in Mumbai, around 5,000 men collect hot meals from private flats and put them down four hours later on the right desk. Right building, right floor, right person. Each container changes hands up to twelve times on the way. None of these men uses an app. Many cannot read. The system has been running since 1890 and it turns a profit.
The story appears in every second talk about efficiency, and it is almost always told wrong. The usual punchline: low tech beats high tech. Or, one notch more romantic: community beats corporation. Both sound good. Both are comfortable. And both throw away the one insight worth taking home.
Because the dabbawalas did not make delivery better. They made it simpler. In a way any mid-sized company could copy and almost none want to.
The number nobody measured
Start with the detail that shows up in every deck: one error in six million deliveries. Six sigma. Certified by Forbes in 1998.
None of that is true.
Forbes never certified anything. Subrata Chakravarty, who wrote the piece, clarified in 2007 that he never used the term six sigma at all. The number itself came out of an interview. The president of the carriers' association was asked how often mistakes happen and said, in effect, almost never, maybe once every two months. That recollection was divided by the daily volume. Because the empty containers travel home in the evening, the return leg was counted as a delivery of its own and the denominator doubled. At a conference in 2002 a reporter asked the association president whether they were a six sigma organisation. He did not know the term, had it explained, and said: then we are, ask Forbes. The reporter wrote it down. The certificate was born.
This is not an argument against the dabbawalas. It is an argument against us. The most famous metric in modern process literature is a gut estimate nobody checked, because it fitted a story everybody wanted to hear. If you wonder why companies believe AI promises quoted to three decimal places, here is the mechanism in pure form. A good narrative produces agreement faster than data ever can. I have taken that apart using football analysis as the example, and it applies here one to one.
Even the base numbers wobble. Depending on the source it is 130,000 or 200,000 containers a day, depending on whether the return leg counts. That is not a scandal, it is normal. But it should trigger the reflex to look past the number for the mechanism. And the mechanism really is remarkable. Just for different reasons than everybody claims.
The whole route is painted on the container
Each lid carries a short code of digits, letters, colours and symbols. It holds the origin station, the pickup zone at the origin, the delivery zone in the target district, the building and the floor. Nothing more. And it is enough.
That sounds like folklore. It is an architectural decision with serious consequences: the state travels on the object, not inside a system.
Nobody looks anything up en route. There is no control room to call, no database that can fail, no outage that stops the chain, no training beyond learning about twenty symbols. And, the underrated part, there is no state that can drift apart between the object and the system. The single most common failure mode of any digitised supply chain simply does not exist here.
The test for this is uncomfortably simple and can be run in your own company tomorrow: does somebody have to look something up to know what happens next with this item? If yes, the information sits in the wrong place. Every ticket parked in a queue because somebody first has to check a second system is a lid without a code.
Four hours, twelve handovers, no control room
The day runs in fixed blocks. Pickup between 8:30 and 9:30, 25 to 35 stops per carrier. Collection point at the station, first sort by destination station. Loading into the goods compartment of the suburban train while the train stands, in roughly forty seconds. Second sort at the destination station, this time by delivery zone. Then on foot or by bicycle into the building, up to the floor, onto the desk. After that the entire chain reverses and the empty containers travel home.
Around 200 self-governing units of roughly 25 people each run this. No corporation, no head office, no middle management. Each unit signs its own customers, enforces its own rates, decides on its own new members. Whoever wins the customer also carries their container. Accountability is not delegated, because there is nobody to delegate it to.
Incidentally this is the cleanest illustration of Conway's Law I have ever come across. The structure of the organisation is the structure of the process. 200 units, 200 local coding variants, and still no conflict, because the units only touch at the stations and a shared format is enough there.
The real trick: the variables are gone
Now the part the efficiency talks leave out.
The dabbawalas do not reach their reliability because they deliver especially well. They reach it because there is practically nothing to decide inside their process. The time of order is fixed. The sender is one household. The destination is one desk. The contents are irrelevant, because the container is standardised. The carrier is the same person every day. The price is a flat monthly rate, roughly 15 to 25 euros.
A delivery app has the same six variables and leaves every single one open. That is why its error rate is higher. Not because its drivers are worse, not because the software is bad, but because it is solving a combinatorially larger problem. It sells optionality, and optionality is the most expensive component of any delivery.
The comparison is unfair, and that is the point. It gets made constantly without anybody saying out loud that two entirely different products are being compared. One sells a subscription to reliability. The other sells the right to change your mind at any moment. The price difference is not a scandal, it is a correctly priced service. It just never appears anywhere as a service.
You cannot automate a decision you never made
Which brings us to what this means for a company thinking about automation.
I regularly sit in meetings where a process is supposed to be automated, and I ask the same question: how does it run today? In roughly half the cases the answer starts with "well, it depends". Then come the special cases. That one customer gets different terms. The colleague in accounting does it differently from her counterpart. Large orders get a phone call anyway.
Processes like that can be modelled technically. You rebuild the branches, every exception becomes a rule, and at the end you own a rulebook that costs more to maintain than the mess did. That is the standard route along which software projects fail, and it is almost never recognised as a requirements problem. It is treated as a tooling problem. So the tool gets swapped. Twice.
The dabbawalas would never have had that discussion. Their order of operations is the reverse:
| The usual route | The dabbawala route | |
|---|---|---|
| Step 1 | Pick the tool | Decide what gets dropped |
| Step 2 | Model the current process, exceptions included | Standardise the rest so it needs no lookups |
| Step 3 | Patch in the exceptions as rules | Add a tool, if one is needed at all |
| Result | A rulebook that preserves the old mess | A process someone can run without knowing it |
Standardisation is not technical groundwork. It is the product. The tool then only speeds up what is already unambiguous. Invert that order and you buy software meant to replace a decision nobody wanted to make. Concretely: before anyone talks about systems, put the process costs on the table and walk through the degrees of freedom one by one. Each gets the same question: what does it cost to leave this one open, and who pays for it?
Most of the time the answer is: the customer wants it that way. Sometimes that is true. Often nobody has noticed that the variant dates from 2014 and that customer no longer exists.
The price: a system with exactly one dependency
Now the part the admirers of the dabbawalas also leave out, and without which the thesis would not be honest.
This system is not robust. It is rigid. And rigidity looks exactly like robustness right up until the operating point moves.
The whole thing hangs on two conditions: the suburban railway runs, and the office towers are full of people. Both disappeared at once in 2020. The number of carriers collapsed from around 5,000 to roughly 1,500, and many went back to their home villages. A carrier's monthly earnings fell from about 18,000 to 5,200 rupees. Even after the offices reopened, the number has settled at around 3,000. Hybrid work is not a market fluctuation for this system, it is a design problem: a fixed pickup slot for someone who is at home three days out of five is not a product.
That is the bill attached to every act of standardisation. Take variance out and you buy accuracy and speed at one operating point, and you sell the ability to move when that point shifts. That is defensible as long as you know it. It becomes fatal when you celebrate the first half and never book the second.
For a company this means: standardise aggressively where the operating point is stable. Booking, invoicing runs, onboarding, master data. Leave the degrees of freedom where the market actually moves, and make that decision explicitly rather than by doing nothing. Swap the two and you get the worst of both: rigid sales processes and creative accounting.
Not the opposite of the market. The market without the middle layer.
That leaves the romantic reading, in which the dabbawalas are the counter-model to platform capitalism. I consider it the weakest claim in the whole story.
200 independent micro-businesses that form an association, enforce prices together, control admissions and fire customers who will not follow the rules: that is not the opposite of a market. That is a cartel of sole traders, and it works commercially rather well. Rates were last raised in 2025, citing fuel and inflation. An entirely ordinary business decision.
The difference to a delivery app is not moral. It is structural. Nothing stands between the carrier and the customer. No head office, no driver dispatch, no marketing department, no investor whose growth expectations have to be financed. A platform's commission runs from 13 to 30 percent of order value depending on the model, and often higher once fees and mandatory promotions are added. That spread does not pay for delivery. It pays for the coordination layer that becomes necessary the moment you release those six variables again.
That is why a carrier in Mumbai can live on 15 euros a month per customer while an app runs tight margins at 30 percent commission. Not because one is greedy and the other charitable. Because optionality has its own cost centre, and that cost centre appears on no quote anywhere.
What I take from it
I sell automation. It would serve my interests to end this article by saying you can get all of this with the right software. You cannot.
What I take from Mumbai instead are three questions that come before any tool:
- Which degrees of freedom does this process have, and which of them do I actually want to pay for? Every open degree of freedom multiplies the cases. Not adds. Multiplies.
- Does somebody have to look something up in order to continue? If yes, the information belongs on the item, not in a second system.
- How many conditions does the whole thing depend on, and what happens when one of them goes? If you cannot answer that, you do not have an efficient system. You have one that has been lucky so far.
The dabbawalas answer questions one and two better than any software I know. On question three, 2020 handed them the full bill.
That is the honest lesson, and it is less comfortable than the usual one: there is no efficiency without a price. There is only the choice of whether you know the price before it falls due.
Related
- Best Practices for Process Automation: The Complete Guide
- Over Budget, Behind Schedule, Off Target: Why Software Projects Fail
- Conway's Law: Why Your Architecture Mirrors Your Org Chart
- Germany Loses to Paraguay. Our Brain Wins a Story.
Sources: Stefan Thomke, "The Dabbawala System: On-Time Delivery, Every Time", Harvard Business School Case 9-610-059, 2010. Subrata Chakravarty in Forbes Global, 1998, and his 2007 clarification. Figures on headcount, earnings and monthly fees follow Indian press reports from 2020 to 2025; they vary by source. Platform commission rates follow provider disclosures and industry reporting, as of 2026.