Speaker 1:
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 the coing, 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, Tom. Welcome to the podcast. Great to have you here today. We're really looking forward to this conversation. You and I have known each other for a long time. It'd be great if you could maybe give us a little bit of background on, I guess on how you met me. I mean, that might be the best place to start is day one and N

Speaker 2:
Yeah, a long, long time ago at this point, I think you're right. It's somewhere in the region of 15 plus years. Anyway, 16 years, a long time anyway, but no, our first meeting it would've been, I'd originally gotten a job in. I was coaxed into the company by Lee Sillen who tried to encourage me to join and promised that it was great. And for most part it was. I started the company and in the company I'd always wanted to be a developer. I always wanted to work in software engineering. I first met you as the development manager for the new feed handler team. It's a very long-winded way of saying that we built new stuff and turfed it over the wall to other people and yeah, we've known each other ever since.

Speaker 1:
Yeah. Do you know, it occurs to me, I actually don't know how you met Lee the first time.

Speaker 2:
Yeah, Lee and I have a bit of history outside of, well, all of this stuff really sort of through mutual friends. We met actually whilst Lee was sort of at university many, many years ago at this point, but we discovered that we both had a lot of technology and engineering and all this kind of stuff. So I met Lee at the home of our mutual friend where I used to live for a period of time, and Lee was coming over and showing his new phone off to this friend who he didn't really mind too much about it, didn't really care, but I was sat there and I was super interested and we sort of hit it off immediately and yeah, the rest is as it were.

Speaker 1:
I remember the day that you came into the office with two versions of, you might have to tell me what they were, but you had a silver one and a black one.

Speaker 2:
Yes, that's correct. This was the Google Nexus six p for all the nerds out there that are currently not in their head in agreement at the awesomeness of those devices. Yeah. The thing I remember mostly about that story, Alan, is probably more so that you dropped it almost immediately after I showed you, which was very concerning since I was planning on returning one of them. And the one you dropped was the one I wanted to send back. Instead I had to do it the other way around. So thanks for

Speaker 1:
That. Did you, I actually didn't know the end to that anecdote, so you actually had to send the one back that I dropped.

Speaker 2:
I sent the one,

Speaker 1:
No, the other way,

Speaker 2:
The other way around. The other way around. I had to send the one back that I wanted to keep that was pristine and I had to keep the one that had a gouge up the side of it. So

Speaker 1:
Sorry about

Speaker 2:
That. That's all right. These things happen. It's a funny story if nothing else at this point. Right?

Speaker 1:
Yeah. And then you exited out of that business for a while and you headed to new. Maybe you could tell us a little bit about YADA and how you got on there.

Speaker 2:
Yeah, sure. So in NTA it was for those unaware yada at the time, and Belfast was a sort of consultant company that dealt with a bunch of different and industries and whatnot. So primarily public sector and capital markets. So more or less what we had done previously in the New York Stock Exchange. I worked there for about three and a half years in the capital markets department. So working primarily on projects for investment banks, tier one, tier two, investment banks, building out financial products, all that kind of cool stuff for commodities, brokers, all this kind of stuff. So it was an interesting role. There was a lot of variety to it. It's an interesting thing because you're always keen to draw parallels to I guess the difference of a product company and a consultant company, and they are very different. For what it's worth, I'd be product all day long. I think it's a huge boom to be working on something and seeing it develop and flesh out for the whole life of the product and see what it does afterwards as well. In consulting generally you get a little bit of that at the beginning normally, but after a little while you kind of have to step back and step away and sort of do the whole process all over again. So there were sort of pros and cons, but it was a good place to work. I really enjoyed it.

Speaker 1:
I can't believe you were there for three and a half years. That was definitely the wilderness period for Lee, and I think when we were trying to figure out what we were doing and trying to go through early ideation, figure out everything and then go out and try and raise some money. So we raised our seed round in 2019 and obviously that was successful and the first thing we were, we need to hire Tom and we need to hire Dan. So you guys were top of our list in terms of trying to bring back into the company and we were so pleased that both of you accepted. What was it like coming back into, well back working with Lee and I, but coming back to something that you had sort of seen the early signs of before you had gone to Neira and then kind of coming back and seeing what it was like then?

