Welcome to DevEx Unpacked. I'm Alan Carson, co-founder and chief strategy officer at Cloudsmith. We're solving the challenges of artefact management and are on the path to becoming the software supply chain itself. In this weekly podcast, we share knowledge from Cloudsmith employees, customers, and other great guests from the software industry. Along the way, we'll unpack topics like the cloud, security supply chains, and of course the developer experience. Welcome this. Welcome to the podcast. Great to have you on.

Likewise. Good to have me, Alan. Yeah, it's good to see you again. Thank you.

Yeah. How are you doing today? I'm doing

All right. Yeah, we can drop little. I'm based in Belgrade, Serbia. It's nice and warm. So t-shirts and shorts, which you can't see below camera. So I'm moving form.

How did you find yourself in Serbia?

Love. Yeah, love summit. My wife is Serbian and we happened to be in Italy of all places, which is quite random, but we were living there for a little while and then we decided to move to Serbia purely because the weather's better than Ireland. So I've been here about 16 years now, a little over that. So yeah, so that's where I landed here. And

For learn upon, you have an office there, right?

That's right, yeah, we have an office. So when we started Learn Upon, I was based here and we were having that conversation, we move back to Ireland, do we stay here? It was just easier for us to stay here for sure, but myself and my co-founder agreed we will give it a go. At the time, it was like Skype, it wasn't even Zoom. Slack didn't even exist at the time, so it was Skype. We had a lot of time on Skype doing it remotely. And as a result, fast forward to today. Yeah, we've got an office here at the team, so it sort of boots on the ground. So that's a lot of YCRB when it comes to learning ol.

Yeah. Well that's amazing. That's amazing. So how did you meet Brenda, your co-founder?

So I suppose not to bore you the tears and anybody listening in, I mean, I would've graduated computer science and I wandered into e-learning, unbeknownst to myself what that was going to be like as a software engineer and never got out of it. I just fell in love with the space. And at the time I was a software engineer in a company, WBT Systems. They were behind a firewall type LMS based there in Dublin and Ireland. And Brendan would've joined actually when I was there as a sort of product manager, pre-sales engineer, sales type persona. And unfortunately for Brendan, he got teamed up at me and I guess we hit it off. I mean, we built a great friendship working together over the space of close to nine years. And that was ultimately where we met, but we got teamed up doing a lot of onsite delivery of that platform. So we were lucky enough to travel to the US quite a bit and we spent a lot of time together and I guess that pushed us closer and we spent a lot of time ideating. We like to work hard, we like to also play hard as well. And so we could fun obviously when we were doing these trips, but we spent a lot of time just ideating and talking and I guess we saw a gap in the market that we wanted to try and go through.

Yeah, that's not unlike my story with Lee. Actually. We for our sins ended up on the same team. I was the development manager and he was the sort of technical lead of the team, and we used to just drink a lot of coffee and have a lot of ideas and think about doing things better.

That's it. That's exactly it. Plus I think when I look back, I dunno about yourself, but I'd say starting off on your own, doing a solo thing, I'd find exponentially more difficult. It wasn't nice to have that kind of support between myself and Brendan. I don't know how you felt about, likewise, Brendan I would say is more the business side. I can very much have a technical discussion with him and he can definitely hold his own, but I was more on the coding side as a result when we were building. So yeah, it's interesting.

Yeah, no, I find founder stories amazing from the point of view of just when was the decision point where you were like, we're going to leave, we're going to start our own thing?

Yeah, yeah, it's interesting.

And was that a big decision? Did it feel like a big decision at the time or did it feel just natural?

Yeah, absolutely huge. You know what I did, there were certain points. I guess I remember distinctly myself and my wife walking around Dublin for easily two to three hours discussing back and forth would I do it, whether not, and weighing up the pros and cons. And we were visiting home at the time, our daughter was asleep at home. My parents were looking after our daughter and we were going between the pros and the cons and eventually through a sort of two and a half hour walk in the circle, we came back and landed on, yeah, we're going to do this. And even still then you're not overly sure there's always dice for sure. Imposter syndrome was a big thing. I didn't even know what it was at the time, but it's like that sort of self-belief, Risa, all the things that can possibly go wrong from mortgages to loans to everything in between.
Likewise, it's quite funny. I remember when we got our first backing only then we told my parents what we were doing. We were actually afraid of telling our parents they just wouldn't sleep. And my wife's parents were exactly the same. So we only told my white parents when we'd actually made our first hire, that was how far we were in. So it was just trying to protect people around us that would probably have sleepless nights. So yeah, it's interesting. I know Brendan was the same. He comes from maybe a bit more of an entrepreneurial background, particularly with his family and so on. So not that makes it any easier, but just those discussions and chats I would've taught at home are probably that bit easier, was a bit different for myself.

