EP39 | AI, RPA, ML & QC: Supply Chain Impact Simplified ft. Daytona

Speaker A: AI is overrated.

Speaker B: Long term? No. Short term, maybe.

Speaker A: Do you believe cognitive biases affect software design and user experience? Absolutely.

Speaker B: Yes. Thumbs up. Yes.

Speaker A: And is New York pizza better than Chicago pizza?

Speaker B: Uh, so I actually, I love that question between the two. New York, but for pizza in Italy, Napoli pizza, uh, marinada. Best in the world for me, but yeah.

Speaker A: Welcome to the supply chain tech podcast with Roambe. Scott Meares here, senior marketing manager at Roambe and your host. We thank you for joining us today. In this episode we speak with the co founder and CEO at Daytona, Ivan Burazin. We strip away the jargon and break down AI, uh, machine learning, robotic process automation and quantum computing for supply chain leaders. Next, we dive into user experience, discussing how SaaS companies can simplify complex tech without compromising its power. And finally, we explore the importance and strategies for nurturing smarter developers to shape the autonomous supply chain of the future. Welcome Ivan. It's great to have you on.

Speaker B: Thanks for having me.

Speaker A: Yeah, it's really great to have you on the episode. I'm excited for this one because you have such an interesting technical background, um, and it's really interesting what you're doing and I really feel like we're going to answer a lot of questions about a lot of buzzwords that I must say as a marketer we use a lot in our marketing and I know other companies, uh, do as well and a lot of the time people don't actually know the ins and outs of what they mean. They know the surface level, first couple of sentences of what they mean. So I really am excited to just dive into your brain I and just get those answers out you. So very much looking forward to this episode.

Speaker B: Absolutely. I have to just add on that like when I was younger and going to like, like starting off my career going to these conferences, you see all these people talking about these buzzwords and like, oh, everyone understands all this stuff and then when you grow up it's like, oh, they actually don't understand it for the most part. Right. It's like, oh, we just have to throw that in there. You get like a very high level knowledge so you know a bit. But like the vast majority probably don't, especially when it's a very, very new one. So I think that's super interesting to touch on.

Speaker A: Yeah, it really is. Uh, I think I see that a lot of events, people can talk for quite a lot of time on these type of technologies but not actually know a deep level of conversation on them. But it can seem in those five minutes that they Know a whole lot.

Speaker B: Absolutely.

Speaker A: Before we dive into that, I always like to kick off with a nice icebreaker. Uh, and I would love to know, you know, having such a, um, developer background and having a big developer team, I would love to know, what would you say is the funniest, or maybe one of the funniest excuses you have heard, uh, for a reason that has been used to explain that code isn't working.

Speaker B: So I'm gonna do one. There's like a, there's a bunch of them, but one that actually happened to me afterwards. And so that is sort of like why I want to use that. And so it was like my laptop got, you know, set on fire, like literally. And then you're like, you know, you call bullshit. It's like, no, your laptop did not get it on fire. And I think it was like two, three years ago. I open my laptop, I turn it on. It was like in a fire per se, but just like smoke ran out of it. It was like, um, Mac M1. So like fairly like recently. And it just died. It's just like the chips got fried and died. I have no idea what happened. So, um, I don't know later on if that person, I never called them up, like, did that actually happen? Or they're just like blowing smoke. Uh, but it actually did happen to me later on. So I think that's probably the most interesting one.

Speaker A: Wow. Yeah, I would struggle to believe that. But now it's happened to you. I'm sure you can believe that.

Speaker B: You're like, oh, wow, I remember that happen. I'm like, oh, okay, so this can actually happen. Right? So yeah, yeah, yeah.

Speaker A: I've not known of laptops just self combusting. I don't know. That's a, that's a new one. Um, and I really like that answer actually. And before. And I really want to now dive into debunking. You know what we started at the, the episode in diving into understanding what the technical, uh, terms are and also the actual meaning behind, uh, the technology out there, like AI, machine learning, robotic process, automation. These three get spoken about a lot in supply chain and quantum computer. Maybe not spoken as much, um, but it does come up at some events. Um, uh, so I would like to also touch on that as well, just because I know that will come up in conversation in later years as well. So if you could just help me really debunk, uh, people's beliefs and understandings of these technologies and just for layman's terms, um, just explain in really simple terms what each one means. And we'll just kick off AI because AI is just everywhere right now. And I think it's becoming a bit of a headache for people. I mean, it's super useful, there's no questioning about that. But what is it and what is it actually doing? When someone says AI is in my software and it's going to empower you, what is it actually doing for that person?

