4 ms·

3) Amazon grad takes hold of a freight forwarder, and then realizes freight forwarding is not a tech company, nor is it just warehousing and distribution. And

3) Amazon grad takes hold of a freight forwarder, and then realizes freight forwarding is not a tech company, nor is it just warehousing and distribution. And then realizes his competitors rely as much on grizzled logistics veterans and their corporate knowledge about customs brokerage and how to Get Shit Done and Get Shit From Point A to Point B as they do on a cool tech stack. And then goes "shit." Don't get me wrong. From a tech perspective, a lot of Flexport's competitors could use a size-18 boot in the ass. But tech is an enabler for them, not the core business. So there's only so much willingness to fork out cash for what senior leaders see as a supporting function. I mean, if their 40-year-old COBOL backend still works, they DGAF that it's outdated. At least until it can't keep up with the modern side or it starts falling over when all the devs retire, which is a separate story.

AdamJacobMuller 3y ago
Unsatisfied with their IBM mainframe which had a 99.99% uptime (seriously how much missed opportunity cost is that hour of downtime per year!) with a kubernetes microservice application where each of the 1000 components had an extremely impressive 99.999% uptime.
- psunavy03 3y ago
  The problem is that the legacy applications running on that mainframe are tightly-coupled and thus a bitch to test. They're also hard to automate and hard to scale, because design choices made in the 80s and 90s based on people using them at the speed of manually typing on keyboards fall down when you hook up APIs to them for automated testing and for connections to modern applications. And most of the people who know how to develop for them are about to retire. When was the last time you heard of a modern CS or IT degree program offering a COBOL elective? And they're not easy to migrate, because you have 40+ years of business logic locked up in that legacy COBOL application, many of the developers of which are retired or flat-out dead. Did they document it perfectly? LOL! And oh, we're dealing with customs brokerage around the world and also potentially accounting info for a publicly-traded company, which means if you fuck up badly enough, people potentially go to jail.
  - robertlagrant 3y ago
    It's easy to integrate green screens! Just write a program that maps out all of the UI interactions on the fixed-character screen and get the computer to use it! (For those who think this is a joke: it's not only not a joke, it's one of the better ways to roboticise mainframe interactions.)
