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 Cloud Smith 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. Dave, welcome to the podcast. Great to have you here. Thank you for taking time out of your very busy schedule to have a chat with me. Just to let's get started and if you could give us a brief intro to yourself and how you find yourself at Cloud Smith, I'll be great.

Yeah, absolutely. So I've been at Cloud Smith for about three years working in the customer success role. So originally always loved computers, had aspirations to be a software engineer, went to university, sort of computer science, graduated in the middle of a recession. There was no computer science job, no one was hiring engineers. So went for the role that was the most adjacent that I could get, which was a technical writer. So I worked on that role for a couple of years over a couple of companies with always the aspiration of trying to sort segue myself into an engineering role. Moved into working in the New York Stock Exchange where I met yourself, Lee and a couple of the other guys and the Klaus Smith alumni, and then eventually got the opportunity to move into an engineering role. It became quickly apparent that it wasn't for me. I was an awful engineer and had to try really hard to be really mediocre.
And then from there I just kind pled to my strengths. I was always good at communicating with people and understanding the requirements and liaising between engineering teams and customers and I just enjoyed that kind of role. So I moved in, became a scrum master team lead in that sense, and they're just basically helping people deliver the software rather than being directly hands-on keyboards myself. And then from there moved into the delivery manager role and that's when at the time then Cloud Smith was kind of growing and had this opportunity for a customer success manager. And I always loved working for non-enterprise or smaller companies where you can be part of building something as well. And especially at being a Belfast company, that really resonated a lot with me, that being part of something local as well.

Great. I'm realising that you're a lot younger than me now, which is pretty annoying. So good at your job. I hope I can be as good as you are at your job someday. So that was really interesting. In terms of some of the things that you said and the technical writing side of it at the beginning, did you find that challenging when you weren't doing the software rule or what way did that work?

That's a great question. Funny, I had this conversation with a customer quite recently actually, and we gave them a doc and they were like, oh, I couldn't get it to work. It was actually this part of the doc. And I was like, yeah, that's actually mentioned in the middle of the documentation. And he goes, ah, I just copy commands and it, I'm like, that's the part of being a technical writer that you have to come to grips with 90% of what you write. No one's going to read, including myself. You just scammed that into the part that you want, grab it and just think that that's how it's going to work. If you need to, you can go back. So that was one of the things you have to come to terms with. And also, as much as I love engineers, they do not love documentation.
So that was always the other challenge of trying to convince people that I'm trying to help you give me the information, so let's make this, I'm doing you a favour by writing this. So that was also the other part of trying to sort get time with engineers too. They love talking about their code and how great it is, but not sometimes the documentation part of things. So it was quite interesting though, taking maybe looking a code or getting a high level and engineers love talking about how technical things can be. So trying to abstract all this really deep knowledge into a one line sentence of what someone really cares about or kind of give them the line. So that was probably one of the trickiest part, but also the most rewarding when you kind of read it back and you're like, that's a good sentence. And people could actually sort flourish using that as well.

Yeah, I mean you would need to have a good understanding of both sides of what the developers were intending and the end user was ultimately trying to do in order to make that work. Seems like a pretty key part of your job today.

Exactly, and I think that's the biggest part is who's the stakeholder? Who are you writing this for? Who am I presenting to? Who am I working with? On the customer side, there's basically anyone from a CTO or the C-suite level down to an engineer who's just deep in the weeds of Python, Java for 20 years. That's the biggest thing that I think that taught me is the personas get the relevant information across to the person in the quickest and simplest way possible. You can segregate it off going, okay, if you care about this, here's this part of information. You always have the information there, but you want to channel people into the right way. So as they get the motion up, wasting their time or making things overly complex,

That all sounds like a really great basis in terms of understanding what the customer's doing and what we're trying to do from a product perspective. So when you joined Cloud Smith, you were in a, we call them different things. I think at the beginning. Ultimately it was it like a technical account manager when you joined?

That's right, yeah.

How do you feel things have evolved over your three year period in Cloud Smith? What was it like at the beginning when you came in? How many people did we have in and around that time?