Yeah. Well that's amazing. And then what about the core concept at the very, very beginning, did you just think you could do it better? And what was the thinking around the space that you saw and the gap in the market,

I guess to do it better? That's probably the best way to simplify it. And of course you're never really shared Canyon, but the gap that we saw was just a lot of platforms at the time were just really just these big ham things and just got really clunky to use, very difficult to support. And we wanted to solve that. We felt that we could still build the same superpower into a learning platform, but just hide the complexity. So we started out by building, just indexing on configuration. So a lot of our customers at the time used, for example, not to get into the weeds, so we'd use email address, but we also had the option for username if we needed it. But we'd hide that away. And of course when a prospect is coming to us saying, alright, I love your platform, but I really need usernames, we don't have emails, then we could turn it on.
So we just hide that complexity that way. That was one way that we approached it. I think the other piece of it, and again I don't have to get too much into the weeds around the e-learning space, typically speaking, you've got the customer, you've got the learning platform, and then you have the content provider or the content orum tool, and the three of them need to sing well together in order for success to happen. And that was really the piece we wanted to solve for because what ends up happening is the customer is getting information from the content provider who's blaming the platform for not working, and then the platform is blaming the content provider, communicating through the customer, and you have this weird triangle thing that goes on. Ultimately the customer loses, they just get really frustrated and they dunno where to turn. So that was where we wanted the solve for and it's still what we do today.
We go the extra mile to diagnose, identify where the changes need to happen and then discuss directly with the content provider as opposed to C channel through the customer. It's just a quicker reef ultimately as just the customer wins I guess. So those are the two is purely customer support, better customer experience, and really understanding what success looks like for your customer. And I think the same applies. It's not just an e-learning thing, it's just like really what is your customer trying to do? What's the goal? And then can we help them? We're quite happy to tell customers or prospects we don't feel we can help when they'd be better going another direction. So that's another thing that we've indexed on. And over time, of course, when you're starting up in your building, you want everything you need to release, sort of build, you need to pay salaries, but over time and as you build, you can get a bit more focus, which is nice.

Yeah, no, I mean the parallels to Cloud Smith there are very interesting. So we were also on the sort of the simplicity side and kind of hiding the complexity. It wasn't so much that you still wanted it to do everything that it did and you wanted to be able to support and our case, different formats, different tools that integrate with the product. And we wanted to make why take 14 steps when three will do and you make some assumptions and build in the complexity, but at the same time you can go into the configuration settings and go and change it so that you can get everything that you need. So that that resonates very much with me. And yeah, I mean we should talk about the cloud. So you went straight to the cloud in terms of how you were building this as well?

That's right. Yeah. Straight to cloud I guess at the time. Gosh, Stripe were just becoming a thing. I think the whole SaaS cloud based platforms were just really starting the game that sort of traction. And of course, I remember at the time we were deciding what technology would we use and we went with Ruby and Rails. We just thought, well if Stripe are using Ruby and GitHub could scale with Ruby and Rails. And we thought, well, we can do it too. Of course, I remember looking at PHP and glad we didn't go that direction, not to diss any PHP engineers, but at the time it was more sensible for us to go with Ruby. It was just faster to build and it was good platform as a service providers there. Like an engine yard at the time really helped us just get up to deployment. You could deploy at scale really quickly with a couple of clicks, a button. You didn't have to worry yourself with the whole CICD and deployment. You haven't got time for that. You've got to build products. So it was good platforms there that could help us do that at Scaled. So I remember we were thinking, would we go PHP or Java? I'm from a Java c plus plus background or Ruby. So we've went with Ruby,

Right? Yeah, no, I for my sins have also done Java and c plus plus, but we ended up on Python. We went the Python route instead. Amazing. Sorry, and this is an interlude, did you say digital ocean there? Who did you use to do the