Speaker B: Sure, I actually want to kick off, I'll do the AI one much more deeply. It's just like the quantum one is probably the one that I least know about. And so that one is up and coming. There's a bunch of companies trying to build actually quantum computers that work. And so as far as I know the thesis, it works. Um, there is the quantum realm where things sort of exist in multiple places at the same time and things can do multiple things at the same time. Um, and sort of you getting, harnessing that energy to be able to calculate things, um, is a super powerful tool. And we're very, very far off as far. I mean, there are computers already. We have, um, a customer we work with that actually provides services to help build on top of these. But I think the, the usage of it has not, you know, gotten to a place or the ability to use the, the power from that has not come to a place that has become mainstream and probably still, still take a while to get there. And again, I'm probably the least qualified to talk about that. So I just want to get that off the table. Um, AI. Well, wow, that's a big one. So, first of all, the vast majority of things that we call AI today are just like large language models, which I feel is just like a marketing term that everyone just like slapped AI on top of that. It's like, oh, it's AI, the things that we have in the movies. And people just like, you just get so much more clicks. I feel the media also picked up on that one. It's like just, you know, people get clicks because it's like, you know, Terminator, whatever. It's going to kill us, Skynet, you know, whatnot. And so it's like, oh, it's AI. And then we have, you know, the new term which is AGI, which is probably like artificial general intelligence, which is what we thought of AI back in the day, where it's like actual, you know, it thinks in, uh, in the sense of a human and potentially some theories that they might, you know, find us irrelevant. There's other theories that they actually might not do anything because they have no, um, uh, biological needs, so they actually might end up being lazy. But anyway, that's a complete different story we can talk about another time. But basically, AGI. Sorry, uh, AGI. AI. Um, for the most part, there's other. For the most part we're talking about large language models. Whereas basically for a large language model, you set a, you know, input a prompt, if you will, and you say, um, I want, you know, what is, you know, six times four, or what is the capital whatever, or where can I get whatever? And the large, large language model been trained on a bunch of data. And then it replies, um, to your question by looking at the data that it had, it was trained on. And that, it seems, would be the probably the most suitable answer to what you said. And so for the most part, people are like, you know, when they say, oh, a, you know, AI can think or whatnot, it can't actually think. It is just like, trained on inputs to be able to reply against those inputs. And then for you, it seems that they're actually, um, training. And anyway, so, um, they do a lot of, I think, cool things. Um, they help out. I use, you know, chatgpt, Claude every day, depending on whatnot. But it also, with these sort of. And I think a lot of people have also seen this, like, with the initial, like, oh, wonder, you know, what just happened. This is like, astonishing. You can do all these things, you sort of get to a limit really, really fast. It's like, oh, it can't actually go beyond, you know, whatever you're trying to achieve at this point. So there's a lot of excitement around the novelty. And it does solve a finite set of things in the real world, I think, but really quickly, and we see this with every new one is like, oh, my God, it can do all these things. And then like six weeks later or two weeks later, whatever it may be, is like, oh, it actually can't do this or this or this. And I don't know if that's, um, about us as human beings where we get used to things really fast. And then it's like, not, um, super cool because we're like, um, we're accustomed to that now. It can do these things, but it's still so far off of like, the actual potential, what it can do. And I think a lot of the potential in AI, and we'll talk about this later if you want, is actually in the interface. And so how you as a human can interact with these models and what these models can actually interact with, because if you look at right now, like all these models are basically siloed or constrained inside of some piece of software. So it's like they're inside your application. Maybe they're inside of a Google sheet, they're inside of whatever, but they're not very much across all these things. Uh, I haven't had a chance to try, um, Apple Intelligence, so I don't know, but that seems to be something on the trail where, like it can control your entire phone. Um, and then again, I haven't tried it. And then that's super much more valuable to me because I can go, oh, check my booking and then send a text to someone and then I imagine, I don't know, I haven't tried it yet. It comes out, what, this week or something like that. So, yeah, I'm sorry, um, what other questions were we. Something else was missing?

Speaker A: No, it's interesting. So it seems in simple because in a moment, a moment ago, and you know, still some companies, do they still work out spreadsheets to track their shipments and assets and all the data. So it sounds like if we go really to the core of it, it's just being able to consume thousands, thousands, hundred thousand millions in some, uh, cases of spreadsheets of data, uh, and it's able to analyze all that and give you an answer, uh, based on your questioning to that model.

Speaker B: Sure, absolutely. Especially when you have data. I think it's the most useful when you're there. Like, I use it mostly for like Google sheets and analysis and whatnot when you're doing things, because that's very exact. And so it is, um, like when you're working with AI, it's very much probabilistic instead of deterministic. Like usually software engineers are very deterministic. It's like, you know, we want it. When you hit a button, this happens. Like, it's very, you know.

Speaker A: Yeah.

Speaker B: You know, A to B. You know what's happening with AI, it's like, oh, you set up, you tell it a prompt and it gives you an answer and there's a probability that it's correct. But it also changes every single time. So it's not the exact answer every single time. So it changes. Um, that's also, I think, an issue there as well. Uh, not touching on hallucinations at all, but like just that every time you ask the same question, you get a different answer or a slightly different answer. Right. Um, so that's also very interesting with AI, but when you give them, you know, in the sense of like, here's My data, you know, analyze it and give me an output or a graph or whatever I, I believe, or at least as much as I use it, like it'll give you the same output every time because it's just math. It's like, you know, try to figure out this data. And that for me becomes much more useful. And that's where I use it more than anywhere else as well.

Speaker A: Yeah. And that's where it becomes a huge help within supply chain. Um, especially if software like roaming the many other softwares out there, uh, it really does help in prompting and uh, digesting all those alerts that we have in the shipments and assets. And it definitely works hand in hand with, uh, the other one I'd like you to dove into is machine learning. I'd love you to tell us about machine learning, what that's doing and its relationship with AI and how powerful that can be.