I think I was in the early twenties, it'd be around 20, 23 at the time, but to some of the things, it would probably be beautiful chaos. At the time you were wearing 15 different hats. Everything was different, but everyone grabbed a bucket, everyone grabbed a shovel. That was one of the coolest things about it. You can see the whole team in a room steering in the right same direction and you could visibly see what everyone was working on because you probably touched half of it as well. You were working with engineering, you're working with sales, you're working with finance, and especially within the technical equip manager role or the CSM role, we kind of interface with most if not all of those departments. So they've got the Venn diagram. I think we're solely right in the middle of a lot of that with what we do.
So I had a newfound respect for pretty much every department that we worked with and the challenges that they had, but also needed to keep them pretty much on the sweet side because chances are about five times a week I was going to be asking for help or information on something with a lot of those folks. But yeah, the early days was fantastic, not just not now we've grown, we've solidified those roles a lot more, I think is the biggest change. Back then you had these people in a room, everyone was doing everything. Now we've kind of been able to tailor our roles and become slightly more expert in what we do. It's not that I do 15 things and a little bit of them now I do expertly, but for chow down this one single thing with the customer role as well.

Yeah, I actually think in your interview we talked about that you were on multiple different projects where you had to learn different domains and learn different things in your previous life, and then I was like, no, no, you don't want that. You want to come and join us and to focus on the one thing.

Yeah, that's right. It was the old saying of don't multiple things, whole ass one thing. And I think that was before I was looking over my five or six different projects for stock exchanges and other things. I love the technical variety there and this is the first product company I've ever worked at. So it was interesting learning something inside out, but it still has the same variety. Customers use Cloud Smith in so many different ways. It's not very much. It's kind of like a one size fits all. Everyone can use it to their different strengths, whether it's internal development, distribution, there's so many wonderful ways that people use it that you still get that variety. It's not just something simple where this is the one way you use it and that's it, which could probably get very stale and there's so much scope there for people to use Cloud Smith that it still keeps a little bit of that as well.

No, that's fascinating. I think at the beginning, well, we were building the product for ourselves, so we had our use cases as the primary. When you're talking to customers now and you obviously pick them up after they've signed the contract and you get handed over an account, how's that transition between what Dan and KI and the team in solutions engineering do? What's that handover process in terms of you're coming in to try and create a relationship with a customer after other people have already got a relationship? Yeah,

Exactly. I think one of the big things is the kudos to that team. They go through a very rigorous process with the customer understanding their needs, their pain points, and is it the right fit for Cloud Smith? Are we going to solve Their problem is kind of paramount. So the customers, once they assign a contract, they come in to K Cloud Smith with their eyes wide open. There's no one things they're not aware of. They're fully aware of the capabilities, the problems that we'll solve, and the chances are most of the time is how we will potentially solve it. So they've already built up an excellent rapport technically and kind of in a normal sort of emotional relationship way with people, and that transcends very easy. Dan and I have worked together for 15 years across probably when I first met you, it was the first time I worked with Dan in New York Stock Exchange and then newa Klau Smith.
So I mean, we have got an excellent rapport together and I think that helps that we're both very similar in that sense and we can build that relationship and at times we can be very interchangeable. Dan's obviously Mr. Klau Smith. I'm kind of his padawan or kind of perge, but he definitely is the guy that sort of knows everything. And I think that relationship helps because customers don't think that, hey, as soon as customer success comes in, sales leave, Dan is always a bit of a constant and care as well with those. So they make sure anything that was discussed as part of those relationships in those early days, it's B three. We go into this going, so here's what we have heard. Here's what your goals are, that's the let's go. Let's hit the rubber, let's put the foot down and let's actually make it work. So we're already going into a very easily made kind of relationship there. We understand the goals and our part is just more executing it and pipe paving the way for the customers to actually achieve the goals or why the cap to CL Smith.

Yeah, well the personality side definitely has been a huge benefit to us over the years. And you personify that in terms of, I always think you're very good at listening and then you're very measured when you reply to customers, even if you don't know the answer. And not every, but there's plenty of times I've spoken to customers and not known the answer, and it's an art and a science to be able to keep them calm and figure out how to go off and get the right answer or Annie or any answer for that matter.