Engineers? It was engineers, yeah.

Right, okay. Alright.

So they were sitting on top of AWS as well. I can't, we did a one provider before that where we were kind of doing it ourselves, but it was like we hit a certain point of scale where we needed to flip into engineers. They were just able to scale us better. Do you still use that? Very, very similar to Digital Ocean. We don't use that today. We would've pivoted in, I'm going to say 20 16, 20 17 into our own environment. So we basically, we stayed with AWS and we still are with AWS, but we just pivoted off the platform as a service and then we've done all that. So we have our own info team now, SES and so on that would look after that side of the house.

Right, okay. Got it.

Yeah.

And have you ever looked at other cloud providers, just out of curiosity? We have and it's been an interesting couple of conversations.

Yes, I'm not going to lie, we have, but what I would say is that it comes down to across, I think first thing for us, it just wouldn't make sense, but even from a recurring monthly billing point of view, but likewise just the sheer migration process of all that, it just would not make sense. We would rely quite heavily on some of the stuff that AWS would provide plus the resilience and uptime. It can argue with it.

No, it was years ago. It might have been four or five years ago now that we did look at Google and we were shifting a lot of bytes around. They obviously support YouTube and have some pretty cool technology in the background for that. And so we were kind of attracted by that at the time. But we decided, and I'm so happy that we did to stick with AWS and they have been a great partner for us over the last four years and really we've really got a good relationship and really good access and get to hear about early access features and they've been helping us quite a bit recently. But yeah, no,

That resonates. We would've had the same experience as Steven recently. They've invited us to workshops with them. To your point, I've just shown us early access stuff, particularly from an AI perspective and what's going down the track that it's really helped us to think about the future and where to index, where we might need to bring product. So no complaints there. To your point, it probably boils back a little bit to the product itself, depending on for us, content storage at scale and that kind of thing, scale and throughput is important for us, but if you've got different needs perhaps is a different provider, that's better.

So you and I met recently in Japan. How was that for you? How was the trip for you?

Yeah, Japan. How random was that Rice? It was amazing, honestly. It was amazing. I knew that experience of the ER and young finalists and that kind of stuff, it's intense, but as I reflected on it, it was a massive class and actually what you can push yourself today and in the shortest space of time, it's cringey. There's the video online. It's like the video that broke the internet. It's like Arnold Schwarzenegger is one of these motivational speeches, but he talks basic sleeping faster and I think that's literally what we all had to do that week. We just had to sleep faster and get more done and it was great. Absolute fantastic. Really, really great experience. A lot of connections. Obviously we're still chatting, which is great. We had good chats on the buses between the different events and so on. But yeah, just an incredible bunch of people to be involved with, I think. So very, very excited about that.

Yeah, I mean I find the first year the most difficult just because there's eyes on you and you have to get up and do your pitch, which I think was the last day you had to wait all week. That's right,

That's right. Which is advantageous. I don't know about you, but it's kind of like you get to see during the week what the rhythm is and you kind of get a sense of, okay, that's the time that we have. And so that helped. But at the same time, yeah, you're building it up in your mind and getting the anxiety levels increased day by day until you get the call. But yeah, how did you find it after? Did you find it easy to switch off? I think that's the other piece, just from the day to day and that kind of thing.

Yeah, I mean look, it can be difficult if you've got a bunch of things that are happening on in the background and you want to listen to everybody and you want to be talking to people and you don't want to be on your phone or your laptop. And actually it can be a bit of a struggle when you go back to the hotel. If you open the laptop and like you said, you need to sleep. You don't get that many hours to yourself. So no, I mean it is a bit of a challenge. I think going into it the next time around you'll have a better understanding of how much time you've got and that kind of helps. You could put a bit of prep in beforehand.

Yeah, that's it. I knew the initial meetup and Roger was talking about it's really intense and you got to be prepared for it and so on. I didn't quite know what that meant, but it definitely brought a whole new meaning of intensity to me. I know Brendan was saying the same, but it was amazing. Absolutely no regrets. Just learned so much, particularly with the backdrop of Japanese culture. To me it was just a masterclass and attention to detail. I really appreciate everything just from the clean streets to just how they approach people and how they respect each other. It's just to give each other time. So yeah, really, really cool.