Speaker B: I mean, with machine learning, I was also sort of like the way I understood it always that everything that's not AI was machine learning. And that's. They sort of changed the sort of title. There was a point in time a while ago when like people use, started using AI, but it was actually machine learning. Um, so like there's like nuances to that where I kind of believe that we should probably stay with that. But there's differences in opinion and obviously marketing whatnot. Um, also on the RPA part where you touched as well, I mean RPA is basically just automation. There is no, I haven't looked at RPA software. Now they probably use quote, unquote AI, um, in that as well. But with RPA was specifically like, I as a human being have to click these things, the same things and do the same repetitive task every single day. Can I not do that? Because like we know exactly what I need to do. It is like click here, point here, drop down here, do that. And so they automate that for you instead of having a human do it. It's essentially like if you're in a factory and you now have robots, you know, moving boxes versus humans. It's like that box comes in at that time, you have to move it to this place. And so that is absolutely automated. So I think of RPA basically as like, um, automation of software. The same way you automate things inside of factories. Right. And doesn't work for everything. There's a lot of things it doesn't work for. But where it does, it's obviously very helpful because you don't have to use your, you know, capacity or time or whatever. To take care of that.

Speaker A: Yeah, again, that's been a really nice one that's worked hand in hand with Rome is that it can, for example, create a shipment or log into an account and uh, get a vessel number, for example. Um, it was interesting what you said with machine learning. Are you saying that machine learning AI, are you arguing that they're sort of the same thing? It's just we've slapped two different names

Speaker B: on them so we can go, uh, I mean, this is a conversation as their own. And perhaps we do another sort of podcast just on like naming and branding and how we call these things. So yeah, we can double dull. I double click on that one on a, on one, on its own. And that would probably be interesting because you have people from both sides yelling, um, different things on that. So a very probably controversial one there. Although, you know, naming is very important to people obviously. And so that part especially, especially when touching back on AI, I think that it's gotten ahead of itself in the sense of like that name and people just love to do it because we're all sort of like, like we all like doom scrolling, like everyone's addicted to that stuff. And then so when you attach such a controversial name to something, it just gets more hype around it. And the hype has been, it has been very impressive, um, from a lot of perspectives, but also, you know, underwhelming from others, at least for me. Um, but that sort of keeps it top of mind and I do think keeping the narrative alive is also very, very important for the technology to actually get, continue to get the investments, continue to get people onboarded. So it's not something to underestimate the value of. Just like the branding and naming and the interest around those.

Speaker A: Interesting. Yeah, from a marketing perspective, that is very interesting. So we'll take your summary of AI then for machine, uh, learning as well. And robotic process automation was very straightforward. And quantum computing guys, don't worry, that's not really here at the moment. It's been worked on. I know Google are doing some interesting things, but it's not being integrated very much yet and got some time yet that it sounds like, um, I now want to move on to. Of course there's lots of software out there that's tapping into these technologies, but a challenge that I see regularly and you know, when I speak to customers prospects is yes, you've got all these, uh, analytical reports, you've got all this awesome data. That's great. But my problem is I have uh, five minutes in the day or I have 15 minutes in the day and I just need it to give me the answer in that day. I don't have the time to figure it out. And even with all the trainings you do and, and the retrainings, it's still just, you know, someone else. You know, people get rehired, restructuring, it's a lot to keep up with that retraining. And if it's complex, uh, to analyze the data, it can be quite difficult. So what would you say SaaS companies can do to put user experience first without damaging the quality of the tech behind it? Because I really feel that's not valued as much in a lot of software.

Speaker B: I think it is. And I agree with you. And we have this like in Daytona we have a similar issue like where we want the developer experience, like all our users are basically developers. So like customer experience, user experience, developer experience, whatever. Um, where we really want to emphasize on that. But from, you know, the engineering team being engineers and engineers build all these things for, for some of these things that they actually build out for them, it's one, not a problem. But two, it's also often a very complex task just to make something very, very simple, right. Or very user friendly to speak. And I'll give you one actually very, very transparent example that we were working on and what sort of debate we had internally, right? And so when you work with, you know, with Daytona, basically it spins up dev environments from a git repository and so providers of git repositories, there's like GitHub, GitLab, BitBucket, there's a bunch of them, right? And so when the team was creating the product, to start off, you'd have to pick, there was like basically two dropdowns, like oh, where, which git provider? You know, it was for them, very logical. It's like GitHub, GitLab, whatever. And then you have a second dropdown where we list the repositories from, you know, the one you picked above. And for me that was just like a drop down too much. So it's not exactly to your question, but I'm just talking about the experience of what we can do as, as product People creating SaaS products for people in general. And so that was like, for me that was like two, one step too many. Like why do we have two steps? What is the bloody point of having two steps? Like one, it doesn't look nice, two, it takes longer, you have to think about these things. And so the, the idea was, or uh, what we sort of from the product Perspective is like, how can we make this the best possible experience for the developer without degrading any of the technology underneath? And so it's like, why don't we just have like one dropdown where like all your repositories are listed, no matter, um, which provider it's on, right? So you can have all three and you can have, you know, a hundred, two hundred of them. And so there's very, very much pushback from the engineering team where it's like, well, it's just one click. Like, why is this even a problem to you? Like, why can't. Why, like, why is that a problem? Um, and the second was to actually make it work was a bunch of engineering time or I mean, it's not creating a new product, but like they could have been creating new features. Like, why can't I go do this new cool feature instead of just doing this because of like quote unquote, dumb users, right? And so it's like, well, no, these are not dumb. You just want to make their lives. They only have five minutes and can they get the spin up in the least amount of clicks? And when I think about product, it is always like, what is the least amount of clicks and time I need to get to value and whatever that value may be, whatever your product is solving, right? And so I think that's quite similar to what you're saying right now is like, oh, I have all this data, Ah, how can I get what I need? Right? So when you think about it, I'm assuming I don't know the product, we're not talking about a specific one. The developer's like, oh, there's your data, like, you go figure it out. It's not my job to figure it out for you. Rather than saying, oh, my people, my users want this. Can I make it, ah, you know, as a button, as a report, whatever it may be, a dashboard, doesn't matter. But all of that, it takes a level of understanding the user's needs and two, it's engineering work to get that up and running as well. I think those are two basic reasons why we don't have that in a lot of products and why you look at products like, I always, like, everyone talks about Apple and it's always there because I think it is because they spend so much time on these little details to make that experience so much better. Like, having the least amount of buttons is not a trivial task. Now we have an iPhone that basically doesn't have buttons. It has a few, I think, one, it has four but it had more before. Right. And telephones had even more before that. And getting rid of each button without sacrificing anything in the product itself I think is a very, very hard task. And people underestimate how hard it is to create something simple, um, that actually offers you the value that it should.