Yeah, exactly. I'll be the first to hold my hands up coming from a slightly technical role to being out of the developer world for a long time. I have no qualms of going, okay, that's over my head. Explain to me. And Dan uses analogy as if I'm a golden retriever or bust out the crayons to make sure I really know what you're talking about. So for me, that's paramount to understand what they're actually saying. Is it like there's a problem here? Is it we're not doing something? Is it they're doing something slightly differently or we need to under off this edge case? So it's understanding the frustration there where the issue is, or even just the question where it's originating from. And then there's incredibly a lot of smart people here in Klym Smith that I know I can lean on to go, help me dissect this, help me understand this.
How should I respond to this? So a lot of the stuff related to CLS Smith, I know from my tenure here, but it's a massive ecosystem. There's so many different languages, things that integrate with Cloud Smith that it would be impossible to know it all. So as long as I can keep that top 20% of that knowledge that I can respond to or even understand the 90% that Joel's done, that's where the lot of smarter people behind me come in to really drill into that. I think that's the biggest thing that I find. Don't try and do everything, try and have enough to understand and then you can go and rely on the people that can help you understand it or give you the answer you need.

Yeah, no, we absolutely should have picked something easier than artefact management,

Like Microsoft Paint or something. There's something easy, a single use case.

Yeah, I mean artefact management is the gift that keeps on giving. I mean, you're right, there's so many CI tools that we integrate with. There's so many deployment strategies, there's so many formats and the format stacks that customers have or this was a couple of years ago, but I think I had done an audit on the data just to sort of see, do we have any customers that do the exact same thing and no one did the same thing, everybody did something different. So no, that's definitely a challenge, but then that's what makes it fun.

Exactly. I mean as I've been here, I've learned all manners of products and I'm convinced some customers and colleagues actually just made stuff up to try and trick me. They're like, oh yeah, so cucumber and celery is running into issues. And I'm like, you just made that up. You're looking at your shopping list. That's not a real thing. But sure enough, it is. So I thought at the start people were kind of testing me. It's like I'm just going through it, random words here and say, oh yeah, of course I heard about that. But yeah, it makes it definitely interesting because as I said earlier, it's an evolving kind of landscape. There's never stagnant. It is ever forever changing and new challenges and new opportunities there.

So in your role, obviously you're the interface between Cloud Smith and the customer. How do you go about building trust with the customers?

Great question. I think the first thing that I found is just be transparent. The easiest way to build trust is be transparent. If you don't know something you don't know, if there's an issue, acknowledge the issue. The sooner you try and pull a wool over someone's eyes or bluff it, you just get yourself into trouble and everyone else in trouble because then give someone a misconception. So I think that's the biggest thing I've learned is just be honest. Acknowledge if there is something there and work with them on a resolution or work with them to go, right, yep, we have heard you. We have listened. Let me sort of follow up and let me sort of speak to the team. Let me bring some people in that can explain why we have done it this way, why you're having issues, why we can build it this way for you. So I think that's the biggest thing is just kind of listening and full transparency and honesty with the customers.

Have you ever had that really bad sinking feeling that you've had to go and talk to a customer or do you manage that quite well?

So by nature, I over-engineer everything. Going into a call, I will think of 15 different possibilities, 15 different outcomes I want to have, have sometimes people think I panic a bit much, but I want to be prepared. So as I'm not the deer in the headlights as the truck of package management failures coming towards me, I want to be basically sitting there go, okay, we have discussed this, or here's the next step. So yeah, engineering and product and all may think that I worry a lot, but I always want to think of every possibility going into a call if there has been an issue, it's like right, what happened? Do I know enough to give them confidence that we have got their back? Should it ever happened again or what the fix was? I think a lot of the things that customers is just peeking behind the curtain a little bit, showing them how the sausage is made without showing them the whole process.
You kind of just tell 'em. It's like, okay, this is what we draw, this is how we affix it. Two bullet points, one word answer or that one word answer that was that one word answer would be fixed, which probably wouldn't instil much confidence, but it gives them a quick summary of it. And they're engineers, like most of the people we work with get it. They're in this world, they have an appreciation for how difficult this stuff can be. And I think speaking to them like engineered engineer and a human to human, they really just go, okay, cool. Yeah, these things happen. So yeah, thankfully I haven't had too many of those or if I have a massive amount of therapy has probably helped push it into the dark side of my head, never to surface again. But yeah, that's probably the easiest way of trying to try and deal with it.

As you can see from this podcast, I am completely under engineering.