Speaker 2:
Yeah, I think imposter syndrome would probably be something that a lot of folks would resonate with, but it felt the same but markedly different, if that makes sense. When I had originally sort of moved on to Neada, sort of just had the beginnings of what would be the Cloudsmith product. So there were some of the underpinnings there. Some of the package formats, for example, have been fleshed out prior to me leaving, but coming back the difference, I mean what Lee and you wrote in that period of time is just, it's incredible. And sort of seeing the change in how the product itself had actually formed. You look at things like the billing system, permission system, things like that did not exist before I moved on. And to see all of that sort of come to life in a product that works, there were actually customers that were using it and were happy with it. And yeah, it was great. I think it was really cool to see, but to be honest, yeah, I was a little bit sort of bewildered. I think having been out of it for a little while felt I understood it a little bit, but equally felt completely out of a depth initially, but at the same time, quite glad to be there. It was great to work with folks again and it was nice to have Dan along for the ride as well, suffering alongside me once we got back up to speed.

Speaker 1:
Yeah, no, there was a lot of work done in that period and maybe the biggest part was not just the technology, but actually we had some semblance of go to market by the time you had come back and we had a sort of steady stream of customers coming in and that made all the difference in terms of the roadmap and those early decisions of what to do and how to do it. And then that was early

Speaker 2:
20 19, 20 20 almost, I think.

Speaker 1:
Yeah. And then we were in the Malone Road, the 33 Malone Road office at that point, and we had hired Kyle and Andrew Spade. Patty was obviously there and Dan and you and Lee and me and Peter and Kimmy upstairs, I

Speaker 2:
Think Kimmy upstairs. Yeah, as well. That's right.

Speaker 1:
Yeah, no, that was an amazing time of, that was a big difference for Lee and I was getting more engineers in the door to do more things. So I think in those days we tried to get people to write a package format. He may have been exempt from that at the beginning. I don't know. Do you remember?

Speaker 2:
I was somewhat exempt. Lee assured me that I'd written Debian in the past and I couldn't remember any of it, but he's a smart guy, so he's probably right. But yeah, I had written Debian in the past and worked in I think maybe one or two other things, and most of my focus in the early days was augmenting what was there. So with Debbie and for example, with the fact that I was so familiar with it according to Lee, I would be able to quickly bolster it and add support for a bunch of stuff that folks were very interested in, like multi distribution type stuff and everything. So I generally focused on that side of things before starting to look at some of the bigger picture stuff afterwards rather than the formats themselves.

Speaker 1:
And then Covid happened and we all went home and made the one and final transition to remote working. And I suppose maybe you have moved up the ladder now to principal engineer, you've moved into office of the CTO, you've seen that journey from, I think you were employee number five, so you've seen the journey from employee five to nearly 90 people in the company, which I'm still bewildered by in many ways. It's kind of crazy to see just the sheer growth and the sheer sort of focused roles that have kind of appeared. I'd love to hear how you think that transition has gone over the years, I suppose particularly in terms of engineering and then ultimately to where you've ended up now.

