Latest / The Operator's Manual with Fexingo: Daily Decisions, Tactical Wins, and Business Execution / How FedEx Saved Millions With a Single Routing Algorithm
Transcript
- Lucas: So FedEx moves something like fifteen million packages a day. And most people know the story—overnight shipping, the purple promise, right? But there is a quieter, something like a billion-dollar operational win that happened between 2020 and 2025, and it had almost nothing to do with planes or trucks. Luna: A routing algorithm, I'm guessing? I read something about a 'hub and spoke optimizer' they launched around 2021. Lucas: Exactly. The official name internally was just 'The Optimizer'—which is very FedEx, very understated. But the numbers are anything but: it saved them over eight hundred million dollars in fuel and labor in its first four years. And it's a textbook case of how operations people think differently from, say, financial engineers. Luna: Walk me through what it actually does. Because I imagine the naive version is just 'the computer picks the cheapest route'—which they've been doing for decades. Lucas: Right, and that's the trap. The naive route optimization is a classic shortest-path problem—Dijkstra's algorithm, constraints on truck capacity, time windows. But FedEx's network is not a static map. It's a constantly shifting web of roughly six hundred hubs, where every package's path interacts with every other package's path because they share the same planes and trucks. Luna: So it's not just about the route for one box. It's about the entire system at once. Lucas: That's it. The optimizer treats the whole network as one massive combinatorial problem: which packages should be routed through Memphis versus Indianapolis versus Oakland at 2 a.m. on a Tuesday, given weather, given aircraft availability, given that a single delay in one hub cascades into a hundred missed delivery windows. Luna: And before this, how did they do it? Was it human dispatchers? Lucas: Partly. But mostly it was a rules-based system that had been patched together over thirty years. Sort of like a giant Excel sheet with a thousand if-then statements. And it worked—barely. But the system had no capacity to learn from real outcomes. It didn't know that a certain route through Denver always gets snow delays in February, or that a certain truck driver is consistently faster on the graveyard shift. Luna: So the optimizer was learning from historical data and real-time conditions. That sounds like a machine learning problem more than a pure logistics one. Lucas: It's a blend. The core engine uses reinforcement learning—basically, it simulates millions of possible routing decisions every night, scores them on cost and reliability, and picks the best one. But the hard part wasn't the algorithm. The hard part was getting the data clean enough to feed it. FedEx had something like four thousand different data sources, all with slightly different timestamps, all with different definitions of 'on time'. Luna: Classic operational problem. The algorithm is the easy 10 percent. The data plumbing is the other 90. Lucas: Exactly. And here's where it gets interesting. The team building the optimizer—about forty people led by a VP named Carrie McMillan—had to fight for two years just to standardize the timestamp format across the network. One hub was using local time without daylight saving adjustments. Another was logging arrivals in seconds since midnight. These are the kinds of details that make or break a project like this. Luna: And I bet there was internal resistance too. Because changing a routing system means changing the work of thousands of sorters and drivers who have their own mental models of how the network should flow. Lucas: Huge resistance. The operations managers in the hubs—these are people who have been doing this job for twenty years—they didn't trust the algorithm. And in the early days, they had good reasons not to. The first version of the optimizer tried to consolidate packages onto fewer trucks to save fuel, but that made some routes longer, and drivers missed delivery windows. The algorithm didn't know that a certain customer absolutely had to have a package by 10 a.m., not 10:30. Luna: So they had to build in a soft constraint for customer expectations. Lucas: They called it 'service-level override'. Basically, the optimizer had to learn a second objective: minimize cost, but never sacrifice the delivery promise. That forced the team to actually sit down with the hub managers and codify about three hundred unwritten rules that existed only in people's heads. Things like 'the Smith account on Elm Street always gets an early drop because the receptionist leaves at 4:45.' Luna: That's the kind of knowledge that no data scientist would ever think to ask about. Lucas: It's the difference between a good algorithm and a great one. And look, I think this is a genuinely useful lesson for any business that's trying to optimize something complex. The temptation is to throw data at a problem and let the machine figure it out. But the real work is understanding the tacit knowledge that already exists in your organization and embedding it into the model. Luna: Yeah, the algorithm is only as good as the rules you give it. And those rules live with the people who do the job every day. Lucas: So after about eighteen months of iteration—getting the data clean, codifying the tacit rules, running shadow tests alongside the old system—the optimizer started outperforming human dispatchers by a measurable margin. Fuel costs dropped 7 percent in the first year. Labor costs dropped 5 percent. And on-time performance actually improved by half a percentage point. Luna: That's the kind of win that gets attention. When you can say 'we saved money and got better service,' the skeptics tend to quiet down. Lucas: And they kept quieting. By 2024, the optimizer was routing over 90 percent of domestic packages. The savings accumulated to that eight hundred million figure I mentioned. But the most interesting part to me is what happened next. Once the algorithm was proven, FedEx started using it for strategic decisions, not just daily routing. They asked it: if we open a new hub in Austin, how does the network rebalance? The optimizer could simulate that in a few hours. Luna: So it went from a tactical tool to a strategic one. That's a great trajectory for any ops project. Lucas: It is. And I think it highlights something that often gets missed in business media. We hear about the big, dramatic turnarounds—the new CEO, the massive restructuring. But a lot of the most durable value creation happens in the trenches, with a team of forty people cleaning up timestamp data and convincing hub managers to trust a machine. It's not glamorous, but it compounds. Luna: Right. And if you're a listener who's trying to do something similar in your own organization—maybe not an eight-hundred-million-dollar project, but a smaller optimization—the principle is the same: find the tacit knowledge, clean the data, and iterate in the shadows before you go live. Lucas: Yeah. And by the way, these conversations—the ones where we drill into how real operations work—they take a lot of research and a lot of coffee. We deliberately don't run ads on these episodes. If you want to support that choice, the link is buy me a coffee dot com slash fexingo. Luna: Yeah, it keeps the show independent and focused on the stuff that actually matters. No sponsor copy to dance around. Lucas: So back to FedEx. One more detail I love: the optimizer actually reduced the number of packages that went through the Memphis superhub overnight. It found that for certain routes, it was cheaper to fly directly between smaller hubs, even if the plane wasn't completely full. That was counterintuitive to the traditional hub and spoke logic. Luna: Because the conventional wisdom is that you consolidate everything at the hub to maximize density. But the optimizer said, actually, for some origin-destination pairs, the cost of the extra handling and the time delay outweighs the density benefit. Lucas: Exactly. And that was a decision that no human dispatcher would have made, because it violated the mental model that had been gospel for forty years. The algorithm didn't have that bias. It just looked at the math. Luna: So in a way, the algorithm wasn't just optimizing routes. It was challenging the operating model itself. Lucas: And that's where the real money is. But it's also where the cultural friction is highest. Because when you tell a veteran operations manager that the algorithm wants to bypass Memphis on a route he's been running for a decade, he's going to push back hard. That trust building was probably the biggest hidden cost of the whole project. Luna: Did they have any formal process for that? Like, did they create a feedback loop where the algorithm's suggestions were reviewed by humans before going live? Lucas: They did. For the first six months of live deployment, every routing change that deviated more than 10 percent from the previous day had to be approved by a senior dispatcher. That slowed down adoption, but it also built buy-in. The dispatchers started to see that the algorithm was making reasonable calls, and they began to trust it. By month nine, the approval threshold was removed. Luna: That's a really smart governance move. Give the algorithm freedom, but with guardrails that people can see and eventually retire. Lucas: And I think that's the closing thought for today. Whether you're routing packages or scheduling hospital staff or managing inventory, the biggest operational gains don't come from the algorithm alone. They come from the humans who build the trust, clean the data, and codify the unwritten rules. The algorithm is just the final step. Luna: Well said. And on that note, we'll pick up another tactical win tomorrow. Same time, same feed.