Yeah, I'm not going to lie. I came into this not knowing the topic, what we be discussing, how long it is. So the anxiety that has been induced in me, the definition of the swan, I look all calm and elegant, look in the top, but under the water it's just going at it. But yet I think for things like this, I can speaking if it's just about the product itself, I can usually kind of speak with confidence so I'll have enough knowledge and just chat that I can kind of buy. But if there is something about, I think this more aligns to if there's an issue or if there's a serious ask or there's something more like, Hey, we need to take this seriously. I disengage from friendly chatty Dave into, okay, this is professional Dave, and even my fiance can tell the type of call I'm on by the tenisha of my voice, so she'll know if it's okay to come past me or ask me something depending if I've got a friendly voice or if I've slipped into my, okay, yep, so blah, blah, blah. Very serious professional sort of lower tone DJ voice she calls it as that's when I'm being professional, it's the customer call. So that's probably how you can tell. But yeah, I think that's kind of the distinction there, at least for me anyway.

And then in terms of just to go back and surface those two questions that we've talked about there together in terms of we know you get good handover from the sales team and we know what your persona is when you're trying to deal with customers. As you get deeper and deeper into the relationship, has there ever been a case where a customer has come along and thrown a bit of a curve ball that it didn't get found out in the seal cycle and now you're the primary contact and it's sort of on your shoulders to shepherd them through trying to either solve a problem or find a solution?

Not often at a very sort of high level or high severity, but you always come up with little niggles. I mean for you to probably test and road test kind of cloud split, you need to have it in production to an extent that will give you full confidence. You can only do so much just by, it's kind of like ban a car, you take it out for a test drive, that's cool, you've drove it for three months. You're like, what's that ticking? Why does this not work? You find these little nuances and things that weren't quite as you expected or you made an assumption on. So I do think as customers grow, and I think a lot of this is down to nuances and how they do things, they may be abuse an ecosystem when it probably shouldn't and it worked because it was covered up and we maybe are I think the likes of data parsing and things like that and being able to validate packages.
Maybe some older systems don't do this and this exposed problems going, oh, we've been using this. But yeah, it's real with vulnerabilities or it's just the parsing of the data, it's just throwing up all these errors. So I think there is a little things like that that you encounter and also just more nuances with how they used it. Some things that you're like, okay, we assumed you'd done it like this, but they just didn't test it. So then what we do in those situations is basically just, okay, let's have a session. How do you currently use it? Why do you currently use it like that and how do you want to use it? Sometimes how they currently use it and how they want to use it and how they should use it are completely different. It goes back to the sound by, I think it was Ford and he was like, if you ask people, they just want faster horses instead of a car.
So if you ask people how they want some of this stuff, they're like, oh, well we do it this way. So just more of that please. We're like, there's actually an easier way. So there's sometimes a shift in mentality of telling people there's a better way you need to break out. That is here's why. Explaining the problem and also showing the path of how you can get from A to B is probably one of the other things because that's one of, I'd say the biggest challenges is people are like, oh, artefact, it's ingrained in all our pipelines. It's everything that's going to be complicated to move out. But in actuality, nine tens out of 10, it seems scary, but we kind of have done it enough and made a lot of the tools that we have and walkthroughs and we have seen most of the edge cases that people encounter so we can guide them through and even having opinions on how you should set up your repositories, your teams, your structures and everything.
We've gone, we've seen the pitfalls over the years with different enterprise organisations and small organisations, so we can guide them. They're not expert, not effect management. We are so we can guide those organisations into the right way on the right path. And if there are things and stumbling box we encounter along the way, it's up to us to find out is it a problem and if it is, how do we fix it and how do we work with the customer to fix it? In which case it's looping in engineering from that technical standpoint product giving them basically feedback in, okay, we're considering doing this, does this work? Here's timelines, here's the roadmap. And fostering that relationship so as they're not just at the behest of should we do it or when we might do it, we'll communicate going right, we will and here's when, here's how. If we won't, here's what we can propose in the meantime to actually get you around these problems or even changes in your workflows.

Yeah, I mean that seems really powerful as nearly more positioning as a partner rather than a vendor customer relationship. Yeah,