Speaker A: That's really interesting, uh, tip. Because I've not had someone say uh, it like that, that how difficult it is to make it user friendly. That's a real insight that I think people listening to this will take on board and think about that because, uh,

Speaker B: yeah, no, I was just going to say if you look at the most beautiful, objectively most beautiful laptop in the world is the MacBook, it's been the same for whatever 15 years. Like it hasn't changed. How many other companies have created that? And almost none. There's like a Microsoft Surface sort of kind of looks and so why is that? That it is the, it is a status symbol. Looks like that because it's the simplest as possible. It's just a piece of gray metal. When you close it up, it's a piece of gray metal with like an apple on it. That's it. If you think about other laptops, there's like, you know, so many ports and shapes and like slides and colors and like, like, nope, don't need it. Make it as simple as possible. But making it as simple as possible, not just from a aesthetics perspective but from a user perspective, is actually really, really hard. And it takes an order of magnitude more engineering work to get to that place. And so that's why I think a lot of people don't think about it. But your users will definitely experience that and enjoy that much, much more.

Speaker A: Yeah. Oh, that's what it comes to, doesn't it? And that's where you know, your customer service can be quite inundated by what they perceive, you know, the customers perceive as problems, things aren't working. But actually it's just because the UI is just making it quite challenging. Um, but that's really interesting. You know, I feel like, I feel like if this was discussed more like that and shows the efforts involved, the cost involved, the uh, time involved to bring the UI up to speed, then I think there'd be a bit more lenience and a bit more maybe participation from customers to support where they can. Um, I definitely know that having a customer advisory board has really supported us in getting uh, their knowledge and the feedback. But of course it still then demands the resource and cost. So that's an interesting feedback that I Think our listeners will be, uh, surprised, but also refreshing to hear.

Speaker B: Glad to hear it.

Speaker A: And I want to understand for supply chain software, um, out there, how would you suggest they can keep flexible and adaptable, uh, to unexpected disruptions in the market? How can they really be flexible as a software and as a platform?

Speaker B: I mean, it's a hard question. Um, definitely not an easy one because, you know, new technologies come out and then the world changes and then, you know, your product might end up being obsolete or it might not be. I mean you look at, it's not software, but you know, Nokia versus the iPhone. I use the iPhone quite a bit because I've been very good at that. And they were the number one company in the world making phones until they weren't. It's just like they're just gone. Right. Um, and it was very hard for that. Obviously maybe with different management they could have. And so one thing is definitely what I think about when running a software company is you have your core product, you have your, you know, your customers, your go, your roadmap and you sort of have to work on that consistently. You have to like, be true to that. If you said you're going to launch a feature, you have to launch that feature. Or if you don't, there has to be a very strong reason. But I do strongly believe in things that we call experiments. And what I mean by experience is anything that is directly or adjacent around your product, your technology, can you make small bets, financial, time wise and, or time wise to try these things out and see actually what happens? Uh, but also be very, very strict in the sense that you kill these things if they don't work. And so we do that in our company as well. I mean, examples of that are aws. Amazon was doing something else, they were selling books. And now AWS is probably, you know, the biggest center of revenue for them in general. And so how do you keep aligned? Uh, there's other things technologically, when we look at, you know, software itself, we a lot of people in creating software today, you do take a lot of things off the shelf, open source projects or others which you incorporate and whatnot. And so can you incorporate it enough in a way that you can swap these things out? It's really hard to think about those as well because like what happens if something happens? Well, you don't know what's going to happen. So you don't know should you invest the time to be able to swap these things out that are maybe critical, maybe not? And so to be able to adapt to these things. So I think it's uh, a, basically a combination of the two things where when you're building your software, one you really think about it in sort of a module format. It's like, if this doesn't work, can I, you know, exchange that at some point? It's never going to be super simple because that'd be over engineering. But basically that it's not. I've, I've worked with, competed with companies, um, that have been locked into a single, you know, infrastructure technology and has been detrimental to them later on because they're like, oh, we won't solve this. We're just like sort of offload it to whatever it is technology and then you can't swap it out for something else. And then the whole product basically has to be rewritten, um, to be able to, to, to address it or to switch to another one and the other one again. The experiments I think is something that are undervalued to people. I mean, Daytona is a fairly young company. We're 15 months old right now and we constantly have a small fraction of the team working on these experiments. We've killed probably five of them already and one of them seems to be actually doing really well. Actually one of them was the reason that we're able to raise our last round. It's like one of the most successful things we did. Which, um, is open source version that's in just got um, it's like at 8,000 stars, it's been launched five months ago, four months ago. It's like one of the top trending GitHub, um, repositories of 2024. I think we're in 2024, right? We are. I can't remember. Yeah, yeah, I think it. So it was really good. It was an experiment. If it hadn't worked, it would have just like killed it. And so I think that is how you sort of keep on your toes and make sure you know what's happening. So in your all case, if you're talking about people are like, oh, how do we fit AI into this? And a lot of people think about we haven't added it specifically yet to Daytona, uh, as well, but we're very conscious of it in the sense of we're not just going to like, you know, slap, you know, an AI sticker. Oh, you have this thing and now it's AI. If it doesn't give value to the user, then no one is actually really going to care. So if you're thinking about this and every company, I believe will be an AI company. Just as every company is a cloud company, every company is a mobile company right now it is. You have to think about these things, you know, not just as a hype but actually deeply try multiple experiments what actually can give value to my user and if it actually gives value to the user then it actually makes sense.