Yeah, no, it was an amazing trip and I hope you go next year as well. There's not that many software people on the trip, so we have to stick together.

That's it. Yeah, it's neuro have to find each other. Right. I was kind of say it was a bit apprehensive I guess there's a lot of, I dunno whether you're part of Endeavour as well, but there's a lot of CEOs in the groups and so sometimes they'll be a little bit out of my depth when they're talking business. So it's nice to find the techies in the crew.

Yeah. So when you did your pitch, you were talking about some pretty big numbers in terms of how you've kind of grown the business and what has it been like trying to deal with that scale over the years?

Yeah, it's like spinning plates because, and lots of 'em because you, as you're building and you're scaling up, you've got to get your a RR growth going. And I'd love to be able to just say to the engineering teams tools down for quarter, we're going to just focus on tech debt and this code style and this infra and all that kind of good stuff. And then we'll come out of a quarter and we'll all be perfect as the reality is. It's just as time goes on, the numbers change, different thing, different curve balls come E, the thing that was working yesterday decided to just break and so on. And it's just a continuous kind of learning thing. And as a result, I think I often describe it, if someone has said it to me, you got to think about it as weeding your garden. You just got to continually look after it and sometimes you decide to replace the barbecue, sometimes you need to add a barbecue, whatever it might be.
But you got to just continually look at the garden and I think that's what we're try and do. It's difficult to get that balance and I think as a founder, that's probably one of the founder curses, you think you can do everything all at the same time. You just got to get super good at ous, sort of prioritisation and appreciation for just, sometimes things take a little bit of time to get done. I think that's the other piece. So just trying to find that time for teams is important just to focus on be it tech debt or just to carve out a bit of time. Honestly, we still struggle with it and likewise every company does. I dunno whether that resonates with

You. Oh yeah, a hundred percent.

Yep, everybody does. The problem for me is you read online blog posts about these, here's how we solved all the world's problems with technology and then coming from certain companies and it just looks like this crystal glass skyscraper from the outside looking in and literally when I go in and start talking to some of these companies, you realise it's just kind of held together. I think that was a quote that was sent to me at one point and that's the problem. So it's trying not to get ahead of yourself. Sometimes I think as part of it within the team, take it day by day. You can't solve all the things today.

Yeah, and do you have a VP of engineering that you work with?

That's right. Yeah, we have VP of engineering. So as I guess as a founding CTO, I'm more the customer facing CTO. My last pull request was back in 2019 and that was in part a coach at the time just telling me, you need to get out of people's way, you need to stop coding, you need to dedicate your time to some other stuff in the business and strategies and things. So that was tough. I miss coding, but at the same time it was the best thing for engineers just to get out of the way. They're way better at it. To me that was one part of it. Then likewise in my teens as a VP of engineering that would run that side of the house, I'm quite happy to have tech discussions and stuff, but I try and stay out of the way. Sometimes I come up with mad stuff that are out of the realms of reality.

It is hard when you think about the way things worked at the very, very beginning because this is what I find at the very beginning, you just were able to make the decisions there in the RI lee would be sitting across from me, we'd have a two second, two minute discussion about something and it would be done at the end of the end it. And when you start to grow and build and expand your teams, then just the level of understanding across your organisation has to grow as well. And so it's about communicating those things and it's really, it's about making sure that everybody's on the same page and know where you're going and that all just does take time. So there's no real way around that. Yeah, so it's the problem everybody has.

That's it. Because inevitably I find when you're trying move fast, inevitably you leave somebody behind. And that's hard because trying to bring all the teams along with you at the same time can be sometimes a little bit too slow. So sometimes you just need to run at something, but it's tough because somebody's nose is going to be put out of joints and it's not intended and that kind of thing. But for me it's like truth in the middle. I don't know you guys find it, but trying to find that balance of almost like a 10 air break just with your team to say, put the brakes on. Here are the things that we're considering. Yes, this could break, that could break, that might be wrong, but let's just go at it and let's just see what happens. And I think that's the important piece, particularly as we go through scale up life, it's just maintaining that nimbleness to some degree. At some point I'm assuming that luxury will just disappear. That's what I hear. At least that's the word on the street. So it's to do the things that we can do today and take advantage of it.

And then do you have a product org as well? Do you have a product department that feeds into engineering and