Exactly. And that's what I always strive to have. I've worked for a lot of enterprise organisations where it is a very transactional, basically that's when I'm on the receiving end and there's the vendors there, but I always want to make customers not my friend, but I always want to have that personal relationship with them. I want them to know that they can come to me if going, this isn't quite working or here's what I'm hearing from people, I just wanted to let you know because the sooner they surface that or they can be honest with me, that means I can help. So I would like to shy away from the transactional kind of business approach and basically become more friends where people can be open and honest. And I think that kind of fosters quite a better relationship and working with customers is more of a partner. We can grow together in lockstep rather than kind of just, okay, you're just customer transactional. I'm moving away from that.

Yeah, I mean that actually sort of leads into my next question mean what does success look like to you? How do you measure success at the end of the day or the end of the week or the end of the month?

You think of how to have a good answer to that saying success is in my job title, it varies on customer to customer. If truth be told on the stage that the customer's at success is what were their pain points? Have we solved them? That's sort of fundamental and at the end of the day is does Cloud Smith do everything they needed to and are they happy with it? That's the core. If they see value from Cloud Smith, they going, yeah, we need it off our X solution. We're now here. That's sort of stage one. We have got them away from the problems that they had and have we made their life easier? So it's a hard thing to measure. You could go through so many different KPIs depending on the customer, the success, where they are along their journey, but I would say fundamentally do the see K Cloud Smith as a value platform as a part of their infrastructure.
And also to an extent they don't have to think or even worry about it. We have had people say, I love K clout, I never hear about K clout. It just works. And that's kind of like you can take a worry off the CTO O stack or any of those people that's I think craves that. It just works. So yeah, it's a tricky one to answer at different stages and each kind of customer would probably have a different answer to. But I think fundamentally it's like are they getting the value and does it basically relieve a lot of the pains that they had?

Well, the change tax slightly in the conversation. We're a remote first company and you are more remote than you once were. So you moved from Belfast to New York. How are you finding the transition of being in a different time zone away from the vast majority of the engineering team and what are your afternoons?

Great question. So firstly a correction, and this is purely for the benefit of anyone that lives in New York, including Glen. I'm not technically in New York, I'm in Hoboken, New Jersey, which I mean it's one kilometre across the Hudson. And I mean when I was talking to people, I said, live in New York and they're a cow whereabouts and I was a cold book and they're like, that's New Jersey, that's not New York. So it depends who I'm talking to. And I've tried to adapt. It goes, oh, I live just outside New York, Manhattan. And I've tried to loosely bend the lines a little bit like that. But yeah, that came, I've been out here about a year or so. It is been very fortuitous. I think one of the biggest things is with the amount of enterprise organisations we have here, the overlap in time now is fantastic. One of the other things that I've tried to move over is I always worked for US companies or US customers. So for the past 15 years of my life, it's generally working until seven ish just due to overlap with the us. And then I moved over here and with the Tao shift I found I was waking up at 5:00 AM and I'm not the guy to get up early and go to the gym. I've never been that guy and I was like, I'm going to be that guy. I'm going to get up when I wake up and go to the gym and seize the day. I'm still loosely doing it, but I do then very loosely.
But I do find the mornings are crazy with meetings. I love just the overlap now because I do get crammed in the mornings with catching up with, the biggest thing is opening slack and seeing it lit up like a Christmas tree and I've had to stop doing that as soon as I wake up because nine times out of 10 I'll read something and goes, ah, I should get back to them. I should get back to them. I get up, I go to the gym, I do things and then I was like, someone asked me something, what was it? So you have to get used to trying to prioritise the reams of updates, messages, channels, customer things until you start. But that was great because your mornings are just like ram with meetings and trying to people and updates. At the start I got to about 12 one, I was like, must be time to clock off here.
What time is it? You're like, it's just hit afternoon. So I've started consuming a lot more coffee, but the afternoons are now great because it gives me time to do a lot of the work that you usually do. So before it was kind of the opposite. It was in mornings I could get up and do things in afternoons was crazy leading on. But that shift now I go in meetings, write notes, and then the afternoons I can stick on headphones for the first time listening to a bit of music and actually just do working sort of churn through a lot of this stuff.

That seems great. I wish I had that. I get up immediately, look at Slack, think of all the things that I need to do and I continues on throughout the day.