Speaker A: I think I uh, like that. So it seems like you say as well as building your solution and you know, continuously growing that also have some space, maybe even a separate team or time where they're doing that testing on the side and maybe even bringing in would you say even customers that can do betas and tests to understand if this maybe is viable for a future adoption. Uh, and maybe quite a turn in the, in your.

Speaker B: I mean absolutely. And if you. That is absolutely what I'm saying. And I know people are always, oh, you never have enough time, right? You never have enough time, money, whatever. Like never. It's always, it's uh, always a constraint. And as a two person startup, as a 14 person startup, as a 50, as a 10,000 uh person organization, it's always an issue but you're basically risking the, not just risking the life of the company but you're, there's like a potential uh, huge opportunity cost that you missed out because you're just like heads down working on this thing and so maybe you don't have to run it, but someone in the company, at least a bit of time, you know, works on that thing and make sure that it's, it's doing really well. And so there's a, there's a dev tool company called Source Graph and their newest, I feel their most popular product now is called Kodi, which is a copilot. So I think GitHub copilot type product. It is not what they started out doing, it's not their main product but I'm assuming it's probably the majority of what users are using from them right now and that it's not the core thing but they had the, you know, insight or gall or risk or whatever to actually go out and try something else. They probably tried a couple of other things, maybe they didn't, but I would assume that tried other things and this is just the one that I ended up picking up. And so are you. Do you believe that you are the lucky one as a provider of Service, a SaaS company, that the thing that you set out to do a year ago or 10 years ago is still going to be there and that nothing is going to change in the environment? You know, probably Not. And if we look at all the large companies, so you know the magnificent Seven on the stock market, they're all tech companies. A lot of them are doing a lot of things that they didn't originally set out to do. You know, whatever Netflix like they were mailing DVDs and now they create a bunch of content. We can argue about the quality of the content right now. You might like it right not. But like they definitely change their entire, the entire product and the service that they gave. And so you have to be open to those things if you want to continually grow at the pace um, that you set out to.

Speaker A: I think you summarize it really well that you know, are you willing to risk the future of the company and also are you willing to miss a massive opportunity for the company? So you know there's a real future uh, scalability and strengthening that uh, opportunity uh here. And I want to move into the integration challenges so you know, with everyone jumping on, um, so again within supply chain, you know there's providers in visibility, um, there's a couple of leaders and there's you know there's real um, time visibility, um, platforms out there and there's more like aggregators out there. And then I feel that with a lot of um, a lot of problems when technology comes in and they start to understand it, they start to fix it individually. Eventually once we fully understand the problem, fully understand the technology that needs to handle it, someone will come in and just consume all these platforms and bring them into one and then just provide the full um, solution that deals with the problem. Now at the moment we're still in a position where it's yes, these individual companies are very much dealing with a big part of the problem. But for the customers it's very fragmented because they're working with a roombee and a tie and a sense tech, they're working with them all on different parts. You know that can be for different reasons. Um, but of course integrating, uh, not everyone's open to integration or not everyone's got ah, system that's built for this. So do you feel that it's the most efficient approach when a company comes in and just consumes all these this into one system versus trying to actually be a lot more open to integration and maybe being a lot more collaborative with our competitors, whether by direct or indirect? Um, yeah, I just really want to understand what your view is on the integration problem that we're always struggling with. And I know a lot of companies are as well.