Speaker 2:
Yeah, that's a good question. It's been a journey for all of us. There's been a very, very long fulfilling and rewarding but difficult journey at times in the early days, excuse me, the early days of what we were working on, I think that the market we were working with was maybe just a little bit less, or not necessarily less complex, but we understood it very well. And what we were sort of trying to target meant that we were focused on just slightly different things. We were wanted to build the best in class package management, artefact management platform. And over time, very, very quickly it became clear that as an industry we were moving towards bigger and better things, particularly in the security space. And I think for me, that's probably been in the engineering side of things, that's probably been the driver for higher engineering teams itself have actually started to evolve and split into different functions and roles.
But the journey, it's been difficult periods of time where we might've had three, four engineers trying to originally keep the lights on of the product, which was difficult, but surprisingly doable when it needs to happen. And we had three or four engineers at one point balancing sort of on-call rotors and things like that in the early days was obviously more tenuous in that you would typically be on call significantly more just due to virtue of there being fewer people to share the load. As time has went on and we started to flesh that out, I think it's certainly become a much more nicer experience for folks to be on call. But the actual growth of the engineering teams and things, it's been like we've seen some points where we might've had maybe 10 or 15 engineers then that drop down and then it went back up again.
But it fails as though we're kind of in a good trajectory at the moment, primarily because we're focused on delivering product. And I guess just sort of focusing on individual product areas across teams and giving them the opportunities to build up and understand awareness of the microcosm of what it is that they're working on in the product. Early days we didn't really, the product probably was less complex than it is today, but we also did have fewer engineers and it made it even more difficult to try and balance development of the product and try and get it built and get more stuff done out there to move the needle whilst also ensuring that it was stable and that the product itself was able to actually meet the needs of and expectations of the customers that we already had, let alone the ones that we were chasing.
So yeah, it's been an interesting experience. I think we're at last saw we were around about 30 in engineering today, which is kind of terrifying to imagine that we have that many people just in engineering alone. It's like you said, we're 90 now or something across the company, and it's just bewildering to think that that's actually the case and there's folks that I still need to talk to and get to know on a more sort of personal basis, et cetera. So the growth has just been insane, but at the same time, super, super exciting. And as of late, I would say relatively sort of sustainable. It's in keeping with the demands that are being placed on each department.

Speaker 1:
So you mentioned complexity there, Tom. I mean, how has that grown with scale or has that grown with functionality or a bit of both?

Speaker 2:
Yes, both for sure and different challenges for each. I think for scale we're heading to give some context, we're looking at, we always wanted to build the product to be able to accommodate 10 x. That's always the golden marker, right? 10 x the capacity, et cetera, from where we are today. But some of the difficulties in that sort of started to arise and that our growth was such that 10 x was too slow, it turned out then we needed to be at a hundred x or even greater. And so there's challenges in that in meeting the needs of customers, the amount of requests and artefact serving, et cetera, that's being done. So that's one aspect of it and trying to ensure that the service is stable throughout, that it doesn't go down. It has to be reliable and available for our customers to use at all times.
But that's just the technical side and generally everyone going through building a product will face a point where they had scale problems or scale concerns probably is probably a better way of looking at it. But scale's just one thing, aside from the scale element, it is complexity. We've since sort of bolstered the product significantly. I think we'd originally had maybe around about, I'm trying to imagine in 2019 when I'd started, but I think there was maybe around about 10 package formats. There's probably more than that. But in terms of what we offered for each of those formats, it was widely different from what we do today. So it was relatively light touch just about, pulled out enough metadata to be able to understand what the artefact was and then serve it to customers afterwards. Today of course, that has jumped, we're now at about 28 package formats and the complexity of what we would call format completedness is significantly higher now than what it used to be.
We have features now such as signatures and verification stuff that we did have previously, but we're certainly more immature upstream support for example. That's a defacto standard that we have now across our package formats. And that in itself, it depends on the format, but some of those can be incredibly complex depending on, depending primarily on the native interface, how package managers actually speak these formats individually. And some of them can be very, very difficult, but many of those problems were hit as we started to onboard customers with even more ingrained approaches to building software that previously you might've gotten away with saying, oh, well this is just how it is, this is how it works here, and can you change your pipelines? We can't do that anymore. And we kind of have to be at a point where there are decisions that be made about what actually goes into the product, what new stuff are we bring into the table, and how we meeting the needs of the customers that we have.
So that's on the software side of things. On the business side of things, it's been probably difficult in the sense that we've had lots of, we've had probably very similar problems in growth, excuse me, as many organisations do in that when you start to onboard more engineers, certainly in the early stages it doesn't necessarily improve productivity. There is an overhead adding an engineer to the mix, there is an overhead adding a new engineering manager to the mix, and it takes time for folks to start to not only just to find their feet as it were, but also to be able to thrive in that environment. I think primarily because the product has started to become that much more complex, the supply chain security stuff is all very much mite now to the product. We need very hyper-focused teams to work on that stuff. Whereas historically we had a scatter gun approach of going, okay, today I'm going to work on the upstreams for Debbie or Patty, you might go and work on the CDN or something to support some. We kind of have to be certainly a lot more judicious about our resources today. And I think that there's been a learning experience to understand where we've gotten to what has worked, what has not worked. And we're ultimately all just, we're still learning every day and trying to apply the learnings to make it easier, but it is complex, certainly adding more people to the mix, mix things significantly more complex, I would argue probably more complex than the technical challenges that we've had up to date.