It gave me good motivation to start when I was going for a run. Then I could think through everything that I needed to do and all this stuff and how I respond to this and what I need to do. Again, leaning back to the overthinking things, I'll have 15 possibilities of how I'm going to respond to a Slack message by the time I finish my run. And then all of a sudden I realised I'm in upstate New Jersey or something. I was like, oh right, like Forest cup, I just kept running kind of thing. But yeah, I think that's the interesting thing about the shift there.

I'm pretty sure I give you a really hard time during the interview process. I think you had to interview with me Nick, who actually hadn't joined us at that point.

Correct.

And then when we finally made the offer and you accepted it and you came in we're like, why did we give you such a hard time? But I can tell you why we had no clue what customer success was supposed to look like at the time. And so obviously Dave, we had known each other for many years prior and you were always on a short list of people that we would want to bring into the company and so that the timeframe was no reflection on you, it was more of a reflection on, we were kind of still trying to figure out what to do and how to do it and then priority would change a little bit and so the time got kind of pushed, but eventually you came in, which was fantastic. So you were kind of there at the very beginning of even the process of really defining what in early days, technical account management, customer success, customer support as well, that even was kind of part of that role and Dan was kind of fulfilling all of that. It was kind of bringing you in to support Dan in that very early position. What was it like coming in to learn a brand new industry, a brand new product surrounded at least by friends? Obviously you knew Lee, me, Tom and Dan.
What was that like?

Yeah, I'll first go back to what you had mentioned around the interview process. I think was just after I think the day of the series A announcement and I think we had just got a bit of message that I came in to meet you and it was equally flattering and also terrifying at the same time because I was like, so what will we do? What's the direction you were like, we don't know, but we pretty sure you're it. And I'm like it, what are we looking for here? It was kind of funny and I think that's what kind helped as part of that interview process that you had mentioned Nick was helping define. So I had reviews with people. I was like, were dealing an affiliate and well they were a affiliated with Cloud Smith, but we're working for Cloud Smith loosely. And I think a part of that was me trying to do some fact finding as well.
It was like, what will I be doing here? I had been working at my previous company for about eight years and there was always the running joke, but because I was in a consultancy company and a lot of my customers were external vendors and banks et cetera, and there's always a running joke that I'm a company man just for the wrong company and that I always saddled with our customers more than the actual company that I worked for. And I think that kind of led me nicely into the customer success role kind of and a company man for our company and our customers now as well. But yeah, I do recall those conversations and it was very much like, so I've got a rough idea of what I'll be doing and I think even the first day I came in I was like, so what do I do?
Where do I go from here? And I think at the time it was like we were very good at talking to customers because I mean they got the white glove treatment. They were essentially, it was a small group of people. They were talking to the co-founders, all these customers as they came in. So we done a fantastic job of selling Cloud Smith and telling them why it's great. But because we were a growing company at that time, we were always bringing in more customers and we needed that attention to the existing customers. And Dan done a fantastic job of leading a lot of that work in the support role, the technical account management and the rollout, but we became a victim of our own success and that Dan can only go so thin. Everyone else in Cloud Smith could only go so far. And I think then that's what I came in working in the support role and the success, or sorry, technical account management and I think the support role to cut your teeth was fantastic because no one comes into support.
It goes, things are great, thanks very much. It's all going class. People come in going, this isn't broke. Why is it doing this? This? I was expecting this is broke. So you kind of see the pain points. It's kind of like when people leave Yelp reviews and stuff like that gently, a lot of people are just pissed off when they're doing it and they want 'em voice as opposed to you never hear about the goose things. So I did think cutting my teeth in the support role and doing a lot of that stuff gave me a better understanding of how customers use it, the pitfalls and the misconceptions there and more empathy for customers as well. And I forgot what the original question was now. I think I've answered a little bit of it. I kind of got distracted with going back to that interview process as well.

Yeah, no, no, I think you have, I just sort of vaguely remember at that time there was a lot of late nights and there was a lot of evenings where there was a sort of small nucleus of people trying to man the intercom chat and make sure that anybody who came on was happy and then there would always be that sort of franticness when somebody reported something you had to go and immediately try and replicate it to see whether it was us or it was them. Yeah, I mean that happened a lot.