Speaker B: I mean if I look at the Space that we're in, uh, developer tools. You have companies like GitHub, GitLab, Harness, CloudBees, um, all these companies have a portfolio of products that serve every single stage of the software development lifecycle. Right. So very similar in the sense of like you have these big companies that have like all encompassing all these services, more or less. Some have some parts of it, some have all. Some have a, like a majority. And it always comes down to are you looking for. It's different for each company and might change as market conditions change. But are you looking for best of breed? So are you looking for the best, you know, that specific, you know, solution and then you as a consumer integrate or they integrate together and you have like multiple vendors for like m end to end or is it just like easier to get, you know, off the shelf? This one gives me everything. Some of the features or some of the problems are not the best. But I don't have to think about it. Uh, your procurement's really happy because it's just like one vendor. It's probably cheaper because they'll discount different sets of the product and whatnot. So it is from a, from a vendor perspective. So we're talking about Roombee or Daytona. It is our decision to say, do we want to be. And by the way, most companies start with one and then they all try to expand across. Like that's. Everyone tries to do that. Right. But like, especially if you're competing at the beginning is like, am m. I trying to right away be best to read in the by far the best in the single segment and then maybe add on or maybe, you know, mergers, acquisitions, whatever, and then add on these things. Or is my plan right away just to take the entire world, like the entire segment. And so that's what you have to decide as a company, but as uh, a vendor also, that's also important there because are the vendors now looking for consolidation or do they actually really want the best of the best? And so my take on it right now as a small vendor to one segment of an entire, you know, life cycle is that can we be the best of breed and while we're doing that, integrate with all of our frenemies so all the companies that are sometimes friends because we integrate together, sometimes enemies because we compete together. And so I'm going after like integrating massively with every single company I can so that uh, when we come to the table, like, we only do this, we're the best in the world, but you can integrate all these others. It is hard, um, especially Market conditions. It can be hard when to say with market conditions now where everyone is trying to, you know, cut down costs, savings, blah, blah, blah. And then your procurement will be, you know, what, why are you paying for, you know, X when you know Y does everything at whatever. And so it's your job, if you're the company to do that, say, well, you get way more value from us because it does whatever better, saves more time, makes your people productive, whatever your pitch may be. And so there's no straight answer to, I think what you're saying. But what I definitely believe is that you should make it, uh, as easy as possible for these companies to say yes to you. So, like, it's the best and it integrates with everyone. That definitely is an easier way to get to yes. Rather than, oh, we're the best. But like, you have to go figure this out because we don't work with these people because we sort of compete on other things. And if you look at the best companies in the world or the biggest companies in the world, they all. I'm going to hit on. Apple doesn't integrate very well with other people, to be honest. Um, they have very much monopoly there. But everyone else, basically, if you look at like the Microsofts of the world or GitHub, GitHub is Microsoft, GitLab, whatever, they all integrate with others even though they compete with others as well. And so I would definitely say that that is the way to go. Unless until you have a monopoly, which you're not allowed to have, but if you do, then you can sort of.

Speaker A: Yeah, yeah, that's, uh, yeah, that's a funny one. So, and I like frenemies. You know, it's. We're friends, but we are also, uh, rivals at the same time. And there's, there's a value for both of us to, to integrate. And you know, we're in the same position. We integrate with both indirect competitors, uh, and direct competitors and you know, we're friends at enemies. It's a bit of both.

Speaker B: But I mean, I was gonna say it is, sorry in the sense of like, there's always going to be customers, hopefully that will pick both of you for different products.

Speaker A: Yeah.

Speaker B: And there'll be some customers that just pick one of you or, uh, the one that can do all of that. And so in that position, it's better for both that there is integration because sometimes you end up working together in the sense of you're on the machine of the client. Right. So it's better that it works together. I think and then it's your job from a go to market perspective to convince everyone that you're the better one. That's, that's a different job, but.

Speaker A: Yeah, yeah, that is a different job. But I like it how you've said it. And you know I do see a lot of positive moves in supply chain. Um, you know, a lot more openings for partnerships and a lot more conversations happening, uh, is becoming much more open, uh, with integrations and, and just conversations between frenemies, uh, to, to really be open and make uh, it easy for the customer and easy uh, all around. So it's, it's great to hear that you um, also support this as well. And I want to move a little bit to uh, the developer side because of course everything we've discussed today, uh, is not possible with a very strong developer team. And of course to make sure supply chains are smarter, uh, we need smarter technology. But to have smarter technology we need smart strong developers that are behind building that technology, understanding it and developing it. So for organizations looking to prioritize uh, developer experience and really make sure they're top notch, where do you feel they should begin in that journey? Because that can be, I know, you know, even hiring the right developers and being building that team can be, it's tough. So where do you feel they should start in that journey to really uh, find the right experience and keep them top notch?

