What's So Hard About Scheduling a F****** Truck?

My first interaction with Dave Clark occurred in Peak (Amazon’s name for the insanely busy period from Black Friday to Christmas) 2011. Technically, it was my second Peak but I had started on Nov 1 in 2010 so my first was more similar to the experience of falling off a whitewater raft into a raging river - lots of being tumbled about and suddenly finding myself on the other side dazed, confused and wondering what just happened.?

Another individual and I had been hired to manage Amazon’s “linehaul” aka Truckload movements and carrier management. For perspective, at my orientation someone had asked me, “What does Amazon need trucks for?” More than $200 million in Truckload spend which was more than doubling year over year, thousands of time critical movements per week, two people… sounds about right for Amazon Transportation in those days.?

A year later and I was a participant in the Peak metrics review – a very deep, data driven recounting of yesterday’s business.? Everything from UPS and FedEx’s “performance to Promise '' to Fulfillment Center safety, productivity and customer facing “defects' ' for the millions of packages being shipped every day from ~20ish FCs and a single 3rd party run Sortation Center.? An FC General Manager in that meeting reported that several thousand packages had missed their Critical Pull Time (CPT) because the truck meant to pull at that time had never shown up. Dave’s eyes turned to me as the person in the room responsible for making sure the trucks showed up. I actually don’t think he actually asked what happened. He just gave me that look. Those who know, know. My response to the unspoken but obvious question was that the truck had never been scheduled and so the carrier was never tendered the load. No tender, no truck.

Now, at this time, I did not own the creation and communication of these schedules. It was, in fact, yet another area that had become much larger, much faster than the resources assigned to manage it and was the responsibility of two more junior Program Managers trying to manage out of control volume and complexity growth in an Excel spreadsheet. They were not in the meeting but I was.

“What is so hard about scheduling a f****** truck?!”

As with many things, the complexity isn’t in the scheduling of A truck but in the scheduling of thousands of trucks in a highly variable, high volume environment with no TMS to speak of. At that point Dave didn’t know those details and why it was hard. This concept of “linehaul” was new to the company as it began to disintermediate both on Inbound and Outbound. His question was perhaps unfair as voiced but his willingness to learn the complexity was there once it was explained.?

After that Peak, apparently I had demonstrated enough understanding of the complexity that I was given those two Program Managers responsible for scheduling who, as it turns out, were amazingly talented. Over the next year we built that spreadsheet into a simple Access-enabled front end and then managed to gain the interest of a bit of an overlooked tech team and? they built us a web based interface while we continued to apply data to address the complexity as that Linehaul spend continued to grow to half a billion dollars.?

By 2013, resources from the main transportation technology technology team were assigned to turn our scrappy little solution into a global platform. While that development and launch of “Roadrunner” is a saga unto itself, that platform continues to be the core of Amazon’s planning and scheduling services for linehaul movements.?

Dave had come to understand what was so complicated about scheduling a truck and put resources against it to solve it. Although once he was not aware of the complexity, unlike many leaders at his level, he embraced the details and worked to understand the problem. He “got it” and acted appropriately.??

In 2015 with that Linehaul spend approaching a billion dollars, reaping the benefits of coaching from Mike Indresano, I wrote a Six Pager entitled “Project Mosaic”.? It outlined, among other things, why Amazon should purchase tens of thousands of trailers, adopt a contracted service provider model to power them, start training CDL drivers and invest tech and people resources into its optimization, dispatch management and maybe an App (Relay - although others ended up naming that one).?

Of course this was a massive investment and other than the pride I have in what that work has become since, there is one thing from the review of that paper with Dave that I remember the most. As part of the optimization necessary to realize the full potential cost savings of this initiative, I suggested we blow up one of the most sacred of sacred cows at Amazon - the CPT. Not really blow it up (CPTs are still central to Fulfillment and Transportation architecture at Amazon) but expose it for what it had become and start thinking about it differently.

Over the last 15 years the CPT had become THE single biggest metrics in an FC.? It was the best proxy FC operators had for the Customer Experience of receiving orders on time. Working backwards from the customer, in order to receive their package on time, the package had to make its first planned sort at UPS or FedEx . In order for that to happen the truck had to arrive before the sort was over and for THAT to happen, the truck had to leave the FC by the CPT. At some point in the past when only a single truck was sent on any given lane to the local UPS or FedEx facility it was a fine proxy.

By 2015 Critical Pull Times had become Convenient Pull Times in many cases. Although still loosely aligned with their original intent now linehauls leaving for UPS, FedEx, OnTrac and? LaserShip were influenced by factors such as shift times, break times and the need for load leveling labor and sortation capacity within the FC as well as ensuring volume availability for the efficient operations of Amazon’s own shiny new 24 buildings sortation network.??

Despite this erosion of the importance of the CPT downstream, inside the FC, missing CPT was still sacrosanct and for good reason. The presence of a firm deadline to work against inside the four walls was critical. My suggestion in the paper was that a truck not being out of the yard by 30 minutes past CPT may not actually be a bad thing. Provided we could still get the packages downstream by their theoretical Critical Entry Time there was enough buffer built in the system to exploit. Although buffer was rightly always viewed as inefficiency, in the case of the optimization of “our” fleet that buffer drove massive asset efficiency and could save billions over the course of several years of forecasted growth.?

Needless to say, there was some gnashing of terrible teeth as I suggested breaking core metrics that had been the leading conversation in every meeting for the last decade plus. Dave, however, “got it”.? He now very well understood what was so f****** hard about scheduling a truck and through the lens of that understanding was able to objectively view the data and green lit the initiative which has since gone on to be one of the more above the water line representations of Amazon’s growth and success in Logistics.

This is what Flexport bought: An executive who thinks big, yes, but more so, an executive who is willing to dive down far enough into the details to “get it” even when it’s new to him and very complex; who knows how to? leverage the hell out of data to both inform himself and drive planning and performance in an organization; and who is willing to kill even his own sacred cows if that’s the right decision.?

Sure there’s some other opportunities and pitfalls there for him but that can be said of all of us. Being a builder isn’t about just building things other than yourself.