The intercom, I don't know if you've ever obviously used it, but that little but intercom there is times. So I try to hear that the thousand yard stare comes along and you sort of think back to all the horror stories in the late nights, but I did enjoy that as sadistic as it sounds, there is an energy that comes from not the same one, let's put it down to a safe two or something that's not completely, that's a manful there. But I did enjoy that kind of energy, like jumping on a call, watching the incredibly smart people in Klaus Smith just drill down and get to the root cause. If it was us or in a say because we're instrumentals, a lot of what people do, it might be us, their pipelines, it might be authentication permission. So there's equally on the other side, an investigative work that we have to do to help the customer understand this is where it is.
We might have the information that could help them or they'll immediately just go, ah, failure was Enclos Smith, it's your fault. And we're like, it actually happened in your pipeline, it's just manifesting in us. So there was quite a bit of that, but I did enjoy, and again, I'd say probably half the engineers would not because I was just on the call going, how's it going? How's it going? Any update yet? Any update yet the customer's asking. But I did find that adrenaline or that sort of product at the start where everyone's pitching in, everyone's, as I said earlier, grabbing a bucket, we're heading through it, trying to figure out how do we get out of this, how do we fix it? And then being able to report back to the customer, okay, this is fixed if you did have an issue. And everyone's always very appreciative I think is one of the biggest things with Smith is the support that you do get.
It's engineer back support for the most part. Internally engineers and our principal on call teams have eyes on most things that are reported from customers. So it's not that we'll go through a script or a user flow and just try to work out what it is. We're going to ask educated questions. We are engineers ourselves, well they're engineers. I used to be an engineer, but we understand and can work through a lot of that stuff with them. So they appreciate more that technical. It resonates more with them that we're asking the right questions and pointing them in the right direction or taking ownership and drilling into it and giving them updates around our resolution should it happen to be within Cloud Smith.

I mean I love it when we notice before the customer and are able to communicate an issue or an issue that's about to happen before it happens or before they notice

That actually happened literally this morning. Someone noticed that anomaly in a spike again, it wasn't, it was like authentication error at an normally high amount. And that was flagged into the customer, our internal channel. We were able to communicate to them going like, it's not in clouds Smith, it's something within your pipelines. Chances are your users are going to encounter this soon. You might want to have a look. And they were able to go and Oh, okay, yeah, something didn't rotate or there was an issue with a token. So it is always when I hit enter on that to a customer channel, you're like, is this going to be good or bad? Are they going to thank us or is this going to open the flood gates and you're just going to let go into full sort of panic mode? But I think largely people do really appreciate that and it shows a little bit more that we have got their back. It's not that we need to respond or they need to flag it. There's lots of stuff that's like we're this invested in their success as we are. And again, we have monitoring on our stuff, so why not just put it and help the customers early detect a lot of this stuff if we can.

Yeah, I'm not going to lie though, when I am looking into an issue and we realise that it's not our issue and it's theirs, the sense of relief is paramount.

See, you might get that. But then I get the customer going, are you sure? Or I have to prove to them without proving to them that it is. And a lot of the times, I think the biggest ones are around network related and things like that where it's very obfuscated down into the weeds of what we can tangibly prove. We just know it's not us. And they're like, well, where is it? I'm like, I don't know. So yeah, it is good, but there's also an element of how can we help them. We, I think a lot of the times we don't count. Our job is done at that stage. They have still got an issue, is there anything we can do to help them? But yeah, that definitely is kind of good when you can go get to the resolution of it, albeit within Cloud Smith or the customer side.

I mean the other win is you feel like a million bucks when you figure out what it is.

And I'm the one that gets to tell the customer it's fixed. I do nothing. I just sit there in engineering, do all the hard work and then they give me the thumbs up and I'm like, sweet, it's fixed. There you go guys. And they're like, oh Dave, thanks so much. And I'm like, don't worry about it.

Yeah, we were at an event that CubeCon recently and I'm one of our customers come up. It was quite funny. It was Lee Skill and our co-founder and I were standing beside a big massive TV screen with both our faces on it. We were sponsoring the vent and we were just standing looking at this TV and it was scrolling through different options and then eventually our faces appeared. It was pretty surreal. But one of our customers came up and then recognised us. Obviously they saw us on the TV and they were very complimentary about you. They said you and Esteban were the two names and they just said you were so good at communicating and talking through the issues and the challenges and the solutions and everything. They were a little bit drunk, so they kept going For a long time. We were standing listening to how great you and Esteban were for a long time.