Speaker 1:
No, I mean, I have to admit, I liked it when there was three or four people and the communication was so much easier as well. And I guess that was obviously partly because we were all sitting around at the same desk in the same room too. So I really did enjoy those early days of just sort of solving the problems in the room right in front of people. And then now you have to get multiple people involved and it definitely does have an effect. I mean, arguably we're making better decisions now or maybe inarguably, we're making better decisions now that are more measured and better to chart the course for the roadmap and the overall platform. But I have to admit, I do miss the days of the chaos and the fixing of the problems sort of there and there in the rim.

Speaker 2:
Yeah, there's something, there was certainly something cool or nice about being in the heat of it and just getting stuff done ultimately and seeing, certainly back then when we worked on something, it was fast, it was the talk, obviously the whole phrase people say is move fast and break things. We certainly did move fast in the early days, tried not to break too much, but you can aspire. But yeah, there was a certain kind of camaraderie I think about being in that situation and being where we were at the time. It was exciting. It was very, very fun. It was just great to be a part of it.

Speaker 1:
Yeah, I mean obviously there was less customers too, so the customer demand for things was less. So you actually could divert attention immediately to a customer and try and help 'em solve their problem. And we still do a really good job of that, I think even at the scale that we're at today. And I think that comes from that DNA that we kind of laid down sort in those early days. But yeah, no, I mean there's challenges all over the business to try and raise our game, and I think we're doing a pretty good job, a job to that. So I suppose that moves us on nicely to your, like I said before, you're not a principal engineer, you're in the office. You've moved into the office of the CTO O out of the regular engineering squads, and that gives you a bit more freedom and free licence to go off and work on what we internally call horizon two projects. How has that transition been for you?

Speaker 2:
That's a good questions there. There's, there's challenges and there's certainly pros to it. One of the nice things about being in the position that I and a few others are in at the moment is just that predominantly there's certainly an element of trust to get stuff done and know that you're working towards something much larger than where we are today. And it's exciting. It's exciting. There's an element of feeling back where it was in those early days of where you might, it's not necessarily that we didn't have product market fit at certain things, but we were just doing things incredibly fast. We were trying to get stuff out and we were trying to do the right thing, the horizon two stuff that we're working on currently, it's a similar approach. There are bets, there are things that we might not have ordinarily done or tackled throughout the regular kind of engineering cadence because there are so many other concerns in terms of keeping the lights on in terms of meeting customer's, roadmap requirements and all that kind of stuff.
So it's nice to have the opportunity to take a step back and actually go, okay, give us two plus years. Where do we want to see this product? What do we want to see in the product that we're currently not able to do? And it's nice that we're taking that approach to do it. I think from a personal perspective, it's interesting because moving away from kind of task oriented, like building something for a little bit, fixing an issue, working with some other folks in the squads, et cetera to get stuff over, there's an element of that that you do sort of lose, I think, and it becomes more difficult to, I guess, certainly to keep yourself very motivated. It's a research oriented way of doing things. So primarily a lot of document making, a lot of understanding about what can be done, what can't be done, and ultimately trying to distil that down into something that you can be presented to other folks to help inform whether or not we move forward on things. So yeah, it's pros and cons. I think certainly missing the opportunity to work in some of the squads. We do still get that in horizon two during what we would call the kind of integration or incubation phase. So stuff that we do build, we do go back and work with squads to kind of get that over the line, but the period of that which that can happen could be, it could be many, it could be a month, it could be three months. Depends on the project that we're looking at currently.

Speaker 1:
Yeah, and you're just out of a squad recently.

Speaker 2:
That's right. Yeah, that's right.

Speaker 1:
What was that about?

