Having built one of the largest tech-enabled 3PLs from ground up and serving as CTO for a logistics tech startup with client 20M - 1B annual transportation spend, my take below
> We're using a third-party product that functions, but barely. The provider is understaffed and unresponsive and the platform is stagnant. It's a fight getting basic bugs fixed let alone new features implemented. We're having to resort to a separate low-code platform to fill in the gaps. Our business operates in a specific niche and there are no other providers who cater specifically to our industry.
Most successful and agile 3PL and LSP (non VC backed) do not build all their tech, but rather glue tech together. They leverage pre-built TMS, WMS, YMS and build out in-house middleware layer for analytics and control points. Key is to guarantee portability of data and analytics with a unified view of the business.
> On the other hand, while our current solution seems like a straightforward CRUD app, I fear the devil is in the details. Will we get stuck at 80% completion? We do a lot of data exchange via EDIFACT, for instance, with various government institutions all over Europe. This feels like a quagmire in which development can quickly stall.
The Devil is definitely in the details. We regularly ignore what C/VP/Dir-level's description of tech and business process. Talking with the direct team member or their manager reveal so much more of the real painpoints than what higher up learns. The risk here is not business adopting tech but rather tech team understanding business. Have a senior leader here who are technical with strong business domain expertise is critical. They need to form a culture of domain understanding throughout the tech org.
> Strategies for attracting and retaining tech talent in a non-tech industry Experiences transitioning from third-party to in-house software (success stories and cautionary tales).
It is very hard. Mostly due to comp, EPD treated as a cost center (and engineers do not want to be devs), lack of recognition of the industry.
There is one thing going for logistics, it touches physical world and is extremely complex (not hard). It attracts certain types of people prefer complex problems. Aside from senior tech leaders and a few senior engineers, you will be aiming for the diamond in the rough profile here.
There are rare cases such as Ryder acquiring Baton and use the latter as their core Engineering while keeping some old IT groups hanging around. Ryder is large enough to pay tens of engineers 300k+ salaries.
> Potential pitfalls we might not be considering. Alternative solutions we should explore.
Instead of building a tech team to build everything, you have an artifact, who is a domain expert on your own business, define a business middleware and analytics ingress for the company. Start by normalizing against the middleware and analytics ingress with consultants before building your own tech team.
Logistics has been the most fascinating industry I have worked in and I see my whole career in this industry. Excited to chat more tech strategy in logistics, email shu at loop dot com.
> We're using a third-party product that functions, but barely. The provider is understaffed and unresponsive and the platform is stagnant. It's a fight getting basic bugs fixed let alone new features implemented. We're having to resort to a separate low-code platform to fill in the gaps. Our business operates in a specific niche and there are no other providers who cater specifically to our industry.
Most successful and agile 3PL and LSP (non VC backed) do not build all their tech, but rather glue tech together. They leverage pre-built TMS, WMS, YMS and build out in-house middleware layer for analytics and control points. Key is to guarantee portability of data and analytics with a unified view of the business.
> On the other hand, while our current solution seems like a straightforward CRUD app, I fear the devil is in the details. Will we get stuck at 80% completion? We do a lot of data exchange via EDIFACT, for instance, with various government institutions all over Europe. This feels like a quagmire in which development can quickly stall.
The Devil is definitely in the details. We regularly ignore what C/VP/Dir-level's description of tech and business process. Talking with the direct team member or their manager reveal so much more of the real painpoints than what higher up learns. The risk here is not business adopting tech but rather tech team understanding business. Have a senior leader here who are technical with strong business domain expertise is critical. They need to form a culture of domain understanding throughout the tech org.
> Strategies for attracting and retaining tech talent in a non-tech industry Experiences transitioning from third-party to in-house software (success stories and cautionary tales).
It is very hard. Mostly due to comp, EPD treated as a cost center (and engineers do not want to be devs), lack of recognition of the industry.
There is one thing going for logistics, it touches physical world and is extremely complex (not hard). It attracts certain types of people prefer complex problems. Aside from senior tech leaders and a few senior engineers, you will be aiming for the diamond in the rough profile here.
There are rare cases such as Ryder acquiring Baton and use the latter as their core Engineering while keeping some old IT groups hanging around. Ryder is large enough to pay tens of engineers 300k+ salaries.
> Potential pitfalls we might not be considering. Alternative solutions we should explore.
Instead of building a tech team to build everything, you have an artifact, who is a domain expert on your own business, define a business middleware and analytics ingress for the company. Start by normalizing against the middleware and analytics ingress with consultants before building your own tech team.
Logistics has been the most fascinating industry I have worked in and I see my whole career in this industry. Excited to chat more tech strategy in logistics, email shu at loop dot com.