You

Work with them as well?

Yeah, that's right. We have a whole product org and design. Well, I guess when I say product, I mean product and design. They're two separate teams, but we would refer to it as p and e or product and engineering. So it's the whole two orgs or three orgs in this case all merged together. So we have the concept of table of three, which is typically engineer, manager, PM and design. And then everything kind of flows in and around that. So typically you'll have a staff engineer or senior engineers and so on front end backend or merged in and around that typically aligned to a product area from a learning perspective, say like content authoring or there's some stuff like Ring Shared services, which is all backend IAM authorization, that kind of stuff. But it's typically set up that way just to try and keep teams closer together. Sometimes we get it wrong and I think all companies we've got work to do. There's always that healthy tension between product and engineering and I think that's healthy. I think that's the way it should be, just to push and show up each other. But it'd be important for me just that teams are close together that they feel like they're on the same team,
Whether that makes sense.

Yeah, no, that makes perfect sense. Would you keep your teams fairly small then in terms of engineering effort?

As much as we can? Yeah, it can depend sometimes on the complexity, let's say, or the vastness let's say. But yeah, it'd be typically staff engineering going to say a two, three backend and front end. Typically I would, it'd be small kind of, I guess some companies refer to as squads, we refer to it as teams. That's just how we typically run biweekly sprints. It's very similar how teams get to the end of the goal. It's up to them. So I think autonomy is important. So some would use Kanban, some might say they're agile, but it's a combo of let's say daily standups and just trying to be nimble. That's how I would think about Agile. So yeah, so we've come through an interesting journey there. At one point we tried the full agile approach and it just wasn't working for us and so we pivoted out of that.
So that was an interesting time. It was an interesting learning as regards process and so forth. I dunno about you guys how you's approach it, but every company's different. And I remember someone to me telling me at the time, when you start trying new processes and product and engineering, the problem is you probably won't realise whether or not they're working until 6, 12, 18 months later. And I find that's part of the problem when you make some of these pivots, you don't really realise maybe sometimes until you feel it's too late, but you have to go and go through that pain. So that was an interest and I look back over the years, that was an interest in learning.

Yeah, no, I mean core engineering set up pretty similar to that and we have a product and design function as well. They work hand in hand the way our teams have. We've kind of evolved out of with a pretty solid core team and then we've just been sort of splitting functions off as we've grown. And actually we've just recently split one of the functions in two, which is kind of in and around the package format type work. So yeah, no, we are constantly just evolving and trying to move people to where they are feeling happy. But then of course there's also the case of on call and we have a thing where we call enterprise readiness, which is when we bring on the enterprise that there's a team or a function that can react to how the new company is interacting with the product. And again, at scale we're constantly monitoring and watching out for gotchas and high levels of traffic and all of that sort of thing. So yeah, we've got a fairly well flexible way of working towards it. It's interesting when you say sort of nimble on one hand we have quite a lot of process, but on the other hand we have this feeling of nimbleness and being able to grab people out of places and put them where they need to be, but it's pretty similar.

Yeah, it's that constant evolution I think of process. I think it's important if it's working for you and it's a guardrail sometimes or it helps teams understand how decisions are made or what have you, but bloat definitely creeps in. I'm sure you've seen that as you grow and as you scale, I think it's important to revert back to some processes and say, well hang on, this still makes sense and could we refine it? Could we make it shorter? Could we just ditch it? That kind of thing. I think experimentation is important than that, just having that ability sometimes nimbleness to me is that just the ability to experiment sometimes. Just try something new for a sprint and change something tomorrow and see what happens, that kind of way. So it's that concept I guess of a two-way door. You can always walk through it, but you can walk back out again. I think that's important.

So in our organisation we actually have the office of the CTO and Lee actually has a couple of developers working for 'em in terms of well and a security function. There's a bunch of resource there, and that's where we do essentially horizon two work, which is essentially innovation in terms of what's not next, but beyond next. Do you have anything like that in your company?