Speaker 2:
Yeah, so it's a good question as well. I worked in, well internally what we would call Sentinel. It's a squad that's primarily focused around supply chain security and the features of the platform that make that broad strokes goal or remit. What I was focused on at that time was the incubation of a product, or rather a feature improvement that we had in the platform called continuous security and continuous security, excuse me. It was an evolution to the concept of security scans. We've supported security scans for quite some time, but scans are heavy. They require action to occur, they require things to happen in order to understand what has changed. And a whole bunch of the times we took a step back and looked at this and thought, well, hang on. If we understand what something is, what a product is, could we not flip that on its head and instead have it where when CVS or vulnerabilities are actually announced, we do the inverse.
We check at that point to see should we apply this to any other artefacts inside of the platform. And the benefit of us having a kind of SaaS platform like this that's tailored for this sort of stuff is it certainly enables that kind of stuff to be done at scale. And it's been very helpful. We've taken off a whole bunch of time in terms of security scans. We've enabled recurring security scans because of the efficiencies that have been gained in using the new process, and we've ultimately offered the ability to get enriched data to customers using enterprise policy management. There's now the ability to fetch EPSS scores, for example, that can be used to write better policy. So it's been a very good project and I think so far things seem to be good.

Speaker 1:
Yeah, no, that's amazing. No, I mean I love it when we figure out something innovative that finds performance or finds another way of surfacing more data into the platform. I think that really resonates with the reason why we started the company in the first place was to give, this was the language maybe wasn't there at that particular time, but really it sort of control and visibility of their software supply chain. I've been in the industry now for over 25 years, which

Speaker 2:
Frightening,

Speaker 1:
Isn't it? It's frightening. I felt young when we started, so that was when we were, I think it was like 33 or something when we kind of left NA and sort of started this whole journey. And at that point you weren't old enough to be the father of people that you hire and now it's like easily, it's kind shocking.

Speaker 2:
Yeah, I know. It's crazy. It's absolutely crazy just to think back how long it's, and having Cloudsmith itself and the incarnation has been in going, it's been like a long burn, but less so today. It's all very,

Speaker 1:
It took a long time to build the rocket ship. It

Speaker 2:
Took a long time to build the rocket ship. I think that's the words I'm looking

Speaker 1:
For.

Speaker 2:
But back then it was tough going. And you just felt like a lot of times you just felt like you were getting a kicking

Speaker 1:
Figuratively. Not figuratively,

Speaker 2:
No. For anyone watching this, I didn't actually get a kick in from Lee or Alan, but I mean more like a kind of personal mental kicking.

Speaker 1:
It was passion and grit. That was the fuel in those early days. I mean, I had very high standards at that point. I've since been on a kind of mellowing journey where my expectations have, expectations a bad word and should, those types of words are all a bad place to exist when you're trying to track and create and think about things and everything. It's more now, it's like we haven't done that yet. I was very quick to add yet onto the end of sentences, and I think that it is absolutely been a massive journey, but at the same time, when you think about it in the moment, it's like what can you do in the moment to make the best decisions and kind of go forward? So all of that leads into how has it been for you personally in terms of the whole development experience through that process? At the very beginning, we would've kind handed you the laptop on day one and was like, there's your desk, away you go. And now we have people coming in, there's a whole host of resources and things to a plan when they come in the door. So how has it been for you sort of seeing that change over the years?

Speaker 2:
It's interesting because it's like you said, it was, I don't want to say it was chaotic, it wasn't. It goes back to the way things, what we've just talked about, it sort of being exciting and I think as well, because it was probably slightly different because we all knew each other so well. We'd all worked with each other for quite some time, and there's an element of knowing how someone will react by you doing or not doing something. And over time, obviously the more folks you get in through the door, the less that actually exists is a thing. But it's been crazy. I think just looking at what a developer sort of gets now as that come through the door, as you say, there's a huge plan. I think we have a sort of buddy system as well. We have a whole bunch of things, but I mean, we didn't get any thought back in the day.

Speaker 1:
Mean you don't still use Vim anymore, right?

Speaker 2:
Oh gosh, no, no, no, no. Yeah, those days are over. Although, I mean, you remember the site I used to use a whole, I was always using some kind of funky editor or something and trying to persuade you and late you use it in

Speaker 1:
2012. I never switched. I

Speaker 2:
Never switched. You never switched. You never switched.

Speaker 1:
I was vim until I stopped basically picking up the keyboard to code.