tschwimmer 3y ago
This is a very nice sentiment but the truth is that the established forwarders operate in a way that is could be greatly optimized. Established forwarders (and Flexport) have teams of people that "move" shipments by applying an SOP (basically a written algorithm for advancing the shipment to signals that come in from a variety of sources (an origin factory various carriers like truckers, airlines and shipping lines, governments, etc). Paying people to do this work is expensive, and the people, while very good, go home at night, take vacations, make mistakes and are generally human. The technology that enables this process at legacy forwarders is as you say archaic, but it is archaic in _design_ as well as execution. It assumes that human beings will be sitting behind a keyboard pushing buttons and making phone calls based on what it says. In my opinion, there is nothing about any of these processes that in aggregate be worse if they were automated, and no fundamental issue with automating them. Moving freight is about as complex as any other inter-business process in that the input is some signal (usually an email but potentially a phone call or a fax) and the output is also usually an email or a phone call. The internal logic to that process is not particularly complex either. So there exists a massive opportunity to provide roughly the same service that existing forwarders do at a much lower cost basis. The requirement to do so is to aggressively automate operations. There's also an secondary opportunity to provide better quality of service (more transparency, more programmatic logic related to movement of goods) to customers (supply chain professionals at F500) but I think that's both harder to do and customers are less sure about how they might take advantage of that better service. Quite frankly, I don't buy the argument that "grizzled logistics veterans" hold the secret sauce to make this work. I was told probably a dozen times that what I was doing was impossible to automate but when I dug into it, what we were trying to do was a bog-standard business process dressed up in domain-specific jargon and 'tradition' (e.g. we can't do it that way since we've always done it this way). I'm not saying that I'm some logistics savant and there's a vast amount of expertise I don't know. What I am claiming is that I've pulled back the curtain on logistics and the wizard is just a regular guy. Source: Former Flexport employee
- sharkweek 3y ago
  > I've pulled back the curtain on logistics and the wizard is just a regular guy. I agree, but land at a different conclusion. I dabbled in logistics a bit at one startup and the thing I found true is that every warehouse and receiving dock did things a little different and sometimes that thing was computer software and other times it was a person with sticky notes all over the walls of their tiny office by the bay door who was on 2-3 phone calls at a time screaming at/being screamed at by people moving goods around the city/state/country/world. Logistics has a ton of room to optimize and I’m sure we’ll continue to see billion dollar startups roll out every year solving some part of it, but in the day-to-day operations of supply chain, change is so incredibly hard. The middle layer of management always seemed so risk averse to making any changes that had the slightest risk of disrupting their existing workflow because if one day they goof something up it quickly spiraled down the chain.
hef19898 3y ago
How much do you know about zje logistics software ised by, e.g., DHL and the like? Because I worked at Amazon, with DHL among others, and I can tell you that in some use cases, DHL has bettwr logistics software than Amazon does. And CargoWise is just a straight genious software suite to run everything from Customs over air, sea and land freight to warehousing. Guess who is using that, or something similar, in some form. Guessed, the majority of logistics companies. No idea where this "incumbants bad, disruptive start-up so much better and easy" mentality comes from so. If you go into the field of logistics and supply chain with that attitude so, you will fail. And hard, and burn a ton of VC money while doing it. The only company that managed not to fail was Flexport, and even they fell short of theit lofty pitch goals. Thaz being said, Dave Clark had, to my knowledge, not a lot to do with the "tech" part of Amazon, he always was an supply chain / logistics ops guy. And a good one at that. If anything, he treated it as a numbers driven thing, and definitely not a tech stack driven one. Part of the reason why he was good at his job at running ops.

AdamJacobMuller 3y ago

Unsatisfied with their IBM mainframe which had a 99.99% uptime (seriously how much missed opportunity cost is that hour of downtime per year!) with a kubernetes microservice application where each of the 1000 components had an extremely impressive 99.999% uptime.

psunavy03 3y ago
The problem is that the legacy applications running on that mainframe are tightly-coupled and thus a bitch to test. They're also hard to automate and hard to scale, because design choices made in the 80s and 90s based on people using them at the speed of manually typing on keyboards fall down when you hook up APIs to them for automated testing and for connections to modern applications. And most of the people who know how to develop for them are about to retire. When was the last time you heard of a modern CS or IT degree program offering a COBOL elective? And they're not easy to migrate, because you have 40+ years of business logic locked up in that legacy COBOL application, many of the developers of which are retired or flat-out dead. Did they document it perfectly? LOL! And oh, we're dealing with customs brokerage around the world and also potentially accounting info for a publicly-traded company, which means if you fuck up badly enough, people potentially go to jail.
- robertlagrant 3y ago
  It's easy to integrate green screens! Just write a program that maps out all of the UI interactions on the fixed-character screen and get the computer to use it! (For those who think this is a joke: it's not only not a joke, it's one of the better ways to roboticise mainframe interactions.)

tschwimmer 3y ago

This is a very nice sentiment but the truth is that the established forwarders operate in a way that is could be greatly optimized. Established forwarders (and Flexport) have teams of people that "move" shipments by applying an SOP (basically a written algorithm for advancing the shipment to signals that come in from a variety of sources (an origin factory various carriers like truckers, airlines and shipping lines, governments, etc). Paying people to do this work is expensive, and the people, while very good, go home at night, take vacations, make mistakes and are generally human. The technology that enables this process at legacy forwarders is as you say archaic, but it is archaic in _design_ as well as execution. It assumes that human beings will be sitting behind a keyboard pushing buttons and making phone calls based on what it says. In my opinion, there is nothing about any of these processes that in aggregate be worse if they were automated, and no fundamental issue with automating them. Moving freight is about as complex as any other inter-business process in that the input is some signal (usually an email but potentially a phone call or a fax) and the output is also usually an email or a phone call. The internal logic to that process is not particularly complex either. So there exists a massive opportunity to provide roughly the same service that existing forwarders do at a much lower cost basis. The requirement to do so is to aggressively automate operations. There's also an secondary opportunity to provide better quality of service (more transparency, more programmatic logic related to movement of goods) to customers (supply chain professionals at F500) but I think that's both harder to do and customers are less sure about how they might take advantage of that better service. Quite frankly, I don't buy the argument that "grizzled logistics veterans" hold the secret sauce to make this work. I was told probably a dozen times that what I was doing was impossible to automate but when I dug into it, what we were trying to do was a bog-standard business process dressed up in domain-specific jargon and 'tradition' (e.g. we can't do it that way since we've always done it this way). I'm not saying that I'm some logistics savant and there's a vast amount of expertise I don't know. What I am claiming is that I've pulled back the curtain on logistics and the wizard is just a regular guy. Source: Former Flexport employee

sharkweek 3y ago
> I've pulled back the curtain on logistics and the wizard is just a regular guy. I agree, but land at a different conclusion. I dabbled in logistics a bit at one startup and the thing I found true is that every warehouse and receiving dock did things a little different and sometimes that thing was computer software and other times it was a person with sticky notes all over the walls of their tiny office by the bay door who was on 2-3 phone calls at a time screaming at/being screamed at by people moving goods around the city/state/country/world. Logistics has a ton of room to optimize and I’m sure we’ll continue to see billion dollar startups roll out every year solving some part of it, but in the day-to-day operations of supply chain, change is so incredibly hard. The middle layer of management always seemed so risk averse to making any changes that had the slightest risk of disrupting their existing workflow because if one day they goof something up it quickly spiraled down the chain.

hef19898 3y ago

How much do you know about zje logistics software ised by, e.g., DHL and the like? Because I worked at Amazon, with DHL among others, and I can tell you that in some use cases, DHL has bettwr logistics software than Amazon does. And CargoWise is just a straight genious software suite to run everything from Customs over air, sea and land freight to warehousing. Guess who is using that, or something similar, in some form. Guessed, the majority of logistics companies. No idea where this "incumbants bad, disruptive start-up so much better and easy" mentality comes from so. If you go into the field of logistics and supply chain with that attitude so, you will fail. And hard, and burn a ton of VC money while doing it. The only company that managed not to fail was Flexport, and even they fell short of theit lofty pitch goals. Thaz being said, Dave Clark had, to my knowledge, not a lot to do with the "tech" part of Amazon, he always was an supply chain / logistics ops guy. And a good one at that. If anything, he treated it as a numbers driven thing, and definitely not a tech stack driven one. Part of the reason why he was good at his job at running ops.