Not yet, but it's funny you should mention, it's something that I'm looking at right now and maybe some of our teams are going to be listening. They're like, wait, what? What's he talking about? But I see huge benefit in that and particularly as we get to the future future as we're mapping it right now, sort of the next four or five years for learn upon on the platform, what that would look like. And as I look at other companies that are at our point or a scale just beyond it, to your point, they have perhaps that CTO with a few engineers that are just experimenting and building and prototyping and experiments and around different ideas. I see the reason for that in the sense if we're trying to do it now, we work with Roadmap and OK Wars, and to your point, there's flexibility around that kind of tactical thing you need to jump on, but typically that's reserved for let's say urgent bugs or there's a performance thing or whatever it might be. So it's separate again to that. So that's really interesting to me. I'm currently looking at that. Yeah,

We still, we've had it for maybe 18 months or something, but we're still trying to find our feet with it a little bit because how do you graduate the work back into engineering as well is another challenge to that, right? And there are ways to do it and it helps having great product managers that work with it and that the people that are on Okta, which is what we call it Office of CTO, will go and embed themselves in with the teams for a while and carry it in. The work is also, and we're still also trying to find the water level of how much work gets done. So once you have done that work, do you get it to a certain point and then take it into the teams and get the teams to work with the person to try and finish it off rather than deliver a fully fledged, oh, here's how we're doing this now, which is obviously difficult, then the teams have no visibility into how that had worked. It's a really interesting way of trying to build innovation into the process, but it does of its challenges.

Yeah, definitely. I can imagine just that pure junkiness of trying to bring that stuff back into products and then again trying to upscale and bring engineers and PM design up to speed and what you've been trying to do for the last quarter or whatever, it'll be pretty difficult. I know from just limited research, and again, just chatting to other companies, even one of them billion dollar revenue valuation, the D, it was interesting, they approach it from if it's a siloed product that would integrate into the existing product, but ultimately you build an innovative team around it and build it and then that team remains on it and owns us. That's worked well and you kind of integrate it then into the existing team, presumably there's APIs and so forth talking back and forth. That's interesting to me, particularly as I look like the AI world.
There's this concept of agents and so on and to me what learned upon and in general, that's the future, that concept of these agents talking to each other. I'd like to think that we could actually create some innovative teams, owns an agent, builds an agent that integrate back in easily enough into the product. That's kind of the mindset that seems more appealing to me rather than an innovative team that spends a quarter doing something and then just throws it over the fence to another team to worry about and then move on to the next thing. That would be a bit weird.

Yeah, yeah, no, absolutely. So you've mentioned AI a couple of times. How is that affecting things within your development teams at the minute? Has AI really found its place within your systems?

It's getting there. It's getting there. I look at it from two points of view and it wouldn't be a hall if we didn't talk about ai, AI features within the product and that's fine. We're building those out and so on. We've a roadmap or in AI and in specifically one piece I'm interested in the moment, it's just AI efficiency, not just in engineering but just across the company and how we can use AI for better efficiency. So that's really interesting. Again, I'm curious how you're finding it. We haven't quite found a way to evangelise it yet so that we're consistently and constantly talking about it. I'd say that there's pockets of our teams over the last two months have been really focused on it and they're now coming out of that and sharing it with the rest of the company. So actually August is an AI awareness month in product and engineering and we're doing lots of what we call share our sessions each week.
They're like brown bag lunches, we've got some guest speakers coming in to talk to us. And so it's all with a view of how can you better use AI in the day to get efficiency into what you're doing and so on. I was having a one-on-one recently with an engineer and he was telling me that he's been using AI for let's say a templated code, like automated tests. So he was saying he easily saved two days on just getting AI to generate tests for him that he can then edit and move on and ship. That's a huge saving. That's incredible. Plus it meant for him, he's spending more time on interesting feature building as opposed to let's say the work quote of tests and writing that kind of templated code. Again, I'm curious to see how you guys are finding it. What we've seen, it's great for let's say, and I use the term I guess like lightly senior engineers, it means different teams to different people, but I guess senior engineer to me is someone who knows what to expect.
And so when you ask AI to do something, if a general sense, yeah, that makes sense and then I can edit it and move on. Anything else outside that? I think you need to be super careful. It's great for creating an app from fresh. When you've got zero, it's great, but if you're using AI in a big platform like ourselves, you've got to be super careful. It doesn't know all the nuances, it doesn't know all the backend part of the platform. So the engineers know that better. But certainly it can breed efficiency for sure and no doubt about it.