Speaker 2:
Well, I mean, it's a bit like coffee for you. A black Americano is about as exciting as you're prepared to go. But yeah, the editor stuff, this is interesting. Obviously you can still use Vim, but it's just, it's sort of changed widely by having Visual Studio Code has probably been the kicker. But even before that, it was Adam GitHub Adam, or it was sub supply tax before that. There's always been some pretty neat stuff out there. I try to convince some of you guys to actually look at it is a different matter, but by and large, I think developers today are, they're certainly more judicious about what they want to use and what they want to play with, and the editors are kind of crazy, particularly the AI side of things and stuff at the moment that just, it's kind of frightening where we are with all that.

Speaker 1:
And you would know better than me a bit closer to it, the teams are dictated in terms of what tooling at that level to use, are they? No,

Speaker 2:
No, no.

Speaker 1:
So you can kind of use whatever you want, but

Speaker 2:
In the early days, we used to allow folks to use whatever computer that they wanted. You would've gotten a budget of some sort. That was pretty generous from what I remember. It's been a while now, but the idea was you could pick, obviously developers, they all picked MacBooks, right? That's just the way it is. So eventually we ended up just sort of making that the default, primarily because it makes tooling things and building a developer experience for folks consistent, it just makes it a bit easier. But in terms of the tools that they use, no real kind of, if someone wants to use Vim all day, they still can. We'll not stop just we'll generally try

Speaker 1:
And well, maybe from a productivity point of view, but yeah,

Speaker 2:
Yeah, from that, yeah. But it's interesting. It really is just using the right tool for the job, I guess that there's so many of them now. It's completely changed in the space of even maybe the last five years. I haven't personally used these very much, but I know folks have used Cursor and things like that. If nothing else, it's just kind of exciting and crazy that these things exist now. Developers have so much choice whenever it comes to deciding what tools to use in their toolbox

Speaker 1:
And team wise as well. That's the other side of this, in that we now have a platform team. We now have SREs. There's a lot of the rough edges that we would've had to have dealt with as developers. Managing the platform itself has kind of been taken away from the day-to-day and that there's a, there's a team to look into those things that must have made life a bit easier.

Speaker 2:
It's made a massive difference just having a platform thing. I think we always kind of had a platform team in the sense that Patty was the platform team for quite some time, just by the fact though, it's something that he's always been interested in. He loves a good incident, but it's kind of been nice having folks around there that are super interested in that stuff. But just taking away the notion of having to be a complete Postgres expert about shaping queries to the health, et cetera, by understanding, write the way down into the performance characteristics of certain things. Those things still matter. They're still important in general, when we ship stuff, we've tried, the folks in platform have improved developer experience probably from that by quite some. They've added things like internal profiling, for example, using open telemetry, things like that that historically we just didn't have in production.
And we have in other production-like environments, but certainly not within our development environments. And sometimes there was a big sort of gap I think between or potentially a big sort of gap between what you see in development and in production. We try to keep the environments roughly the same, but there's some disparities between the two, but the platform teams just made that a whole lot simpler. We don't need to think about that stuff. I think for me, one of the big things has been having dedicated data functionality, like having folks that exclusively look at databases and schemas and all that sort of stuff. Because certainly from my experience, that's not something I've ever particularly enjoyed. It's something that the data folks seem to absolutely love. So I call that a win-win. But just having that in place, it's really great to have folks that can kind of do the right thing and they know their focus area inside and out, and you can learn off them. You can find this stuff out, but it does mean that we get more opportunity to focus on what's what we are actually trying to ship as well.

Speaker 1:
Sure. Yeah, no, it has made a huge difference, I think, across all the teams. So looking ahead, what are you looking forward to most in the next six to 12 months?