Speaker B: I mean there's so many things like there's so many things where to do, where to start. I have the privilege to talk to a lot of these engineering leaders. With Daytona, it's usually fairly large enterprises. So users of uh, a service like ours, basically anywhere from like 100 engineers, but it's usually over a thousand engineers. So you're talking to these leaders of like very, very, very large enterprises and that have a lot of engineering talent underneath. And what I've heard for the most part is how do we enable our developers to be more productive? And that sounds such like a cliche like how can they make more, like how can they write more lines of code? But it's not just that. It's like there's so many things that end up breaking. Uh, so we talked about at the beginning, it's like why they couldn't commit their code or why couldn't they work. There's so many reasons that stop a developer to actually do their job. And if you can sort of remove as much as you can of that, the developer should be more productive. Like maybe there'll be other things, but they should be. And so, uh, we did also research at Daytona. So Daytona just like briefly just automates everything around the dev environment. So instead of going through readme, opening up ports, installing Python node, whatever it may be, you know, they don't just click on the button, everything's automatically done. And so why we did this is that we looked at, uh, we did a bunch of our own analysis, but we also have a bunch of reports that we read and it comes down to about, we said about 56 on average, but it's anywhere from like 49 to 73% of developers. Productive time is thrown out the window. That is like a huge amount of time. I say productive, so it's not half their work hours, but it's half the productive time when you remove, you know, meetings and you know, PTO and whatever it may be from like the year that they work in on a yearly scale, like more M than half of the time that they should actually be working is lost on either waiting for tests, waiting for builds, or debugging their dev environment. So that's like, that's just like enormous, enormous amount of time that people waste. There's obviously other things as well, and there's different tools that are trying to help out with all these things. But this is something very close to home. So I'm just going to talk from that perspective. Whereas, like, if you can do this on a scale of, you know, a thousand developers, that is enormous. Like why I say that companies. And when we're talking about companies that are trying to solve these issues, if you're a really small team, like three, four or five people, you don't feel that pain that much. And uh, the time that's lost is probably smaller just because communication is way faster between, you know, a handful of people versus, you know, a hierarchy of, in a, in a large corporation. And so when you take that, it's not just a cost perspective that, you know, the, the average salary of a software engineer in the US like $200,000 a year, 180, whatever. Um, and if you like, you know, the productive time, if you look at that, how much is lost, that is a huge amount of money each, each year. But it's not only that, it is also time to market. Like, how long does it take you to get that feature out there? Because everyone's wasting time. But also there is some companies that actually measure this, the happiness index of your engineers as well, are like, are they content? Are they just like trying to work around a lot of bullshit, um, and get the thing done or Is it just as easy as possible and they can just get into flow and get their job done. So anything that you can do as an organization to remove these issues for developers will make them more productive but also more happy because they can actually get to the job that they want to do. And there's a lot of things they can do there, but just on a high level. That is what I look at and that is what I hear because like from these companies that we talk to, they're mostly you know, Fortune 5000 size companies and they're not tech first companies. What I call tech first customers. They're not a Facebook, a Google, a Netflix whatnot. They're not those. Because those companies are as they're called like tech first. And they, if they don't have a vendor to solve a problem, they basically, they're all, it's an engineering company, um, first they solve the issues for themselves, they'll create their own solutions. But everyone else think, you know, aerospace, defense, finance, insurance, whatever. There's like, they have like thousands of engineers and they don't have the capacity or will for the most part there, there are some that do for the most part to solve this. So they're looking for vendors to solve these issues for them. And there are vendors that solve some of them. There are some that sell most, there's uh, some that don't solve those issues. But definitely as a engineering leader, definitely see in your organization what is the bottleneck, what is the biggest one and then try to find a solution um, to solve those.

Speaker A: I really appreciate you so highlighting all those points of really where companies can focus in on. And I particularly like the happy index one um, because it's, I always feel sorry for really engineers and sales because they always get the worst, uh, you know, they always get it in the neck, you know, it's always their fault. Why is this not here? Why is this no why is that deal not on the table? And it's like, you know, it's always lands on them and you know, it's, we're all here, we're all um, we're all trying to get to the same goal. And I think it's a lot of the time it's just not maybe being communicated really how difficult this is and how much uh, resources involved. And they're getting hit with so many different um, requests from customers and different people around the company. I think it can be quite challenging. So yeah, it's nice to know that this company is uh, implementing happy indexes to ensure that their engineering Teams are really focused on the right things because I've definitely seen that in companies of it just them m just getting blasted by everyone and I'm just like, I feel quite bad for you guys.

Speaker B: I mean it's terrible. I look at these things. There's a question I do on talks where I asked people, have they seen the screenshot? The screenshot is for like remote desktop connection. So vdis so there's remote desktop connection for Microsoft and Citrix. Basically a lot of very security constrained enterprises need all the data to be on centralized servers, right? And for that, the way to solve most software is then you just give them a vdi so they log into a server somewhere and they essentially screen share whatever that, whatever they're doing, right? Because everything's then locked into that server. And they do this for software engineers as well. And so the engineer will have, you know, imagine like a Windows desktop opens up and then their IDE or their editor is over there and there's like the frame rate is lagging. You're typing and everyone has been in that place, you're typing. Then you have to wait for like uh, for the letters to show up. And I asked people, have they seen this? And the people that do, they put up their hands. Very few because it's mostly like really, really strict companies or you're old, like I am. And then you've worked generally that's how you solve things. Um, uh, before, in general. And then people put up their hand like yes. And like, do you hate this? And they're like, yes. Um, I only had one person the other day that actually kept his hand up like they don't hate it. I'm like, you can work eight hours a day. There was like, there was like a thousand people in the audience and I'm like, wait, wait, wait. You can work eight hours a day in like in this. And you love it. It's like, oh, no, no, no. I mean it's cool because if I just need to do something quick, I don't have to go to the machine. But I would never work eight hours a day in that. And so to the point like when you exchange something like that for something that is, that feels better for a developer, it's not just that they will be more productive because they can do things faster. It's because they won't hate their whole life because they have to sit in this thing every day. And so I think that's where it's a very sort of simplified view of like what a happiness exists because I would be happier working not in that environment and another one that is much easier for me and probably more productive just because I'm happier, not just because it's faster.

