Rebuilding IT From the Ground Up for the AI Age: Serval's Jake Stauch

You know, I think that there's always a gap between the idealized vision of what you think your job's going to be and then what your job actually is. I think it's true for every profession. You idealize and kids do this the most, right, when they're like, want to be a firefighter or an astronaut, what that job looks like. And then you get in that job and you realize, oh, there's actually a lot in this that I don't like. And we want to be the tool that actually closes the gap between what you think your job is going to be and what your job actually is. All right, I'm here with Jake, the founder and CEO of Serval, Jake. Welcome to the show. Thank you so much. Great to be here. We're going to start with a high level question. You guys are building kind of the next generation service now, like the AI native service now, so to speak. That is right. Why does the world need an AI native service now? Yeah, employees need help at work. That's kind of the idea here is we are a platform for employee support, the technical term is enterprise service management, but what it really means is getting help at work. And the ideal way to get help at work is you ask for something and you get it instantly, automatically, you don't have to wait on somebody to track down a ticket and assign a ticket to somebody just get help immediately. That requires you to have some kind of automated support and that automation is best built with AI. So we think about this from first principles, how do we support employees, you automate all the requests, how do you automate all the requests, AI is really a good tool to bring that automation employees. Awesome. Let's say more about that. So I remember back in the day, when we first met Fred Lutty who was the founder of service now in like 2007, 2008, sort of time frame, and at that time, people thought that service now is amazing because there's this big step function change over paragraph and remedy. And the key thing that they got right was to think about enterprise software as an abstraction is just workflows on top of a database, right? So they built kind of this flexible workflow configuration engine on top of a database. And at the time that was amazing and IT people loved it and they were off to the races. What I'm hearing you say is that that's not enough with AI, there's kind of a new generation of automation that can be done. Can you just say more about the thing that service now built and the thing that you guys have built and kind of the side by side, like what is truly different this time around? They got it right. We also built workflows on top of databases and that is the right abstraction that those are the right primitives, the problem with their workflows and databases is that they require a lot of manual effort to build and maintain. So building those workflows often requires dedicated development resources to put those together. And while that sounds fine, you invest those resources and you get a beautiful automation on the end of it, that can take weeks to months. And in an era where business processes are changing very rapidly, by the time you get that workflow implemented, your business may have changed and moved on and you want a different workflow. And so your automation kind of runs behind where you want it to be and that's more true now than ever before. Same with the database. If you need to manually update those entries and look at your IT assets and make sure they're up to date in those systems, that's going to be very, very painful to have to bring in consultants or internal developers to update. We took this unique approach of let's keep those primitives workflows on top of databases, but allow you to use AI to build workflows and use AI to update the databases. And the way we do that is this code gen engine where you describe the workflow that you want, all the different steps and permissions and approvals and logic. And we take your natural language description and we turn that into code. And so your workflow appears instantaneously. There's practically zero time to develop those workflows. And the same thing goes for our databases. You can describe exactly what data you want to take from which sources and our system will actually generate the code to fetch that data and keep it up to date without you having to do any kind of manual intervention. I remember you said months ago, this is one of the things you said when we were first getting into each other that really piqued my interest. Something along the lines of if you really want to drive enterprise automation, you have to make the process of building the automation just as simple, if not simpler, as the workflow being automated. Exactly. Is that, do you still believe that? Is that still true? I still believe that. That insight came from just putting yourself in the shoes of someone in IT or another function and you're presented with a task. Somebody asked you to reset their password and you've got two options. You can go into Google Workspace, find the user, hit a button that says reset password. Or you can open up a workflow builder and you can drag the trigger and then you can drag the response and then you can build out this custom workflow. When you're presented with that choice, you're just going to reset the password. You're going to do the manual thing. But if it were actually easier to build the automation, you would build the automation because it's just why wouldn't you. And I think that it comes down to that, people in the moment have to make that decision and you want that decision to be very, very easy to opt for the automation, not opt for the manual step. Now, is there such a thing as being too simple to automate like, is there, you know, people talk about the vibe coding and all the slap that it produces is such a thing as slap automation? Yeah. It is. It's real. And we've had to build some really interesting things around that because yeah, when you make it so easy to automate, somebody might build the 20th password reset workflow this week. Yeah. And it's basically the same as the 19 that came before it. And now you've got all these duplicate workflows and the AI gets confused on which one to run. Yeah. How do you guys manage that? Yeah. We built a, a new agent basically on top of servo that's what we're really excited about that has full contextual awareness of all the workflows you've ever built before, how they work, what they're going to do. So when you say, hey, I want this workflow that does X, Y and Z, it says, hey, actually, you've got 19 that already do that. I can modify one of these, but here's what I think you should do. I think you should actually delete 10 of them, separate these remaining nine into these different categories, add these approval steps. And so it actually walks you through the system and it's kind of your assistant that's an expert in our product to help you translate your business requirements into the actual product implementation. Speaking of the product. So your product guy and one of the things that we've heard about you consistently from every possible source is that you're extremely customer focused and like really good at listening to the customers and figuring out what they need. Do you have a North Star metric that you rely on that just tells you the product is getting better and more useful or is it more you collect all the anecdotes? You synthesize them. You kind of have an intuitive sense. Like is there a number that you can look at? I think it's a ladder. Like I try to be embedded with the customers like full immersion. I am in every single customer slack channel. Yeah. I think most of our customers will get a slack for me and that channel every single day. Wow. And that is a huge. Maybe. A little bit of context. A listener might think like, okay, you probably have four customers. How many customers do you have? No. 100 customers. Okay. And a lot of large enterprises and it is overwhelming at times to be in all those conversations all the time. And sometimes I feel like, oh man, I'm wasting my time. But I feel like I really understand what's going well. What's not going well. And I just have my finger on the pulse. And there's just no substitute for that, especially when a lot of the implementation work has gotten very fast, more and more of the moat for any startup is the customer insight, the empathy of like actually understanding what they want. And if we can have a differentiated advantage around the customer insight, that's going to be much more valuable than having a product advantage, which is copyable overnight. Let's talk more about that because this has been a hot topic for a few years now. You know, ChatGPD comes out in November of 2022 and immediately people start deriding application layer companies as rappers on top of a foundation model, right? And what you just said kind of plays directly into this theme of there's always a school of thought that says, well, the foundation models can just do everything. And then there's a school of thought that says, sure, but you can build a company on top to close the gap between raw capabilities and like actual customer problems. How do you view your role running an application layer company versus the role of the foundation models? Like, where do you think the moats form around your business over time? Basically, to the extent somebody listening is interested in like, how do you build an application layer company in this era? What are your thoughts on that? I think you have to be happy when the new models come out. And that is that is kind of the guiding principle that we have is how do we make sure whatever we're building is actually not made obsolete by whatever the labs and hyperscalers come out with, but actually is made better. What's a good example for us, we think the product is the boundaries. The product is the controls. The product is actually what limits the capabilities of the model because the question now is not, can opus, can GBT 5.5 do these amazing things? Can they do the things I want to do in my enterprise environment? The capabilities are practically unlimited. The limitation now is how do I get comfortable as a large enterprise that cares about security and deploying this company wide without elevating my security risk. And so we think about it from the boundaries. And so that means really boring old school enterprise software things around permissions and approvals and limiting the scope of your API integrations and having visibility into that, having audits and reporting and logs and alerts and just all of the things that make you feel comfortable letting the models run wild in your environment. And so one of the fundamental things we did from an architecture perspective is kind of divide the agents into two parts. So our customers, when they experience serval, there's really two agents they work with. One is the admin agent that helps build all of these tools and skills that configure how to help desk and what things that help desk agent can do and what it knows about. And so it's the admins that build that. And then there's a help desk agent that end users talk to that resolves their problems. The help desk agent can only use the tools and skills that have been expressly built, published with approvals and permissions and all of that by the admins. And that architecture, that kind of like 2-pronged architecture, ends up being really, really powerful because you can let the help desk agent run wild, right? Because the end user can ask it anything, and it can use its racing ability and its full intelligence to be able to solve a user problems. But it can only use the tools that the IT admin has expressly set or OK to use. And those may have approvals attached, permissions that gate certain users from doing certain things. All of that is done on the admin side. But then you get like kind of the full ability and intelligence of the help desk agent to use those tools appropriately. What's under the hood? Is there anything you can say about which models you guys are having luck with and maybe how that's evolved over time? Yeah, we use OpenAI and then Thropic Models today, always experimenting with the latest models from all providers to make sure that we're on the cutting edge, running eVal suites on everything that we do. Today, it's still OpenAI and then Thropic Models. We find different models or better at different applications. So for the interaction with the end user, we're seeing the most luck with OpenAI models. And that is remain consistent for quite a long time that actually calling the correct tools and responding to the user in the appropriate way, that's still we're having a lot of success with various GPT models and always keeping those up to date, depending on the latest release. But on the automation side, which is mostly co-gen automation, having the most success with the Thropic Models, so continue to use those. Sonnet, Opus, and tons of trade-offs between the different models. And I think what's interesting in recent times is the new releases oftentimes are not just plug and play. Sometimes you get some advantages and some things that we're working really well. Don't work as well anymore. So that's become an interesting challenge as things go. Actually, yeah, how do you guys manage that? How long does it take to incorporate new models into the production version of your product? How much of that process is automated in some fashion? How much of that is somebody just has to sit down and figure it out? How do you manage that? It's not as automated as I'd like. We have the evils automated. But then in every situation when we have a new model that we're testing, some things get better and some things get worse. And a lot of things that get worse, not necessarily the model got worse, but we built a lot of prompt tuning and a lot of infrastructure around the known quirks or behaviors of that model. And those make less and less sense when the new model comes out where you're swapping models. And so that's where a lot of the adjustments have to be made. And then you kind of run it through the evils and then you do a slow release across customer. So we're getting better at this. But I think there's certain cases where the trade-offs have not been worth it, where we've actually upgraded models and then downgraded the models and said, you know what, the old models are maybe they're a little bit faster. Or maybe they're reliable in a way that the new models are. And so maybe the new models are a little bit smarter, but they misbehave in ways that are less predictable. And we have less predictable guardrails to prevent against. And so we're like, hey, this model might not be a smart, but we know it's going to behave the right way for these customers. So it's been an interesting challenge and it's changed over time. How much are you guys factoring cost into the equation right now? Because I think step one, you got to make sure the product does something magical. Step two, OK, now let's make sure we got a business. Exactly. And we can extract and propiate amount of value for this functionality. Do you guys think much about cost at this point or we kind of know where that's going over time? Let's make sure the product is magical and we'll figure out the cost element later. It's the latter. And I think one of the reasons that give us this flexibility is that our unit economics end up looking much better than a lot of AI companies because we are not in the business of reselling tokens. The way that our product works is that you build these automations, which are basically typescripts. And once they're built, you don't have to rebuild that. And so every time the end user asks for a password reset, it's not going in regenerating code to reset a password. It's actually just running the code that's already been generated. Over time, users have to generate less and less actual code because we have a growing library of automations that cover the very long tail of things that you might want to do. And so there's not as much, especially in the kind of very expensive code gen token consumption. There's not as much as you'd expect. And so the United States are very strong, even though we haven't done a lot of optimizations around that. So I try to tell the team spend more money, use the best possible product. We know long term where this is going. We know that there are all kinds of optimizations we can make down the line. So that's been our focus to date. I think that though where it starts to get more interesting is as we explore more and more applications of like background agents, long running agents that are not just responding to help desk requests or not just building quick scripts for you, but investigating all of your historical tickets or investigating logs from devices and doing all this work in the background and maybe generating solutions to problems you didn't know you had. That's where it becomes a little bit more interesting where maybe the costs become more relevant. So that's where we'll probably start to think about costs a little bit earlier in the journey because those could run away pretty quickly if you're not keeping an eye on it. - Yeah, that makes sense. Let's say somebody at Openair and Thropic wakes up tomorrow and they're like, wait a minute. I found this company called ServiceNow and it seems to be like a major system of record, major center gravity inside the enterprise. I think we should build as a first party product, you know, the OpenAI ServiceNow or the Anthropic ServiceNow. If they set their sites on you and come after you directly or come after your category directly, what would that mean for Service? - Yeah, I mean, this is always a really tough question because on the one hand, any response to like, okay, this company with infinite money and the best engineering talent and AGI wants to do what you do. How are you better? It's kind of like any response that is going to sound pretty naive but like, well, we're just going to like beat them. But I think the history of startups tells us that often the smaller company does beat them. I mean, the existence of OpenAI and Anthropic are kind of proof that you can be at the entrenched and come in with infinite resources. And I think it comes down to, you know, maybe divine provenance favoring startups or maybe like a lack of focus is often what makes it hard to execute. And so, you know, when I was starting my first company and the whole, you know, every VC would ask me, well, Google just do this. And yes, Google will do a lot of those things but it actually is very hard to do a lot of different things really, really well. And it's hard to divert your focus into all these categories. And I don't think ITSM makes a most sense as a focus area. One reason is that I think in the past couple of months Anthropic has added more ARR than service now has in the past 20 years. Good point. And so does it really make sense for them to take their best and brightest people to throw them at this problem that even if they're very successful, would not be really, it would take them years to get what they could get out of the rest of their product portfolio in a matter of months. And so I don't think they're going, they're probably looking at this category. I wouldn't be surprised if they built some kind of simple version, maybe a more mid-market recipe focus version. But to really devote the time and energy to master the complexities of enterprise service management, not to say they couldn't, but the focus that would require I think would be a bad use and bad prioritization of their resources. And I don't think that that's going to happen. Yeah, I think you're right. Let's talk about your customers for a minute. So you got a bunch of the kind of really nice AI native logos. And you're also starting to have some kind of big enterprises. How do the needs differ from the AI native crowd to the big enterprise crowd? And if you had to pick from each of those, what's the nicest thing that they would have to say about you? A server is amazing because what would they say? Yeah, I think what's been the biggest learning is how similar they are relative to how different. I expected them to be much more different. But the pain points and the problems end up looking remarkably like from the AI native to the large enterprises. We work with companies as small as a few hundred employees, up to companies as large as a few hundred thousand employees. The difference ends up being how many people it takes to make a decision. And that's what actually makes things really challenging is because of a go-to-market thing. It's a go-to-market, it's an implementation thing more than that. So when you're-- if you're working with a company of a few hundred employees, there's probably an IT leader that can say, this is how we're going to do things. This is how onboarding works. This is how we're going to reset passwords. If you're working with a company with a few hundred thousand employees, no one even knows who that person is. If that person exists. And so you end up in all these kind of committees trying to figure out what should we do here. And that's actually what makes it very, very challenging. And I think you see that in these labs building out these consulting businesses and more and more services and deployment resources. Because that ends up being a lot of the rate limiting step and adoption is coordinating all these folks. So what would the nice things they say about me-- I think about Serval. In the AI native early stage companies, we often just-- we take an IT person that's passionate about technology and we let them spend their time building. They got an IT because they love technology. And so much of their job before Serval, they weren't really getting to experience technology. My favorite example of this is a customer he had that spent a lot of their day fielding service now requests to provision someone's access to cursor. Yeah. And that juxtaposition was just so sad. Like I am in this ancient ticketing system, helping somebody else at the company get out. access to a really cool AI tool and my tools are still stuck in the past and I don't get to use the cool stuff and with server they get to use the cool stuff like there's actually an AI tool for IT built for them and so that's I think what we see on the anate of side. I think in the large enterprise you know generally they're thinking about it at just a higher level of business transformation and we hear a lot more about the end employee experience because in a small company even if your IT processes aren't perfect no one's waiting weeks to get a response back from IT but a large organization like you could send a ticket into you know into the abyss yeah and and just have no idea where it's at if it's being worked on so then you'll send another ticket and then there's confusion on the other side because now you've got two tickets from the same person and and there's actually people that are blocked for weeks from getting back to the thing they're trying to do and so I think in a large enterprise we actually change the employee experience and what it feels like to be an employee and and have this more broad impact because the problems are actually a lot deeper in those big organizations what is a delightful or a surprising use of serval at serval how do you guys use it oh man I forced the team to use it for everything so every time so where do they really push the boundaries exactly I mean obviously like things like officer quests like snacks like all of that has to go through several but I think one of the coolest thing to do for serval is one we have a channel called dream team draft we take this very person first approach to recruiting where we want to identify the best people in the world and we want to bring them to serval versus just cast a wide funnel host and open try out and see who makes it and so people put the best people they've ever worked within this channel they post the LinkedIn that's a serval channel so serval take that profile and then run a series of automations one it'll it'll run into all of our outbounding campaigns our nurture campaigns it'll also do a lot of things that my marketing team won't let me talk about of like making sure that they are seeing serval everywhere they go and and serval becomes very top of mind for them and we basically warm this audience to make sure that that they know about serval and we're playing a long game because these are generally not people that are going to leave their job tomorrow but people that we love to work with one day and so I I love the idea of going in and saying like hey all I have to do as an employee is just like I love this person they're great and I'm done and the talent team will be able to through serval have all these automations that kind of get them into the system that is very cool what's the best reason to work at serval like why do people join your team I think it is the greatest group of people I've ever worked with I think when you walk into our office and you meet our team it's just a group of so you know people that are so kind and so talented and so fun to be around and I think that that's what's really unique is is I didn't even know I was selecting for this yeah when we started the company but something can it started tell me is that while your team is so nice and they're so fun to be around and like I walked in the office and the energy was just contagious and I wanted to work there and obviously there's really interesting technical problems you know building these really complex enterprise automations getting to touch HR legal finance IT security like it's kind of a training ground we often think about this is a training ground for anyone who wants to do anything in AI you get to like touch all these different departments build all these cool workflows but I think the you know if I'm being honest the reason you joined serval is because you meet the team and you realize this is the place for you yeah very cool we heard some of the words that you used to describe your culture you know fun and nice and high energy people what is it not it is not a good place for let's say a lot of training or mentorship so everyone is kind but everyone is doing their job and there is not a lot of hey you're going to be onboarded through this program and you're going to learn how to do these things and we're going to train you really well and we're going to hear you with the you know some resources and coaching and mentorship and there are great companies that do that really well we are not one of them so we we hire people to come in and and basically be productive on day one and who's like that ambiguity of I've got to show up and figure out what I'm supposed to do and then do it really really well so it's it's not a place for coaching mentorship it's not a place for very clearly defined career paths we don't know where a lot of these functions are going to go so there's not going to be this clear progression up the org chart there's not really an org chart I don't actually know who reports to me at the company I am like blissfully unaware of who technically reports to me versus other people because we try to keep everything as flat as possible and and so if you're looking for that kind of like natural progression you know it's just not going to be a good place for you yeah as far as one of the big topics that we've had a lot of conversations on recently just amongst founders and folks is this idea of living in the future and not only the product that you build needs to be AI native but the way that you build it and the way that you manage your organization needs to be AI native beyond using Surveille itself like what does that mean for you guys like how is the way that you operate changed this time around versus Verkata or your prior companies and so many ways so one is we are questioning everyone's role every department we're wondering if it needs to exist anymore and it still makes sense and oftentimes it does you we relearn the necessity of some departments that we thought maybe we didn't need and but we start with the the assumption that maybe this doesn't need a person anymore maybe this could be AI so AI almost gets like the right of first refusal for every job or every department of like hey maybe we don't need this at all and maybe this can be much smaller than maybe this is a good example of something that fully went to AI solutions engineering so we don't have essays we also don't have SDRs but I think that's been that's less of a controversial take over the past few years but we don't have SDRs and we don't have a solution engineers our reps are not necessarily more tentacle than reps and past generations have been but they have access to servo and so any question they have about how the product works or that a customer comes up with a prospect servo is going to give them an instant answer to that question servo can even build them decks build them one pagers and quick you know battle cards and comparison sheets like all of that on the fly in the middle of a call so we expect more out of our AES and they're not going to have the SE resource we do have four deployed engineers that assist with the actual pilot implementation but that's been one example where we didn't need that we also delayed hiring in a lot of domains like and and sometimes not by choice just by the slowness of our hiring but we've discovered how far how far we can get on the enablement side we have someone in product marketing who's done an incredible job of like building out enablement and all these automated resources and scaled that quite far and we definitely need more help there but you know a lot of times you get further than you think with these AI tools revops is another one where we've gotten pretty far without a rev up sire but then discovering like actually you do need somebody eventually and so there's a lot of these things where you delay it a little bit and you're like actually we need somebody but maybe this department is a little bit smaller than we thought it was going to be company is about two and a half years old they're about two years old two years old okay in the last and you guys have grown like crazy more people more customers all that good stuff how has your job changed in the last two years in the very early days I felt very useless honestly my CTO is building the product and it's very clear what we need to build there's so much to build and I'm trying desperately to hire and to set up customer calls and maybe try to sell this thing it's not working and so I think in the early days it was kind of like trying to figure out how I can be most useful when we don't really have a business yet and then over time it switches and it becomes a business and stops being me kind of pushing the boulder up the hill and more of the business dragging me along I think what hasn't changed I'm still very involved with customers both in the sales side but also in like the long term success and talking to customers every day I'm still very involved in recruiting what I'm not as involved in that I'd like to be is a lot of product and the early days I am thinking nonstop about the product direction and now it feels like the product direction is kind of emerging from our customers through our four-deployed engineers and going right into the product and which is in many ways great because you have this kind of nice closed loop of customers talking to four-deployed engineers and then the products can implement and getting better all the time you know I've often referred to this as like gradient descent for product improvements because our four-deployed engineers are just just just swarmed with all these you know all this feedback from customers and they're like oh I'll fix this I'll make this better I'll change this and like you fast four to week and like wow the product is a lot better than it was a week ago and it keeps going that way but I get to spend a lot less time thinking about the future and where we want to be and I think that's something that I need to spend more time on because this stuff is changing so quick to your question earlier about you know how are we different as an organization and an AI native organization I think a big difference is you have to be willing to reinvent yourself so much faster you disrupt yourself so much faster like we are thinking about just uprooting things that we were convinced or true months ago and going in completely different directions in all these different ways and we have to have that flexibility we're going to be renaming parts of the product we're going to be completely shifting how we do certain things in the product and we have to be willing to do that over and over and over again and there's going to be less of this idea of like I am building a software that's going to last for 20 years and more I'm going to build software that hopefully will last six months and then I might have to rebuild it once the paradigm shift and the markets have changed yeah and let me ask you about that because there's a foundation model on one side or a set of foundation models and capabilities there's a customer on the other and they're serval in the middle and these capabilities are changing at a very rapid pace this customer is probably not changing all that fast. And so you guys in the middle are kind of this buffer. Yes, that is right. Try to take all these capabilities and put them to work for the customer. So the question is really, it's kind of a change management question. Like how do you keep the customer from drowning on this downpour of capabilities coming out of the foundation models? - I think that's exactly the right way to think about it. We are in that we are kind of the that translation layer. - Yeah. And we have to meet customers where they are. I mean, I think we very much have to understand their business problems. And that's what really helps with the four deployed engineers is we are starting with their business problems. What are they trying to solve for? And then we are helping them discover how those solutions are implemented in serval. We are on the other side figuring out how to take in the latest advances in AI to be able to deliver those solutions. And so that is kind of what role we serve. And then we're often educating them of like, hey, here's how we do this. And by the way, it's changed since how we would have done this three months ago. And we have these new tools at play but we will be the ones to help figure this out for you. And one of the things we're working on is how can we bridge that gap a little bit more succinctly? So how can we make an agent available to the end user that kind of says, okay, what are your business problems? Cool. Here's what we're going to do. Here's what we're going to solve them. So you don't really have to think about the latest advances. Serval just kind of takes care of that for you and you just have to focus on what are your problems, what are you trying to achieve? - What's your most contrarian take on the world of AI? So one take that I have, which I don't know how contrarian this is, but I think there's this big gap emerging between who wants autonomy and who wants control of these agents. And the individuals in an enterprise, they want autonomy. They want their clawed agent to do everything for them and have access to everything. The organization itself doesn't want their employees' agents to have all this autonomy. And there is this interesting tension emerging between, and I often see this in consumer versus enterprise products where the consumer products obviously are built for a world where you want it to do everything and the enterprise products are built more with this control layer. And what's happening in the enterprise is that the individuals are adopting these tools and wanting it to be able to do more and the security organization, the IT organization is very worried about this and for good reason. And I think that's something interesting to track is this tension between autonomy, like do organizations actually want autonomy or do just individuals want autonomy? And how do you navigate that tension? And that's where we're thinking a lot about the server product and how we help solve that. >> It reminds me of Shadow IT back in the day when consumers started to adopt iPhones and enterprises still had blackberries because they could lock down the blackberry. And the iPhones started to show up with work information and then more applications. And they're kind of sneak in their way into the enterprise. And the instinct of most CISOs was, you know, protect, protect, protect. And then I think eventually they realize, wait a minute, this is kind of the leading indicator on what my employees need to be productive and they started to embrace it, right? And it feels like the same thing's happening now with AI where employees kind of know what they need to be productive and as long as you can just kind of systematically follow those signals and embrace it more likely to end up on the right side of history. >> Yeah, and I think the companies that basically say yes as the default are going to be way ahead of the companies that say no as a default. And we're seeing this with the companies that just embrace it. They will also kind of be leading the charge and face a lot of the consequences of there are going to be security incidents, there are going to be problems and we're gonna learn a lot from those. But I think that that is what we're going to see is the companies that take those risks are gonna get ahead. But those risks are real and they're also going to be some of the ones that suffer some of the consequences on the security incidents. >> What's your biggest issue at the moment? Our biggest issue is hiring still. Every AI company I talk to is in the same situation. Even though AI is allegedly supposed to automate all this work and take away all these jobs, we're all still hiring more than ever before and it's still like our number one priority and our number one concern. And so, but I think people remain the biggest mode you can have and having better people in the room is really the only thing that will keep you ahead of the competition. It's the only mode that's left is the people in your organization. So hiring and scaling and keeping the bar incredibly high as we hire are the things that keep me up at night and worrying me especially as the business grows so much that I am less involved. There's a lot of people that I will only meet in their interview and they're onboarding but not have probably a lot of one-on-one interactions after that. >> The talent density point, I think, is a good one. And we think about that a lot too because we're sort of in this world where Costco's down, capabilities go up, the result is accelerating change. If the world is changing quickly around you, you have to optimize for agility. >> Yes. >> The best way to optimize for agility is an organization is to have the smallest possible number of the best possible people, right? And so I feel like the returns to talent density have never been higher than they are today. And so like you guys could go hire a million people but like doing so with the sort of quality and culture fit that you need, that's tricky. >> And to your point, it makes it harder to turn the ship and so our mantra on hiring is fewer better, fewer better. Like we say it's over and over again, fewer better, like how can we make this department fewer and better. And that's going to be really important because again, I think we're going to have to reinvent ourselves more frequently than companies have ever had to do this before. And I can imagine a future version of serval where it's unrecognizable from what we do today because we just had to adapt so quickly. And that's much easier to do with a small agile team than if you scale very rapidly, you become thousands and thousands of employees and you say, hey, by the way, we're changing everything about our go-to-market, we're changing everything about what our product does. >> Yeah. >> You know, we're making some big changes to the product and it's nice to have a relatively small organization that can embrace that shift almost overnight. I can't imagine what we do if we had to convince thousands of people that this is the new direction. >> Yeah, let's assume, and obviously this is not something we can take for granted, but just for fun, let's assume, let's assume that serval becomes a monster company. You know, it gazillion customers and employees and revenue and market gap and free cash flow and all that great, so let's assume you become a monster company. At that point, what would you want people to say about you? What else would you want to be true that is not contained in one of those traditional metrics of scale or success? >> I think I would want the impact of serval to be very clear in terms of like what it did for the world. The impact I think is most important what we do today is we unlock meaningful work for people. I think that there's always a gap between the idealized vision of what you think your job's going to be and then what your job actually is. I think this is true for every profession. You idealize and kids do this the most, right? When they're like, want to be a firefighter or an astronaut. What that job looks like. And we want to be the tool that actually closes the gap between what you think your job's going to be and what your job actually is. And we do that by automating away all this repetitive, menial work that you don't want to do and then is not productive and is not part of the reason you took this job. And we've done that in many ways for IT. And I think as we unlock automation for the entire organization, that's what we do for people is we get them back to the work that they actually signed up for and the work they actually enjoy. And so I would hope that there is clarity that that was the impact that we had. And it wasn't just like, oh, server automated away a bunch of IT jobs. It's like, no, I want people to feel like server-made people's work lives a lot better. Awesome. - I feel like a great place to end it. Jake, thank you so much for joining us today. - Thank you so much for having me and this is a blast. (upbeat music) (upbeat music)