Speaker 2:
More than likely the scale challenges that we're heading, particularly with our most recent very large customer who's come on board and the challenges that presents us just as a whole company, really we have to level up. There's just no two ways about it. We've got really good folks across the board, not just within engineering, but great folks in customer success, et cetera, that are able to work and build really good relationships with customers. And that's super, super important. We leverage those relationships all the time just to understand, I mean, obviously the product folks do that to understand what we need to build next, but even an engineer and it's nice to join calls, for example, with customers and just speak to them. It's one of the great things about what it is that we do day to day is the people. Our customers are just people like us.
And that's not necessarily normal in most industries, but it's something I sort of appreciate. But if I was to talk about that, the excitement, it probably comes off as the scale challenges and a lot of people would probably be like, what's exciting about that? I think it's the level and upside of things that we have to do across the board. It's the improvements to the platform that we need to make in order to meet those new challenges. We'll be introducing massive changes, for example, to how we do work at the edge. And I mean, I'm a nerd. That's super interesting and it's great. And trying to see what that's going to look like in reality is just exciting. It's, there's a whole bunch of things that we've wanted to do for such a long period of time that we, maybe it wasn't the right time for it or there were other things that we were contested with.
So yeah, it's probably the scale stuff. It's understanding what we're going to get out of that. Particularly I think with the supply chain security stuff, we're in the process of rolling out policy management, et cetera, but there's a lot of work that looks really, really pretty cool that we're sort of looking at it at the moment related to it in terms of what happens next with policy management. And I think for me it's super exciting just to imagine that you'll be able to drag and drop things and make policies and do all that kind of cool stuff. It's just a world apart from what we were doing five years ago even.

Speaker 1:
Yeah, yeah. So final question for you. What do you love most about your job?

Speaker 2:
There's two things I would say to that. I think the first one would be probably the industry sounds weird, but it's changing all the time. It's never dull, it's never staying the same. I think the last four years, I've discussed this a couple of times now, but with the hyperfocus and the importance of security and all that sort of stuff, it's driven us to have completely new solutions to problems that didn't exist to the same degree a while ago. Over the last three, four years, we've seen the prevalence of things like SBOs seen, thinking more about attestations, using frameworks like in Toto and all that kind of stuff. It's super cool to see how those are going to start to be used more in the public domain. These things are starting to be introduced into package managers, and they're starting to be used heavily by everyone.
Even canonical registries today are focusing on security. So it's interesting because that gives us a lot to work with. It gives us a lot to work towards, but the industry is probably it just because it's so fresh, it's always changing. There's incredibly talented and smart people that work across lots of different organisations that we have partnered with and organisations that we have yet to partner with. It's just great to see these folks and see them sort of trying to change things and make it better. And like I said, it's making things better for other folks like us, really like dev tos interest in that respect. And it's just different for many other industry that I've ever worked in. Aside from that, and this is a bit of a cop out, I guess, but just talking about the people, it is literally the people working in Smith.
The benefit of being here for five and a half years at this point, and I've had the opportunity to meet a tonne of people across the board, and there's some of the people that we're bringing in are just, I still learn stuff off every one of them regularly, and that's rare to work somewhere and still get that so long into your role. And they, they're just nice folks. They're just great to work with. They all, they just want to do things and do it right. They have a right attitude, right way of looking at things and they like dogs and stuff, so that works for me too.

Speaker 1:
Yeah, no, the all offsites are really fun and getting everybody into your room. I was having dinner with Glen, the CEOA couple of nights ago, and we were talking about the offsites and he was saying, we're a Belfast company. The offsites are probably always going to be in Northern Ireland. And I was like, on one hand it was really pleased. That means we don't have to travel too far to go to the offsites and get to go home to your own bed. And then on the other part, I was like, ah, but it would be nice to go somewhere sunny

Speaker 2:
Vegas. Come on, can we not get to Vegas or something? Seriously, I've been angling to get us to go to even AWS reinvent for a number of years, and I swear it's because reinvent looks really good. It's nothing to do with Vegas. Scott's Honour,

Speaker 1:
We might be able to get you to reinvent, but I don't think we're going to land the whole team into Vegas anytime soon. Maybe a series C,

Speaker 2:
Maybe. Maybe we can dream. You got to have dreams and goals, right?

Speaker 1:
Yeah, yeah. No, absolutely. Well, look, Tom, it's been a pleasure speaking with you today. I've really enjoyed the conversation and there's lots of cool things to come for both you and the company. So I'm really excited to see what's next. So thank you very much.

Speaker 2:
Yep, likewise. Thanks very much.