That sounds amazing. You are so lucky.

I know. It was so nice for us to hear how good you were even though we were standing there, but it was amazing.

I was going to say, that's what we'll do it for, but we don't do it for the gratification for customers to tell us how great we are. But it is that as what I said, fostering the relationship, letting them know. And I know who you're talking about and I think a lot of the challenges there was misconceptions or hey, our old platform done it this way. You do it differently, I don't like it. But in actuality it was better. How have we done? It helped, but it was just a perception thing that we really needed. So it was more of an education going like, right, let's just take the time. Let's get the board up. Let's walk through how everything works on the inside. And again, as I said, they're engineers, they love this stuff. They love knowing, okay, so that's why it does it because of this.
They don't want to take our word for it, that it's better. Well, tell me how it's better. And yeah, I really relied on Esteban on that one because he'd did a fantastic job of walking through can write blank pad, here's this, here's this, here's how it works. And drilling down, I think it was the size of a, is it a two is bigger for a two page worth of drawings and explanations and stuff like that. Just really conveying how the inner workings of it all worked. And I think one of our biggest things is we have engineers who are comfortable sharing how this stuff works because it's pretty cool behind the scenes and people see this like, ah, that's quite clever how you do that way, or I love how you do this. So showing them how it works instils more confidence. And also they can take some of that back themselves and they go, actually, I really like how you're doing that. I wonder if we can do something similar within our side. So there's more of that collaborative sharing as well.

Cloud Smith has always been about transparency and solving problems and communicating and dealing with the customers and trying to, like you said, provide value. And I think you do a fantastic job of really personifying that and dealing with the customers. Dave, what do you love most about your job?

The variety and building up those relationships. There's quite a lot of customers now that I jump onto calls with and to Bill. So we have to try and get ourselves back to work. Like we've got weekly syns or monthly syncs and if people join, they were like, do you ever talk about work with this deal? I was like, yeah, usually we squeeze it in going right, we've got five minutes left, we need to chat about this. So I think that's one of the other things is just meeting people, hearing the stories here, hang there using Cloud Smiths and just basically just building those type relationships is probably one of my favourite things. As I'm sure you can tell, I'm an introverted extrovert, I think is the way I put it. I love chatting to people, but I can equally not want to chat to people and sit in the room quietly on my own. But I think that chatting to folks is really one of the things that I really enjoy the most. Building those relationships. As I said, the variety, each call each customer is different. It's not just right here we go run through the same thing over and over again or the cookie cutter for every customer, each one's different, each ones use it in a different way. So I think that's one of the most interesting things and even trying to sort of figure it out.

That's amazing. I'll have to join more of these calls, these work calls that you're doing though. That's a great answer. Anyone else you think I should talk to? Any customers, anybody outside of Cloud Smith?

Customer-wise, as a character on a great conversation, there'd probably been about five, say three people out. Probably you, mark Doug, the guy from EDB like Doug and brand from EDB. They're fantastic. And they're one of the ones where it genuinely is. We have an our call in every two weeks and we just shoot the breeze half the time. I think we are chatting about doing a case study with him, so there could unlike something like a joint thing at KubeCon, so there probably could be some stuff there as part of that. Jordan from Core Weave, lovely guy, amazing guy, and he loves me. So I mean obviously I'm going to put that one up there. But he is generally just such a decent guy as a bit of a dude. And then Jesse from WCG Clinical is always an interesting guy. They in the medical trial space, they're consolidating 30 companies.
Him and a couple other guys stand up their entire infrastructure as code, bring people in. They're basically dockerizing a lot of stuff. So again, doing a lot of cool stuff there as part of that kind of role. And also quite an interesting guided to chat to and really friendly as well. So from a, it's not going to strictly be deadpan, be a bit of banter and crack with those who probably be the three people that I would kind of say I would probably put forward. And again, I've got weekly biweekly calls with all of them, so you're more than welcome just to fire up a gong recording and see how much shit talk and I actually do, and how little of my job I actually do on some of these calls versus joining one as well.

It's been a real pleasure having you on the podcast today. Thank you so much for taking the time to chat with me. I hope you've enjoyed it.

Yeah,

I have indeed. Thanks for having me. Great. Thanks Steve.