Introduction to Dan Bailey & AI in Logistics
00:00:02
Speaker
Welcome to Supply Chain Connections. I'm Brian Glick, founder and CEO at Chain.io. On this episode, we're chatting with Dan Bailey. Dan is a co-founder at Nexcade, which is a young company working in AI automation inside the
Dan's Transition from Banking to Logistics
00:00:18
Speaker
I first met Dan when he was at Sedna building email automation capabilities inside this yeah industry and have been very excited to see his enthusiasm for industry grow. And we're going to chat about that as he comes from a non-traditional background as in he isn't born into it.
00:00:36
Speaker
So I hope you enjoy the episode.
00:00:43
Speaker
Dan, welcome to the show.
Dan's Career Path: Deutsche Bank to Nexcade
00:00:45
Speaker
Brian, thanks for having me. Delighted to be here. So let's start off. You have a non-traditional journey into this space. So I'm very curious how you got into this business because we have about three canned answers on that we hear from everybody and you're not going to give one of them. So tell me, tell us how you got into the business and then i'm even more curious why you decided to stick around for another go at it.
00:01:08
Speaker
Yeah, my background, I started out I grew up in the northwest of England in a small village, came down towards London, studied economics. and ended up joining Deutsche Bank in investment banking.
00:01:19
Speaker
And yeah, very far from a supply chain, but while I was there, learned a lot of things, but got burnt out a little quickly by, i think, the detachment of what we did from reality.
00:01:30
Speaker
You know, reducing these enormous transactions and the companies that we worked with, which were incredibly rich and interesting companies, down to a set of numbers on a spreadsheet, really didn't jive with me.
Role at Sedna & Email Automation Challenges
00:01:39
Speaker
And so left investment banking after a couple of years, joined Venture Capital, and was where...
00:01:45
Speaker
I got my first foray at the intersection of supply chain. So I started, we were investing in early stage technology companies across the UK and Europe and started to dip my toe in a little bit by, we started looking at investing across the digital freight forwarder landscape, some of the early supply chain technology landscape between 2015 2020.
00:02:04
Speaker
Ultimately, did not get as excited by one or two of those propositions as the company that I ended up joining, which was Sedna. I joined in 2020 building supply chain communication software. So we worked across the supply chain landscape. Any companies that were struggling with high volumes of email and tremendous volumes of communication, which turns out to be almost every company in the supply chain.
00:02:26
Speaker
I started off as chief of staff and up becoming chief operating officer and stayed there for four years before leaving to start Nextcade.
00:02:35
Speaker
What about this led to you? And I do want to hear about what NexKid is doing because you guys just just
Why Logistics? Complexity & Optimization
00:02:42
Speaker
launched. But before we get into that, what about this was interesting enough at Sedna that you were like, I'm going to do another one. I'm not going to go down the email collaboration path or the generic things you learned about startups from being an adventure-backed company, but the specific things I want to work with these same customers again and I want to work in this universe.
00:03:06
Speaker
Why? Yeah, but it's funny. Actually, at Sedna, we had a similar thing that we hired ah bunch of like we hired about 100 people in the time I was there, ah bunch from some supply chain background, some from outside supply chain. And those that came from outside supply chain tended to have a kind of immune response one way or the other, which was they were either kind of in and out after 18 months, never to work in supply chain again,
00:03:29
Speaker
or a handful of people who yeah now have stayed at Subner a long time, but we've got now colleagues across the industry on both the kind of maritime shipping side, but also across the freight forwarding and logistics side across the industry. And I think those's i think people have ah sort of one type of response or another. For me, logistics has this kind of It's just this wonderfully fascinating problem space with a wonderful set of people.
00:03:54
Speaker
So you have this constant need to both, yeah you're optimizing the supply chain, which is an enormous system, but in a hyper-local fashion often. So you have individual people who are trying to make the best decisions on a single cargo or in a single office,
00:04:09
Speaker
While at it's at scale, we are trying to ultimately impact how the world gets clothed, fed, heated. And this interplay between the micro decisions that stack up to this macro optimization, just an incredibly fascinating problem set to tackle every day and to do our little bit to potentially make it 1% better.
00:04:29
Speaker
And you combine that with a set of people who just, I think, they for yeah The people in this industry tend to be in it for years and years. They fall in love with a set of problems as well. And so I think it's a kind of intoxicating space to end up in.
00:04:43
Speaker
Well, congratulations. You're officially afraid. Sorry to inform you and if you didn't know that, but you're ignorant. So tell us, give just for context, give us a little bit about what you guys are doing, what you just launched and kind the vision is. Yeah.
Nexcades Intelligent Automation for Forwarders
00:04:57
Speaker
So at NextGate, we build intelligent automation for forwarders. And so what that looks like is we build end-to-end products that forwarders can deploy in critical workflows within the of shipment lifecycle. Today, we focus a lot around the rate lifecycle. So our three products are initially focused on rate procurement,
00:05:18
Speaker
spot quotations and booking and order entry. And we build tooling that and allows the forwarder to deploy that into their existing workflow, whether that sits in email, in chats, integrated into their online portals, then to bridge the gap between the unstructured, bringing their team in when necessary, but also all of the structured data they have access to, perhaps across many fragmented systems.
00:05:40
Speaker
So i would imagine, or actually I'm certain, because I also do software, that one of the great challenges when you're going into something like the rate business process is there are existing processes, and even more so than processes, people who have to change. And I know at Sedna you had a similar thing because you literally taking away someone's most precious thing in the world, their outlook, right? And you're saying you're going to do this differently.
00:06:12
Speaker
What did you learn about change management and how's that informing what you guys are doing?
Change Management & Process Understanding
00:06:17
Speaker
Yeah, I think one thing that Bill, the founder, used to say is often to make a process better, you have to capture it first.
00:06:23
Speaker
And so I think one of the things that we have seen limitations of other software is this very heavy-handed approach to change management where you don't appreciates the nuances of why a process is done in this sometimes by some teen way that when you, if you're not as familiar with the problem as the person on a pricing desk or an account manager, it can seem sometimes irrational, but the closer you get to the problem, the more you really get close to it. But by acting in a very rational way, it just perhaps doesn't scale. So the way we take um a very, what we call forward deployed approach, my co-founder is ex-Palantir.
00:06:59
Speaker
We spend a lot of time with our customers really understanding all of the nuances of how they tackle the problem today. And then we go through this exercise of understanding which of those behaviors do we still want to capture and enable, and which of those behaviors perhaps are actually done differently by different team members on the desk, but not for a specific for specific reason, but because that's the way that they were taught or that's the way that they learned the business. And so we try to be as thoughtful as possible in identifying actually which of those nuanced behaviors are important to replicate and which of those can actually be part of a transformation process.
00:07:32
Speaker
And then you have to spend a lot of time actually getting the team on board that you're working with, like understanding the wants and the nuances of the different team members who are going to come on and position to them that this is something that can help elevate them in their role and can enable them to do more and often to do more of the type of work they want to be doing, which is ah speaking and spending time with customers, being on the phone, being in the field, rather than manually rekeying data and pulling together spreadsheets and emails.
00:07:58
Speaker
So I'm going to double back on the term forward deployed for a second.
Forward Deployed Engineers: Context & Software Building
00:08:04
Speaker
Yeah. Because that is a hot topic in the B2B AI space, but not something that most of your customers or our customers, they don't even know what that term is. And sometimes they're experiencing it now without even, without even being able to label it, but Explain what Forward Deployed means why we need it now and we didn't necessarily need it for other products or maybe we just didn't know.
00:08:34
Speaker
Yeah, I think it's a very trendy term now, partly because the Palantir stock is ripping so much, but Palantir, a large US s AI and data company, and popularized the role.
00:08:46
Speaker
What we mean by Forward Deployed is that our leading and our best engineers and our team come out in the field with our customer facing team members to spend time on the desk with our customer and understand it. so The prior abstraction where you might have a customer success or implementation person writing up a set of specs and trying to deliver that either with the tools that they have available or asking engineer, creating a couple of tickets for engineers creates this dissonance and abstraction between what happens in the field and what the people who are actually building the software really understand.
00:09:19
Speaker
And by going forward deployed, we tried to completely collapse that process and build both a level of understanding, but a level of empathy with our customer among our engineering org. And I think what that allows you to do is build a much richer, more relevant, more accurate set of products.
00:09:35
Speaker
But why is this more common now? I think in the era of AI, we've shifted from a world in which the AI doesn't do all the work, but it is doing an increasing amount of the work on behalf of our user.
00:09:47
Speaker
And but as a result, we're not necessarily building tools with the perception of, here is my abstract persona of a user who uses my tool in this way. And it could be a Monday.com or a Microsoft product or a supply chain product. We're now thinking about how does this user execute this piece of work so that when we send them a piece a quote to review or we have extracted data from ah documents, that the AI can do it as well as the best person on your team.
00:10:16
Speaker
In order to do that, our end user and our product it needs to understand the nuances of your workflow just as well. And so I think collapsing that distance between engineering and customer is incredibly important in this era.
00:10:28
Speaker
So if I was a skeptical investor who didn't know the pounds here stock price, or I was say a CIO at a freight company and going Salesforce didn't need to send people into my building. And I'm like,
00:10:47
Speaker
What makes this scale? Like, is this a short-term problem while the AI tools are getting better and we can productize them? Or do you think this is a groundswell kind of shift in the way that software is delivered?
00:11:03
Speaker
Sorry to go with the hard ones. No, I think you're right because we think about it a lot in terms of how we can scale our company. And I would argue that actually with Agent Force, Salesforce are going to be deploying FDR, sort of deployed engineers in the field before long.
00:11:18
Speaker
But one of the reasons it works for Palantir is their average contract is about $2 million. dollars And so you can amortize the cost of a couple of bright but young engineers going into the field if you're going to build software.
00:11:30
Speaker
is more accessible for a wider audience of customer. Ultimately, you've got an economic problem of how do you rationalize the cost of a very expensive engineer spending a lot of time in your
Scalability of Forward Deployed Engineering
00:11:40
Speaker
customers' offices.
00:11:41
Speaker
For us, each customer and even every office might have their own nuances about how they handle a particular freight workflow. These are often unique and novel combinations of understood concepts as opposed to this person has created this entirely new way of executing a workflow.
00:12:00
Speaker
And so for us, that may be specifically how you handle non-stackable cargo or hazardous cargo. We've seen yeah a handful of half a dozen, a dozen different ways based on different SOPs and different requirements around your agent or your supplier network.
00:12:16
Speaker
But that it requires some level of customization. But each time we're building, we're thinking about how do we rationalize this back into a core concept so that the end plus one of the next customer can benefit from that in a faster and more effective way when we think about configuring these deep concepts.
00:12:32
Speaker
If you're not building software with that in mind and you're taking a very horizontal, unopinionated platform approach, and you're using forward deployed engineering to deploy all of the industry context all of the nuance into your software from scratch every time i probably don't think i will scale unless you can get to those million dollar plus contracts off the bat and so i think we think about it as being a tool in an era in which we need 10x more domain understanding to build great software it is a sort of a mechanism for us to fast track
00:13:05
Speaker
deeply understanding all of our configuration options in the future. And maybe that will get to 20, 30, 40 for lots of these little workflows that we can eventually bring together much, much more quickly. But it is it is for us, it's a tool to build great software faster, but we think it will scale a long course of time.
00:13:22
Speaker
So if I was a CIO who wasn't used to this and I needed to quickly develop a bullshit detector for people coming in and pinching me, would it be fair to say, just to kind of summarize this, that the difference, I could look at two companies and try to figure out whether one is a consulting shop who is trying to build software and one is a software company who's using forward deployed engineers.
00:13:49
Speaker
And the kind of distinction would be to ask them how much of what you were building out of this is going to go into a general product release and how much of it is just going to sit in a folder called my company name and not loop back into the core product.
00:14:11
Speaker
Yeah. Is that kind of the scale that you put things on both sides of? That's definitely one area to dig into because if your provider, your vendor is not doing that, then the code or whatever they produce for you as the CIO, it's not going to scale.
00:14:26
Speaker
They're not going to put as much love in it in six months or 12 months or 18 months time. And so you're going to have the same typical problems that you got from custom built software for the last 20 years. The other way that I would turn my bullshit detector on is if you're working with a vendor who knows your use case, ask them how they've handled similar problems to the ones that you might face.
00:14:46
Speaker
Take a nuanced approach to poor preferences within their customers or handling hazardous or non- non-stack or other types of out-of-gauge cargo. ask them how they've handled it with their other customers in the past and how that turns up in the software.
00:15:01
Speaker
They may be building some kind of customization or adjustment for you, but if they can't clearly articulate how they've done that in the past, it probably means that they haven't actually lived to that problem at all.
00:15:12
Speaker
That's fair. couple of things that happened this year as we're getting to the end of it at Chain that I think are interesting corollaries. One of the things we did around the springtime was we made an internal statement or I made an internal statement. I said, code is no longer secret.
00:15:29
Speaker
So instead of building forward deployed engineers and calling them that, what we actually did was we took the role that was our business analysts and we said, you are now allowed to write the code instead of the spec, right? Which I think is effectively like we came at it from a legacy perspective. we We had this role, this business analyst role, and the big change we made was saying,
00:15:54
Speaker
You're not allowed as a business analyst to go into the core processing engine of chain because you don't have enough engineering training, but with the combination of AI assisted code and what have you, if you realize that we need six more fields mapped or that the way that we're handling carton combinations in relation to the items inside of them in a plugin to system that is different,
00:16:17
Speaker
then just code it and then document what you coded as opposed to writing a document and then asking someone to code it and they'll get it. Probably equally wrong as you're going to get it on the first try, so you might as well just do it yourself.
00:16:30
Speaker
um and That was kind of the legacy math into that and I think for A lot of internal IT groups at forwarders and what have you, they would potentially benefit from internally taking that mentality that we just sort of came up with this term, code is not sacred, but this isn't a thing to be guarded anymore.
00:16:51
Speaker
Yeah, like I think the entire generational shift in AI is incredibly empowering for up and down the stack for your fully non-technical user who may not get something into production, but they can actually try new tools to be able to kind of express themselves in a way to their internal IT t org in a way that they couldn't before, because they can go and use Lovable or Bolt or any of these coding tools and they can get something that looks reasonably plausible and can work in a way that they can then hand that off to someone which has a level of richness they never had before.
AI's Impact on Engineering Roles
00:17:24
Speaker
have a semi-technical folks who are now equipped to be able to, as you say, kind of shift from writing specs into writing code all the way down to, I'd say, ah, you know, and we've hired, we've had the benefit of hiring in a kind of AI first era from the start, but your kind of highest and best engineers are now more leveraged than they ever have been before to be able to write more code and execute in a way that was never previously possible.
00:17:49
Speaker
So I think one of the things that would be scary for me if I had come through the pure engineering path is there's a cliche, at least in my generation of engineers, that I got go talk to the customer today.
00:18:04
Speaker
right And now that's the job. right like The really good engineers, and I think Amazon actually but AWS sort of pioneered a lot of this because they always made their products and continue to make their product teams available to the customers. But in that case, it was often programmers talking programmers.
00:18:23
Speaker
But now it's, oh my God, you're going to be in the room with the CFO and the CCO. Yeah. kind of coding on the fly while they're talking, not hopefully literally, but you know, I have seen that happen, but you know, this idea that soft skills and all of that, like, how does that go into your thinking about hiring?
00:18:44
Speaker
Yeah. So I think we have probably a very different interview process to lots of other companies as a result. We actually lean into hiring like very strong senior generalists. And so I'd say the composition of our engineering org would have looked very different if I was building a company from scratch three years ago in terms of seniority.
00:19:02
Speaker
But also we have I would say generalists who can work across the entire stack, but spike in one of three areas. For us, that's platform. So they build out an underlying tool set, both from an infrastructure perspective and for the tools for our product engineers.
00:19:16
Speaker
And then we have AI and products as two separate skill sets. so But within each of those, we have two technical-based interviews. One is a coding interview. The second is a vehicle-weighting, is a problem-solving interview, which actually involves zero code. And we give them a very abstract problem, sometimes a supply chain problem, sometimes something that's in a slightly different domain.
00:19:38
Speaker
But we give them like a problem statement delivered by a customer and actually they have an hour to get to ah solution to that problem. And we spend five to 10 minutes in the end discussing how they would implement that technically.
00:19:50
Speaker
But we really gear up the relative indexing on their ability to problem solve, ask good questions and get to the heart of an issue they've never heard about within 45 minutes to an hour.
00:20:01
Speaker
And I think the traditional software engineering process would look nothing like that. So you guys are at release stage, right? You just launched a few weeks back from at least from more recording this.
00:20:12
Speaker
And so you have the luxury of being able to answer this question without 150 or 200 customers getting mad at you and thinking you're talking about them. But knowing what you're headed into from having dealt with this customer base before, what do you wish...
00:20:26
Speaker
buyers in logistics would do better? What is annoying about the customers that they could improve on that's going to make it hard for you? That's really good question.
00:20:37
Speaker
I would say probably the first one that makes it hard on us, but makes it hard on them is understand their buying process before they start purchasing software. And so understand who in that organization needs to be involved in this process. What are you trying to achieve by buying it?
00:20:57
Speaker
How are you going to evidence that in your decision making process and what timelines Are you making decisions on? I think those are just the basics of buying software.
00:21:09
Speaker
But in an industry where perhaps software change is not as frequent, and sometimes if you are an operational leader or a commercial leader and proposing a change, this is not your day-to-day and by no means are you or should you be an expert in it.
00:21:23
Speaker
But all of those things can both hold you back, but also can be challenging for a vendor when you don't have understanding of that process up front. So I'd say that is probably one part and it often leads to friction both internally and externally when either requirements change or timelines or understanding of what success means might change.
00:21:43
Speaker
couldn't agree with you anymore. Yeah, it was interesting because coming from being CIO into the software space, When we first brought in external investors who were not from the space, they started asking me some questions about buying cycles and personas and decision-making processes at the customer.
00:22:05
Speaker
And they were asking me to draw out the map of the buying cycle and decision-making process at Freak Forward. And I was a dance CIO and I had no idea how to explain to them. was I don't know.
00:22:17
Speaker
They're like, well, you know, is it an end of the year discretionary spend or like, where does this get put into the planning cycle? of You know, from my experience at midsize and small, you know, never worked at a, you know, a Marist or the SV, but like,
00:22:32
Speaker
It was like, no, stuff just sort of comes up and then we decide whether going to buy it or not. And who's involved it kind of depends on who's in the room and who's mad at who that day. And it is actually i like i agree with you. And for anyone who's listening, knowing your process is so unbelievably valuable to being able to either decide to buy something or decide not to buy it quickly because, oh my God, these software vendors hate the fact that you don't know that you actually need your CFO to sign that piece paper.
00:23:04
Speaker
yeah right And then really you're not engaging them at the beginning. you Sure. And look I think the very best trained account executives and sales reps can help customers on this journey. ah Without a doubt, the very well-trained reps they use and some of those who we work with at Sedna were incredibly helpful in helping their customers think about how they structure that process, what sort of analysis they wanted to do internally, what analysis they wanted to do externally and give them a path to a mutual close.
00:23:35
Speaker
But sometimes buyers have a resistance to being pushed one way or another by a vendor with good reason. And other times, you know, you're busy, I'm a busy founder, and you can't always coach every person you're working through the process. And so, yeah, I think that would be hugely beneficial. And I think then the flip side is it's kind of the same with, you what does a great implementation look like? And for us, it's not just getting people over the line of purchase, but You know, we're extremely customer centric at Sedna and that is a hard and sometimes overwhelming change management process. But ensuring you put as much effort into the change process in the implementation process as you do into the buying consideration is super important when we're hopefully talking about five, 10 year decisions and investments.
00:24:17
Speaker
So what has you most excited about future? What really got you getting out of bed in the morning?
Logistics Industry Embracing AI & New Software
00:24:23
Speaker
I think... in one sense, with the sheer pace of change in in this industry, but across the entire AI space.
00:24:30
Speaker
I think I've probably seen more willingness ah of the freight industry and logistics industry to engage in new software in the last couple of years. And in the last decade that I saw both looking at from an investing and from an operating perspective,
00:24:44
Speaker
And then the v the tools that are at our fingertips to attack a set of problems that were just previously just too gnarly, they were too challenging, because the kind of sets of technology available to us into the more traditional regex and data extractions and deterministic workflows just did not work for an industry as networked, as sometimes unstructured and as real-time as the supply chain, and is you now have this approach that you can deal with both a lot of what you guys focus on at Chain, of bringing together a lot of structured data and integrating and bringing together a lot of fragmented systems, but being able to both execute that centrally but execute it at the edge because you can now be in someone's inbox and help them handle on a sort of individual scale some of those decisions and pull the right data at runtime, at the time of a decision, and not have to have all of your systems implemented in order to do so.
00:25:33
Speaker
think it makes the opportunity and kind of the potential of some of the technology we spent so long working on to actually get implemented so much greater. So I'm going to try to distill that. Sorry. Yeah. No, no, no, no. it's It's a complicated set of concepts, but you know, a picture just popped into my head of the watchmaker. Like a watchmaker does not get to have a non-deterministic world, right? Like they, you know, the we'll picture the old man sitting in Switzerland in the workshop, all the little gears and pieces, and that watch is going to operate for a hundred years.
00:26:11
Speaker
based on exactly how he assembles it with no changes the day that that watch goes out the door. right And so that's how we have built and sold software in the past in this industry very specifically.
00:26:27
Speaker
And we wrote s SOPs to make sure that no variation ever happened that would make the watch break, right? Like you can't put the watch in water and you can't use the watch you know under these pressure circumstances and and don't shake the watch too much and all of these rules for people so that the watch is going to work because we cannot open the watch case and change the gears and the watch ever.
00:26:49
Speaker
And now we're saying is we're not really going to have the watch case itself becomes malleable all the time, right? This is where the analogy breaks. But this idea of deterministic and non-deterministic in our industry is probably much deeper than a lot of others because The reality is we never lived in the watchmakers world. like Banking lives in the watchmakers world because I define what the mortgage form looks like.
00:27:17
Speaker
I give it to the customer. They are required to fill out the form and I get the form back. And I have a set of regulations that define the world in which the form operates and all of this.
00:27:29
Speaker
Well, we're all on the freight business, right? So there is no, we can't tell the world to work the way we want the watchmaker to design the world, the the environment. Is that a, I know it's I've now turned my summary into its own rant, but are we, are we honing in on something here that is a mental shift in the industry?
00:27:46
Speaker
I think so. Yeah, I think we're heading to a technology paradigm that actually more closely reflects the real world that we've lived with. We've spent 25 years trying to condense what people do in the field and every day into a set of milestones and a set of structured data and a set of SOPs.
00:28:06
Speaker
that everyone in the knowledge that sometimes you vary from that and sometimes there's this exception and sometimes adds up and it ends up being an awful lot of the type. And that we now have the ability to take those SOPs and combine them with to incredible amounts of potential context To more replicate that in a computer than simply to take your watch analogy, X must equal
Adaptable Software Solutions in Supply Chain
00:28:28
Speaker
Y. And if it doesn't, it breaks.
00:28:30
Speaker
And if you build software that breaks when there's an exception, i think that is ultimately flawed when you're dealing with something like supply chain. That's, I think, a great summary there. So tell everyone where they can find out more about what you guys are working on. And and we'll wrap with that.
00:28:45
Speaker
Yeah, so where ah our website is www.nexcade.ai. You can find me on LinkedIn and not very much on X these days. So DLJ Bailey on LinkedIn.
00:28:58
Speaker
I appreciate you opening it to www.nexcade.ai. You don't hear that all that much anymore. Cool. Well, thanks so much for being on. It's it's really exciting. I'm very enthused to see what you guys are building next. Cheers, Brian.
00:29:16
Speaker
Thanks again to Dan. It's always fun to chat with Friend and we'll have a link to Nextcade down in the show notes as well. Make sure that you're checking out Chain.io on LinkedIn and on our blog. We've got some really interesting things coming out. Again, AI is a buzzword, but it's also... a product feature and we're launching some really interesting things specifically for dealing with those huge spreadsheets that you still have people searching through Magnally every day to find exceptions. So keep an eye out for some new product releases in that space and hope you enjoyed the episode and I'll catch you again next time. I'm Brian Glick and thank you for listening.