Yeah, I mean I think we're pretty similar. I think the maturity, it feels like there's been a bit of a sort of, I would say a sort of second seismic shift in terms of how people perceive it. Because when it came out two years ago, there was so much hype and everybody was like, this is going to change everything. And it has, but maybe not quite in the way that everybody expected. And so now I think we're at a point where in terms of how it actually gets used, and like you said, it's really important to validate what it's doing and putting guardrails around it and making sure that you're getting the best use of efficiency, but you're not putting bugs into the code and you understand the logic. When we were doing hiring a lot of the time, it's like you must, when you're going through the exercise, you must understand what the code is doing. It's not a case of it's okay, it works,

That's all right, it's all fine until it breaks. I draw a line to it, let's say stack overflow and review people listening, but that concept that you go and stack overflow, get the solution, copy and paste it into the platform, drive on at some point it's going to break and variably it's not going to work straight out of box. You've got to edit it, but at some point it's going to break and it's going to be an emergency or your own call and you're trying fix this thing. You got to understand it. So that's the piece. Sometimes I think we're missing. I think we get a bit too carried away with the bright sparkly, wow, this is amazing. But under the hood sometimes the practicalities I think are tough.

And in your learning space, which is obviously quite aligned to what AI is sort of good at in terms of finding information, making decisions and providing it back, how has that changed how you've thought about your product and how you can build the product on AI I guess?

Yeah, that's right. It's cringey term was, I use the term sprinkling AI into the platform. So I joke about it in the teens in the sense we're not going to become AI upon anytime seen, but certainly it's putting AI a platform where we see that it can bring value for our customers, particularly from an efficiency point of view. So when it all kicked off and chat GBT and generative AI and that all landed, we started out with using that kind of concept. So just taking, say for example, like an exam generation tooling inside the platform. So you could literally just throw a topic at it, it'll generate 10 or whatever the configuration is, 10 questions, Boolean multi-choice with the correct answers marks, then you can edit it and submit it and Jo done that works well. That's just an example of efficiency or likewise on the learner side from a coaching point of view, like a coach persona that pops up at the end of a course asking you, Hey Alan, how'd you find the course?
What was challenging? How did you use it? So that idea of continued reflection to the course, that's been useful. I think what we're finding with our customers is two sides of it, there's a lot of red tape. So just trying to get AI into your company and the trust factor and so on, it's not just a feature that you turn on that's not like a feature flag thing. There's a lot of work that has to go on in the background, so that can be quite slow. So we're working with our customers through that kind of stuff and helping and guiding. And I think the other side of it is just the trust factor because AI does hallucinate and with learning it has to be correct, it has to be factual and it has to be correct factual. And so our customers are afraid of that piece of it.
So that's where we're indexing on. And so we've been working in the background around some sort of private LLMs and stuff like that. The platform that we're experimenting with some of our customers in a closed beta type scenario, it's been great ai, particularly from a text-based learning perspective, it brings some brilliance and insights and so forth and it can easily summarise. Where it gets interesting is videos and that kind of thing. It can interpret it quite badly or in different ways and so forth. And again, our customers would be quite wary of that. Then just like what's going out to the learner? Who learned, what's the difference between Alan Dez? How did Des get a better market than Alan? Was it because of the modality? Was it the content that the AI happened to serve you as opposed to me? And so there a lot of unknowns there. A lot of questions start getting raised. So those are the areas that we're indexing on and that's the kind of stuff that we're trying to solve for fun times. What a time to be life.

Yeah, no, for all the advantages AI has provided has provided a lot of challenges as well. I was talking to Des trainer at Intercom and he had a sort of similar story. They're all in on AI for their stuff, but he was just talking about there's a lot of extra complexity in trying to make sure that the results are valid and you're doing the right thing.

That's it. But even just I think from a learner point of view, particularly for us as interesting because it disrupts to some degree how learners can learn or could learn. And to your point, there's lots that we could do, but what should we do? So these are the types of things that we're looking at. But in the end, particularly from a learner point perspective like an LMS the platform, you need to be able to manage your users. You need certain workflows and so on. And right now AI is not capable of solving that. Maybe in future Skynet will come and all the rest and it can do that, but right now there's still basic feature stuff that you need to build. So I think it's that kind of balance, trying to find the balance. It's tricky.

Well let's hope Skynet doesn't come right.

I hope so. That's