Speaker A: That is so true. And um, that is so important of every role and something that needs to really be taken into consideration for every company and implemented. And just before we sort of get off to our final fun segment is I do want to really uh, put a little bit more time to our engineering teams. And how do you feel small companies can really um, address this concern and demonstrate the value of investing in developer experience. So there's a need in investing, uh, whether that's monetary training time to really keep them top notch. How can they really sell that internally would you say? To assist in driving time and effort to building out their engineering team to make sure they're always ahead of the game and make sure that they're really on top and able to build the best product possible.

Speaker B: I mean I think that comes down to just education of the managing founding team whatever it may be. There are obviously there's data and measurements where developers that are happier have uh, bigger output. So if you set them up for success they will output more. In general of course people are, there are all different types of people but in general if you have a good team and you set them up for success they will output things better. And if you give them a, I'm not going to say mission in the company which is great if you, you can. Not all companies are mission driven. You, they can't all be. But uh, if you really take the time to appreciate, understand what they are doing then I believe you'll have a higher output from them versus oh we're building this thing, you know, someone has to go make it. You are the people that make it. I think it's similar to like salespeople, you mentioned them as well. It's like oh the salespeople are just you know, coin operated, they just make money and that's it. And there's a, there's a similar look, look the way people look at developers as well. Oh they just like type code, you know, drink coffee, type code, they don't care. And so both sides there's more complexity to that, there's more nuance. And if you do, I think it's just like a human thing where if you appreciate the people they're just better at what they do. Mhm.

Speaker A: That's really refreshing tier and so important for it uh, to be again to be implemented within every company. And um, before we get you out of here. I do want to do a bit of a fun thumbs up, thumbs, uh, down segment. So if you could just give me exactly a thumbs up, thumbs down and also just say yes or no, um, or sorry. Just say thumbs up or thumbs down for the audio listener so they can also hear you.

Speaker B: Sure, sure.

Speaker A: Some of them are statements. There's just, it's, you know, let's see, whatever you say yes or no to these. So, okay, let's hit you with sub. So AI is overrated.

Speaker B: So, so I'm in between. I can go deep on this, but I'm like, could be, could not be. We'll see where it ends. Long term? No. Short term, maybe.

Speaker A: Interesting. Yeah. Uh, have you found cloud based supply chain solutions to be more secure than on premise systems?

Speaker B: I will say yes, thumbs up. But I want to add just on this, when we started our company, which is not supply chain, we defined it as a on premise solution stating or expecting the world to go back to on premises. And if you look at the reports that came out the last two weeks from all over the place, uh, On Prem is starting to grow much faster than it did and cloud spend is going down percentage wise. I mean, uh, all in all, cloud will continue to grow, but it'll be at a slower pace and people are, for security reasons, especially because of AI which talked before is going sort of back to On Prem.

Speaker A: Right, that's right. That's very interesting. Um, do you think current supply chain solutions are sufficiently scalable for rapid growth?

Speaker B: I'll just get a thumbs up. Sure.

Speaker A: Do you believe cognitive biases affect software design and user experience?

Speaker B: Absolutely, yes. Thumbs up. Yes.

Speaker A: That's an interesting one. I would love to discuss that more as well. On another episode, have you ever used gamification techniques in project to enhance user engagement?

Speaker B: Yes, yes, we have.

Speaker A: Awesome. And is New York pizza better than Chicago pizza?

Speaker B: So I actually, I love that question. Um, between the two, New York, but for pizza in Italy, Napoli pizza marinada. Best in the world for me.

Speaker A: But yeah, that's wonderful. Yes. And I recently tried it myself and it is, I must say, I concur. Uh, before we do finish off the episode, I mean we've been alluding to Daytona throughout the episode and it's really interesting what you guys are doing and um, you know, the developer questions, engineering questions that we dived into. I know Daytona is doing a lot of support there for engineering team and Ron B. We're doing, currently doing a beta version with you guys and it's interesting to see the support that it's having there. I'd love just to let the listeners know really what Daytona they're looking to achieve and support, uh, people out there with.

Speaker B: Sure. Just really quickly. Daytona is a dev environment manager, which what that means is basically we automate everything for spinning up standardized dev environments so your engineers don't have to waste time on that. They, they won't spend the 56% of their productive time not doing that. It also, because it runs on prem, on a central server, it offers dev environments, um, with bigger scale. So if your machine that you're working on as developer doesn't have the gpu, cpu, ram, whatever, it can auto scale these things on the cloud. And lastly, for CISOs, if any of you see those are listening, it is on prem, everything is fairly secure on your infrastructure and your data, hence should not then be leaked anywhere, which is a very, very important thing. And that's what we touched on a bit earlier.

Speaker A: So, yeah, extremely important. And where can people find Daytona and yourself?

Speaker B: Just Daytona I.O. is the website. Um, everyone can find me, first name, last name. So, uh, Ivan Burazin, LinkedIn, Twitter or X, whatever it's called now, and all the other social networks. I'll be there.

Speaker A: Brilliant. That's great. Thank you so much for coming onto the episode again, we'll give the listeners a little wave together and say thank you very much.

Speaker B: Thank you very much.

Speaker A: Goodbye. Thanks for joining us this time. If you haven't already, subscribe to the Supply Chain Tech podcast with Roamy. If you'd like to support us and invest in yourself while you're at it, visit roamy.com you'll find blogs, ebooks, case studies, webinar discussions, digital solutions, and a bunch of other helpful resources about supply chain visibility and the related technologies. Thanks again for listening. Listening. I'll see you next time.

Speaker B: Uh,