Bad news.

Yeah, exactly.

And well just maybe that's a good segue. In terms of security then, how do you think about security of the platform and have you had any challenges around that?

So challenge wise, I mean we always overindexed on security, that's how I describe it. But people would say, oh, you can never overindex on security, you can never do too much. But we always had security front and centre when we were building. It's always one of those scare factors of it could bring the company down and so on. So we've always had that culture of security and over the years we've introduced, I've done the same like SOC two and these kinds of things as we go along. For me it's just ensuring that it's in all the things that we do as a company, but it's there to help and guide and so on. But not necessarily getting our way too much. You got to have guardrails and you got to be consciously thinking about it. The world's a weird out place these days and so anything can happen and that's our assumption in everything we build in the product or when it's code reviews and security reviews and so on.
It's really important for us. So as I know about you, but as a founder, one of my recurring dreams was just you wake up in the morning and there's been a breach and I had this recurring dream of FBI, for some reason it was the FBI, it was guys in Navy coats yellow in the back in the office looking for me and her head of security. And that was one of the recurring dreams I had as a founder. But joking inside, it's super important to us when it comes to all the things you do. I remember even introducing SOC two for example. It brings a lot of rigour, it brings a lot of new process and that can be frustrating, particularly as a startup, you want to be moving faster and it's like, oh my god, not more process. You want less, not more, but it's put really great rigour on what we do. That's the important point. And it's just trying to find that balance that's key, but you got to do it as you scale up. You got to get enterprise and you got to enterprise ready and he got to grow bigger and think bigger and ultimately it's a tooling to help you get there. So that was kind of the pivot in the mindset that we had to make.

Yeah, I mean we've also found that it's been good for us to understand what our customers go through because obviously there we we're now attracting bigger enterprises and just from the way they think about security has to have an effect on the way we think about security internally and how they engage with us as well. So we've gone through a few product changes and a few mindset changes internally as well just to close that gap and make it easy for our customers. So yeah, no security. I'll be honest with you. I let Lee have all those nightmares as much as I could. But yeah, no, he's always been very security focused as well. But it sounds like you've approached it in the right way in the best way.

Yeah. Yeah, that's it. As someone described it to me actually, we see, I was chatting to an engineer and he was saying security, yeah, it's a bit like insurance. You regret it if you don't focus on it or you don't have it, particularly when something bad happens. So from that point of view, I think it was a spot on. It was a really good way to think about it and analogy, it was just something that's always there, always something that you think about in the day-to-day. So it probably sot we in, even from a software development lifecycle perspective, we just introduced it into that in a nice way, in a neat way. And today it's just become a natural part of the process. But I remember at the time it was like, oh, have we got to do this really is there no quicker way? And unfortunately security, there is no quicker way you got to do the dot the i's and cross the T's and all the rest. So

Yeah, I mean to be honest these days, I think in order to be successful you have to be, think of it securely. You have to be thinking of a performance, you have to think about everything. You have to make everything work to really drive the business forward and be successful.

Yeah, a hundred percent. Yeah, couldn't agree more with that for sure.

We're getting maybe last question. So what's your favourite part of the job?

I see the people. Obviously as a founder, I'm super biassed obviously towards learning phone, but hand the people that we have here, we've just being really lucky with. So for me, just getting up in the morning and getting to work with is amazing. We call ourselves. So if you're part of Learn Upon, you're a luper. I think every team maybe, I dunno about you guys. Do you have a

We're cl Smithers? Yeah,

Cl Smithers. Okay. So it almost sounds like a blue little smurf or something like that. But we've just been really lucky. We amazing culture. So for me from joke about it for we could reinvent spoons the team have, I think that's what I love about us. So yeah, that's just energising, it's inspiring for me. So everything else after that's kind of secondary.

Great. Well look, I think

That's what's favourite part of the job now.

Oh, the podcast obviously.

Oh well of course. Yeah.

Look, it's been fantastic speaking to you today Des I really appreciate you coming on and giving some insight into Learn Upon. You've got an amazing business and I look forward to the trip next year.

Likewise. Yeah, hopefully it might be Japan Park too, but no, look it, thanks me. It's great to have me on. We really appreciate it. Good to catch up and chat in an environment like this. Nice.

Alright, thank you.

Good stuff. Cheers.