Grant: [00:01:00] [00:02:00] All right. Ev, thank you so much for joining me.
Ev: thanks for having me.
Grant: I'm so excited to have this conversation as listeners will find out, hopefully throughout this conversation, we actually competed head to head for some number of years in, you know, with Replicated. And, you know, initially what Teleport was called, or the company was called Gravitational.
So should be fun.
Ev: Yes. It's actually a very interesting topic that I think like how tech CEOs who tend to be competitive, ambitious people, how they treat competition generally, like, like even mentally. Like how much competition is, like, how much is too much, like, what happens if you don't have any kind of competi competitors.
So, it's a really interesting topic, I think, to explore.
Grant: Yeah. It, you know, one, one I still remember when you [00:03:00] got like this series, I'm wanna say series A funding from Kleiner. I like heard through the grapevine that it, like that you had gotten funded. Kleiner was doing the round, and I, and it was like right before like Kon, north America, and I was just like, we need to launch this next product before they get that funding announcement out before.
And like, it just like, it like pushed me so hard to like really go. It's just funny how those things work, right?
Ev: Yeah, so my view on competition has actually evolved over the years. So when I was younger, I was just absolutely I would actually get kind of crushed when I hear that like, you know, my competitors raised more money or they landed like a huge customer. I think it's understandable just like human emotions, like we feel.
We're failing if competitors doing better. But then what I learned over the years is that your competitors actually, they're your natural friends, not your natural enemies and friends in the sense that we share the [00:04:00] same dream.
Grant: Yeah.
Ev: It's kinda interesting, like you start a company 'cause you're unhappy about the state of the present.
You want futures to be better, but better in, in a way that you like. So guess who else likes the future to be exact same way. Exactly. So like, like after that it became much easier for me to compete. 'cause now we're like basically two teams that are kind of rowing in the same direction. And it's just it helped me too to be kind of mentally more well adjusted I guess because, you know, startup running a company is is stressful.
So that reduced number of amount of stress that I was dealing with.
Grant: Yeah, no, that makes sense. I always try and even still today I just don't think about competition that much because I'm like, you know, I'm, it's funny, I like this is like embarrassing to say, but I often like, think of myself more as like an artist than anything else. Right. And I'm like, like I'm, no, I'm trying to, I'm like creating the art, the thing that's in my mind, right?
I'm a builder and so. I just, I'm like, I want like an almost [00:05:00] unadulterated view of, you know, what I'm trying to create and the vision that I have and not like somebody else's thing and I don't wanna get pulled by them. But I don't know. I, so I've never really been that bothered by competition, but occasionally, you know, something happens that would like kind of light a little bit of a fire for me.
So
Ev: Yeah. Yeah. And you do have responsibilities, like imagine you're having kinda all hands meeting and like, all these people who work at your company, they look up at you and they want to hear your thoughts. Like, hey, like this competitor just raised a bunch of money or did something else that you you need to share your opinion with the team.
So that's kinda where stress is coming from was for me,
Grant: That's a great point.
Ev: Yeah.
Grant: Yeah. That 
Ev: or you board your investors, like, Hey, like, what do you think about that? How did you allow that to happen? So it's easy to be stressed out.
Grant: Yeah, no, that, that point about like the team gets more concerned about it, I think is a really great point. And kind of managing team psychology. Right. And like, because they don't all have the same psychology that you or I [00:06:00] might, and, you know, and they're thinking, they're seeing something that's competitive.
And I, I don't know. I mean, like, how did you or there any times where like, you know, a competitor did something that really kind of lit a fire or changed how you thought, saw things or made you do, you know, go one way or the other? Like how have you kind of handled those competitive nature?
That
Ev: Let's use an example. So there was a prospect that we lost to you actually. So we were kind of shocked that like, replicated. Got it. And because I'm an engineer maybe I immediately felt that something's wrong with the product because like, hey, there is another tech company that evaluated our solution.
They evaluated, replicated, and they felt by the way I'm assuming the audience knows what Replicated is
Grant: Yeah. 
Ev: Okay. So yeah we all help SaaS companies to deploy their software as a service into on-prem environments. And in, in that particular situation, yeah, it just felt really heavy. It's like we worked really hard for a couple [00:07:00] years.
We felt that we solved our, like all these like really challenging problems in a. Compelling, you know, kinda academically correct way, and then somehow, like these companies apparently better, like, what did we miss? So that was really hard. But what happens then is like you evolve and you realize that product is only one of several components that are involved in enterprise sale.
We could talk about this maybe more broadly, how software is being acquired in the enterprise, but, so that was an invitation to basically expand my horizon beyond product and product only, and look at things like, like how you positioning it, like how you communicate to value. Because when you say like, we help you deploy software on-prem, okay, fine, but what do you mean?
Like, do you, like, are you like just copying, you know, bits over the internet, but you could use like secure coffee for that. So, so, so that was the moment. It was like invitation to learn like more about the world, [00:08:00] how it works, what motivates people. Who do you sell to? Like for me, like my previous company was called Mail Gun, by the way, that's another interesting story about the competition that may maybe we can go back to.
But, so that was kinda self-service, high volume, transactional business. So we had like a web form and a website. You go sign up, there's a pricing calculator, you use your credit card, and then you basically you don't have to meet a customer. So I never gotten that education. And that example with replicated beating us when we were trying to close the deal with the company in Seattle, maybe you even remember who that was.
Grant: Oh
Ev: So that, that was kind of opening act for me to get street smart about how enterprise buys software generally. And I think we've gotten better since then. Far better.
Grant: Yeah. If it makes you feel better. Eventually they churned off of us and went to something else. So that was a sad moment for us too,
Ev: That's another learning moment for you, right?
Grant: yeah. Exactly. Yeah. Yeah, it was I think [00:09:00] our learning there was that, you know, so this, if you're thinking about correctly, I think it was this big kind of like early AI company that oh shit, it was UiPath is what I'm thinking about is.
Ev: okay. You said it, not me.
Grant: great. So it was U iPad and yeah, that was a really intense sale actually. And it was actually at the moment where Replicated was we had just launched this product called cots, which was pretty cool because it did two things. One, it like deployed into existing clusters, then it also would de like deploy Kubernetes when the customer didn't have it.
And that was like, we always position it as the full spectrum of customer deployment. But that sale was a really intense one. And we had found really good product market fit then and you know, we had just started to scale it up and it was all kind of working. And actually we, they, they did quite succ.
They were quite successful through replicated for some amount of time, but then eventually they needed 24 by seven support, which we didn't have. We just, we were like a, probably at that time when they wanted that. We were a 30 person team. We just didn't have that many people that could support it.
And we just, I think. I [00:10:00] told 'em no, that we weren't gonna do that. And so they left for Rancher. And they used Rancher, which was, had a much bigger support org and gave them that support. And it was a, you know, and then it was actually, it was, it took 'em like years to wind down off of our products because our, you know, our products were pretty sticky.
Ev: yeah.
Grant: but yeah, that was that was a lesson there. And eventually we had 24 by seven support. So
Ev: Yep. Yep.
Grant: what did you kinda learn from that process? Like, what did, what was your learning? You know, more, it's more than just product. It's also, you know, kind of how you position everything else.
Ev: I think the lesson number one was that if you simply say what you do, that's not enough. So you say we help software companies to deploy their solutions into customer premises, but many, but what? There are multiple problems hidden behind that statement and those problems, solutions to those problems are not equally valuable to the person you're [00:11:00] selling to.
So some people hear that statement and they would just simply because of their title and responsibilities, they'll be like, oh, so you help us count how many licenses they're using. Other people will say like, oh, and you help us. Do like software upgrades remotely and securely, and someone else will say like, oh, you're gonna help us with like remote support, because now we have visibility into what's going on.
Like you see like completely different angles
Grant: Yeah.
Ev: and it's impossible for you, particularly in the early stage to do all of that or all of that. Well, so then when you are presenting your solution, you really need to articulate the unique value that you are bringing, and then you're explicitly stating what you don't do. So, and look, it's a never ending process because you can only become better by practicing because it's impossible to guess these things. It's like back then I never even met anyone who worked like at a big financial institution. So if you. If you close like several deals [00:12:00] to large tech companies, you know, like a, you know, like Snowflake and Dropbox, like people like that.
So they have completely different concerns and they're, they have very different backgrounds for, from someone like Wells Fargo or JPMC, or I dunno, like BlackRock. So you only learn to a tailor your message and your value proposition to markets you're serving as you're doing it.
which basically means there are plenty of opportunity to be disappointed because initially it will always be bad, like try to go sell your software to like manufacturing company.
You're gonna be prepared to be surprised, like what kind of questions you're gonna get during that cycle. So that's basically the kinda lessons that we were learning back then, like when we were presenting our solution. It's actually, maybe it's worth. Explaining to folks who are familiar with Replicated what happened to Gravity, our competing solution, why we don't, that we don't do that anymore.
So
Grant: and I also maybe even rewind I think the vision you have for Gravity was also a, like a bigger vision that we ever had for Replicated, like You [00:13:00] Replicated was just about helping software get deployed into these remote environments. I think I've listened to you to talk about the vision you had for Gravity as like this operating system, you know, for the cloud.
And it's like, it's just, it's a much bigger vision and really interesting and so I think you can tell the whole story about it and then, you know, obviously wanna hear more about Teleport as well, but yeah,
Ev: yeah let's talk about this. So isn't it interesting question to ask ourselves why deploying software in the cloud is so hard? 'cause back in the day before we had this massive cloud environments and we were, again, it depends on on your age, of course. So if you just enter the field, you probably don't, 
Grant: a little history
Ev: It e exactly. Like back in the day before software, like people used to run software on like individual computers, like on their desktops. Or like a company might have like a giant server in like in the basement and you would put like Oracle on it or something. So back then deployment was not a problem.
Like sometimes it's as simple as drag and drop, it's just drag and drop file and you click on it and it runs, like even today [00:14:00] when you like deploying software from like Apple app Store onto your phone or your laptop it's actually kind of trivi like why is it not trivial in, in a data center?
And some people will say, oh, it's because of scale, it's because of the complexity. But hey, you know what, like what, what's happening on your laptop is actually also insanely complicated. Your laptop has millions of lines of code running on it with like dozens and hundreds of processes and actually microservices, I would even say.
And yet it's still trivial and. And the reason for that is the operating system. So it provides just the right amount of abstraction that allows you not to think about things like users and authentication or like, which, like storage management or like all of that is taken care of, but we don't have that concept in the enterprise.
When I say in the enterprise now, I basically mean cloud environments. So if you look at any company that is building and running web applications at scale, or not even like at scale just web apps, [00:15:00] period they always have a SRE team or platform team or cloud team or foundation team, but you know who I'm talking about.
So these are engineering teams that are not building the actual software, but they're building and maintaining these environments. Those teams are actually quite sizable. Like some companies even say it's almost as as big as our kind of core software engineering team. And you ask us, well, what do they do? I would say what they do is they develop and maintain a custom operating system for the environment of their company. So, you could pick any tech company you want, like, you know, snowflake Dropbox Twilio, like anybody. So, like GitHub, they have DevOps teams. Those DevOps teams, they develop these platforms that the rest of the company runs on.
So the question is, why do we keep developing custom operating systems like every single company out there built their own custom os.
Grant: Yeah.
Ev: I like to look back at the history and yes, indeed. That's how, actually it used to be like way before, like before [00:16:00] IBM mainframes, like early computers, before they roll out with the 360 system you would buy a computer and you would basically build your own software from scratch for it.
That was no standardization. So that's actually what made IBM huge is that they made programming kind of portable. So you could build an application, run it on a machine, then you get a new version of the machine and it just move your application to that other machine and it will just work.
And I just feel that because history is evolving on a spiral, right?
We are going to inevitably end up with someone developing an operating system for the cloud. I was hoping Kubernetes would be it. Maybe it will. It's hard to tell, but so that, that is what the idea of Gravity was coming from. So even though. Like, at the time I was thinking like if we try to build an operating system for cloud software, it would be incredibly hard to get it to market because you have to be [00:17:00] huge.
It's not the kind of project that a startup can take on. So then you have to develop this kinda a path between now and this bright future. So you need to have some kind of intermediate products that you can launch along the way. And it just so happened that helping companies dev deploy something on-prem could be the first use case that we can go after with these hopes that eventually, it's kinda like Tesla.
First you build like a Roadster and you use that revenue to fund your next project, and then eventually, like 10, 15 years later, you become this giant company. So we were using on-prem deployments as this kind of stepping stone towards developing this operating system. But what happened then was that.
It kind of happened the exact same way. So when we were people looking at Gravity, and it's just because of the first few customers and use cases that we had at the time, security was extremely important. So like the one thing that Gravity had going for it, that it [00:18:00] had incredibly well implemented and identity management systems within a product, and it was architected as a Golan library.
It was called Teleport. But the basic idea is that if you have a computer. Which is which is a computing environment in this case. So from a gravity perspective, and I guess from replicated perspective, so you have an environment, so that's your deployment target. So you need to bring everything that will be running there.
You need to have like a Kubernetes cluster, you need to have like a couple of databases you know, like web servers, like microservices, like all this kind of complexity. But all of them needed re remote access and remote management. So you have this idea of a user account or and it exists in MySQL and exists in Postgres, that exists for Linux, that exists for Kubernetes.
So there's kinda fragmentation of identity that's going on within an environment. It was extremely important for us in the early days, again, because of customers so that were in front of us. So [00:19:00] they were influencing our roadmap. We very quickly realized that we need to have a a unified identity layer on that environment.
So if I am f and I need to remotely access any of these components like Linux, MySQL, Kubernetes, what, or Grafana what whatever, I need to have a single way to log in and I will be me when I touch any of these things. So if you think about, that's exactly what operating system does. Like on your Mac, you have an identity system.
So all the users, they have user IDs, all applications, they have PIs, process IDs. So it's impossible to be anonymous on a computer. And that was the exact same requirement we had for Gravity. And when we started, acquiring more visibility, like people started to see what we're doing. So that identity management component started to become more appealing to people.
And they said, Hey, I don't have a use case to deploy anything, like anything OnPrem, but I really like the way [00:20:00] how you guys do kind of SSH at scale, for example. So that is when we realized that we now have a bigger market, like outside of on-prem deployments if we just focus on identity management.
So that's kinda what happened there.
Grant: Oh, that's really interesting. And so just for my knowledge, when you said like, you know, remote access, right? Were you thinking this is like the vendor, is you getting remote access to the cluster or to the environment, or is it the enterprise IT admin. That's remo, like getting remote access to the environment.
Like who? Who is
Ev: neither. Neither. So we were heavily influenced by what we call now MSP, use case managed service provider.
Grant: Oh
Ev: example. You have some, I'm hesitating using names of real companies, but I. Let's just imagine you have company A that builds software and then and then company B wants to use that software, but because they don't have their [00:21:00] own operations team, they work with a managed service provider and that managed service provider manages software for them.
So there gonna, there's triangle, there are three companies involved. Again, one is a vendor who makes software. Another is consumer company that needs to consume that software, and a third company kinda manages that software, which is actually happens all the time. If you look at like government, if you're selling into federal use cases, happens all the time.
So how do you manage that triangle of three different identities? So we saw that as like, like the problem number one to solve almost like problem number zero. So Teleport is actually older than Gravity because the very few prospects we had at the time, they had that requirement that we need to manage this MSP triangle.
We realize that identity management is even more important for us for that prospect than actual process of like software deployment, like moving software from A to B because it's actually really complicated. So if you have, if you are an MSP [00:22:00] and you work and you are an engineer as a, as an MSP, so you have multiple customers or clients, so you need to go from one environment to another, but do you keep the same level of permissions?
Ha It probably depends on what kind of customer you are servicing. So, 'cause some customers will say like, we want engineers who are accessing our environments to be, I don you have like security clearance or to be tested for drugs and whatnot. Like, they have all kinds of requirements. So you have then the need to dynamically drop or elevate privileges based on which tenant you're servicing.
So you see it almost like, it's almost an accident that we ended up being an identity management company super early. Without realizing it, we didn't realize it for a very long time. And the forcing function that made us realize that the most of the value that Gravity brings is identity management.
It was COVID. 'cause COVID forced everyone to reevaluate their kinda [00:23:00] identity story COVID accelerated frequency of identity attacks in so that really what brought so much attention to our solution because it's, I will say something that security people will just find pastors, but we do have technology to make your infrastructure unhackable. So that's what kind of brought the spotlight on Teleport and this is what allowed us to kinda abandon kind of on-prem deployment use case.
Grant: Yeah. Okay. So, it's, and did, were you selling directly to the MSPs that they were like your customer or they were just really involved in your relationship with vendors? How, what was the
Ev: So ironically, we didn't close any deals with MSPs with gravity. See, that's kind of how funny these things are. Like in the early days when we had no solution, we found more kind of interest from MSPs. But when it was actually ready to deploy than apparently it was like SaaS companies, like tech companies, basically exact same kind of companies that you sell you, [00:24:00] that you selling replicated to.
That's where we found success. So, which is really weird. So we built this amazing capability that actual customers that we were targeting didn't buy in the end, but it brought us a bunch of other interests from other groups of prospects who found that more appealing.
Grant: Yeah. And then, and you kept developing Teleport, was it like a separate project to begin with, or was it like, okay, so it was always a separate project.
Ev: I'm assuming your audience is technical. So the one thing about like Golang is that it's it's a language and a ecosystem which is pretty good at packaging. So Gravity, and it still sits on GitHub. Anyone can go and find, take a look. It was always kinda neatly broken down into this kinda libraries.
so we had like one library for like working with Docker containers, another like one for managing Kubernetes and so on and so forth. So Teleport was a library actually for managing access. and then when people started [00:25:00] asking us questions like, Hey, how does Gravity do this? And that all we did, and it actually took us very little time.
I wanna say maybe less than a week, we built command line tools that were just teleport only. It's basically here is kinda access minus everything else. And I personally was even thinking like. These are just examples of how you support library. But then we just kept evolving and eventually they just turned into you know, Linux, Damon, CLI tools and so on and so forth. So
Grant: interesting.
Ev: I just think it's yeah, I guess the lesson here is when you design your solution early on, make it composable so it would be easier than to the retire components that are not as useful and easily integrate things that you're missing or missed in the early days.
Grant: Yeah. And then, okay, so from what I heard you say in some other podcasts, like you, you basically had Gravity and Teleport, teleport, maybe one or two [00:26:00] engineers and it was like half your revenue and like you had like nine engineers or something on, 10 engineers on Gravity, and it was the other half.
And it's like a lot more work. It's a lot harder. And so you were just like, oh, this is clearly, there's more pool here. It's maybe a better business. People are more willing to pay for it. So, and there's better growth here with Teleport. So let's just make the pivot and go over
Ev: I like listening to you when you say that because it's it seems like a very obvious and easy decision, but it was actually hell in the moment because the, like, the craziest thing was that we ended up having these two revenue streams, teleport gravity, and and at the time we didn't have venture investors.
It was just basically founders. So we made this agreement that we're gonna keep watching, like the revenue, like once one product becomes, begins to outpace the other one, we're gonna shut the other one down. It's easy to you say that, but then you start watching like one quarter, second quarter, and they're like going neck to neck and you're like, damn.
It's like you are rooting [00:27:00] for one of your babies to die, right? Because you're realizing that it's not sustainable. You cannot have two products at the same time, but you'd be like. You close one huge gravity deal and it was like, oh, gravity, yeah, it's gonna be our future. And teleport is just kinda limping along.
Then next month you'll close like a really nice teleport deal and it's like, ah, and you almost disappointed. But as I said, COVID created like a lot of clarity around that. So, teleport sales became to outage gravity quite significantly, and it was actually an easy decision. It took a while, but it was easy at the end.
Grant: Yeah. It's and I mean, I, I. It's an, it was an interesting moment for me when you announced it because I was like, you know, again, I, we had been competing pretty much head to head for some number of years. Not in every deal, but, you know, in some number of deals we'd see each other. And it was you know, like, it was like, I guess this is good news that we no longer have this competitor, but like, it's also like somebody exits the market and [00:28:00] to be honest, like the replicated and gravity, like, you know, market is not an easy market.
Like, it's like, it is a, you're, like, I always say you're cooking for chefs because you're basically building software for other people who are building
Ev: Yeah. I like that analogy. Yeah.
Grant: have this high expectation of everything and the ecosystem was moving so fast around Kubernetes and Cloud Native and Helm and all these other things.
It was like you didn't know what was gonna come next and where everything was gonna go. And and we saw a lot of. A lot of like, kind of unique like architectures and people taking different angles and approaches and it was like a kind of like, oh shit. Like this is like a little bit different for this customer, a little bit different for that customer.
It's all the same technology, but like, you know, somebody else wants something new. So I mean, it was and I think we were probably like, we were doubling year over year around that point, right? So like, we were just growth, but we not, we weren't doing much revenue at, you know, end of 2019, we were probably doing 3 million a year.
You were probably [00:29:00] somewhere in that range as well.
Ev: Yeah, actually feels right. That's
Grant: yeah, somewhere around there. Right? So like, neither of us were behemoths and but like, so I remember being like, oh, this is really interesting, like, they're getting out of the market. And I was like, I guess it's good. But it's like, you know, there's, you know, a little bit of like, okay, is grass greener over there?
Like where are.
Ev: But it's that sadness that I was talking about earlier. 'cause you feel like that's the moment where you can feel like I'm actually losing a partner there. 'cause there was someone else who really had this like similar vision. Yeah, I definitely, yeah. I feel you.
Grant: Yeah. It's, it was an interesting moment. It's funny 'cause you would think like a competitor leaves and you're like, ah, that's great. But, you know, you're a little, you're a little like, oh, that's a little confusing. How should I feel? Alright. So o one thing that, you know, you kind of talked a little bit about before that you alluded to, was this like kind of thesis you have around how enterprises buy.
I wanted to like, kind of [00:30:00] dig in on that a little bit.
Ev: so yeah, so prior to this to, to the recording, we were talking about something that I just learned, so I cannot take credit for it. So I was having dinner with Bucky Moore from Lightspeed. So he's a venture. So he's a VC who discovered teleport in the early days, and he shared this bit of wisdom that he himself, I think learned from someone also relatively recently.
It's about how companies buy software. So like, the one naive approach to think about that, that I used to have when I was young is that companies have problems. Companies then go and buy solutions that's just completely wrong. Companies are just kind of vehicles. They're structures. They have no consciousness, they have no memory.
It's people who have problems. So you need to solve a problem for a specific person that you're selling to. So therefore, when you are designing a solution to be sold into an enterprise, you need to have a very [00:31:00] clear idea who's specifically going to buy it. And it's not just about the title. Like, oh, we're building for VP Engineering, they're gonna buy it, or it's director of engineering, or someone in marketing.
No. Like, you need to be very specific. It's like, it's a company where in engineering, for example, it's not a cost center. So even start with like just grabbing like the team, the circumstances, the context in which that persona, is living because it's the context that creates problems.
And then you try to design your solution to fit those specific problems. But then once you begin to learn, is that the problem? Who has a. The person who has a problem that you're trying to solve might not have any money. So the solution then is to get budget from a person who owns the budget. So now it's like there are two people you need to consider the person who has the problem you solve and the person who has the budget.
So then you, okay, so you take that into consideration. So, which means that when you articulate the [00:32:00] value of the product, or maybe there's some product now needs to have some capabilities that will appeal to that person as well. So now you basically need to solve to two. Then you realize, oh, hold on a second, there's a third component here.
'cause the person who has the problem might not necessarily be the person who will actually be the user. Okay, so if we take a, like, let's just say you're building a better SSH server. So the person you're selling to is whoever is responsible for protecting servers. 'cause you like, they want like SSH to be awesome.
But that person is not gonna be like typing SSH on the keyboard every day. Okay. But yet you still need to please the actual end user. So now I have three people that you need to please. Okay. And then particularly with larger enterprises too, you realize that there is another person, like a fourth one who has the authority to buy.
Apparently it's not the same as having budget and it's not the same as having a problem. And the observation is that. If those four personas are four [00:33:00] different people, you are not going to succeed, which is kind of paradoxical. So you might have a solution that solves the original problem in the most elegant and cost effective way.
But because every time you tries to close a deal, you need to have four conversations with four different people. And all of 'em are super busy, and it always takes like weeks to schedule and reschedule. So your sales cycles will be long. The cost of acquiring customers is gonna be high. So you just economically that is not the kind of business that venture capital can effectively support.
So then it means that you will not have access to cheap capital and your competitors will just zip by you. So the solution then is you need to, I would even say it starts with product. You need to design your product in a way, and you need to communicate value in a way where those four persons personas are compressed down to one individual.
So essentially you stay away from. Products that require buying Committee of four and try to have it [00:34:00] compressed, ideally to just one person. So when people, because it explains what happened with Wiz, everyone is absolutely amazed by that success story. The first of all, the product is great, it solves a real problem, but there are plenty of other products that seemingly great.
Okay? But the interesting thing about Wiz is that the person who buys Wiz and the person who has budget and the person who actually uses it and has authority, is the exact same person. So that allows you to be extremely efficient, and that's where that hyper hypergrowth comes from Again. Having all four compressed into one.
That's the ideal situation. It's not always possible but definitely not four. So now as I'm kind of thinking about like in terms of this framework, and I wish I remembered who was the guy who originally kind of talked about it. 'cause I do want to give credit. I really appreciate the elegance of it.
So I'm trying to optimize Teleport to like our GTM needs to be that the buying committee should be no more than two people. [00:35:00] We already know that most likely, we'll always have the separation between the user and the buyer. Simply because Teleport is a solution that engineers actually use, like practitioners.
'cause you need identity for them. You need identities for laptops, you need identities for servers, for ai, for all kinds of things. So like exec's not gonna do that. So unfortunately that's already gonna baked into the product. We cannot really solve that. But now we are thinking about. If you identify accounts we should go be focused on and selling into.
There needs to be account ideally where the problem the person with pain, like basically risk management and the person with budget and buying authority needs to, it needs to be exact same person. And now when I look at my pipeline and like, which deals are closed closing faster and which ones are slower, the, like, once you see that correlation, it's impossible to ee like where it's one person that's a really fast sales cycle.
Like even like with a giant logo, [00:36:00] I know it's like 60 days and you're done. It's a really large deal. But the situation where it's like three different people, like, oh that's that's difficult. You're basically seeing like most time is spent, just, even scheduling takes so much time because you cannot get three in the same room.
Like their calendars just don't overlap. Like there's just no way. So, so there's a lesson there that I really appreciate. So thank you Bucky, for sharing it with me.
Grant: Yeah. And it's actually interesting because I think about like, if I boil it down, like partly explains why maybe it's easier to sell to like small kind of startups and you know, these kind of companies. 'cause it's like early on it's like the CTO,
Ev: Yep.
Grant: Or like the ceo, you're selling to one of those people.
They might have all of those things, right? And then as the companies scale and you start to sell to bigger folks. And then to like, then you're, then there's a book that I love called called the Challenger Customer. It's the follow up to the challenger sale. And it's really about this consensus buying, right?
Because to your point they make the point, have you ever read this book?
Ev: No.
Grant: [00:37:00] So they talk about this process of, they're like, you think selling software to four people is hard buying software when there's, you know, five and a half people in the room that have to all get aligned is even harder, right?
So they're like, you know, they're, and it's like this interesting perspective of then how do you drive a consensus sale? What does that require? And
Ev: what's, sorry for interrupting, like, but there is dark side to this too because if you think about what kind of problems exist out there and are worth solving so there are some problems that just basically have no other solution. It basically means that the existing framework in which enterprises acquire software prevents certain types of products to be built in the first place.
'cause you'll be forced to deal with four different people.
Grant: Right. I mean, so their research will tell you that like the average buying group is actually 5.4 or something. Right? So like most, so, so most people are actually selling to like a pretty large buying group in [00:38:00] general. And that, and to your point, it's, it almost certainly slows down sales cycles and slows down the process and gives you lower, you know, conversion rates and all those things.
So I think maybe the, like if you can compress it to two people, you're probably gonna end up with higher, you know, conversion rates and faster sales cycles. But their point is like basically just most sales are just require more people to be bought in. And. There's, yeah. So that's, I think it's a good objective to try to like, get as few people needed as possible.
But I don't know that it's like the, I feel like still in the world, a lot of people are gonna sell to multiple people, so,
Ev: I think there may be two lessons there. Lesson number one is that, just think about this super early in your product design cycle. Because maybe because when we were starting Gravity we had the security included. So for that reason, we, like, we had to address security concerns early on, but you could have visually designed a product or.[00:39:00] 
I dunno how you guys dealt it on replicated side, but if you don't even talk about security, then security person might not be involved. So in our case it was maybe beneficial 'cause in the end we found that person to be the most impressed with our solution. but you really need to think about who those like four or 4.5 people are going to be.
And the second lesson, which is may be more applicable for people who already started companies and already have products. So then like that's that ship has sailed for them. at least it helps to include the org chart considerations into your kinda lead qualification. So for example, at Teleport, I love asking prospects if I get a chance, of course I ask him who's responsible for security in the organization.
So what I'm looking for is, a couple of clarifying questions because it means that they actually get me and they will say, well, basic security, do you mean like how do we secure our, like AWS environment or how [00:40:00] do we secure our kind of office network and printers and stuff? So that's a very helpful cl clarification because they already think, because they're already realizing that those are very different security functions.
Grant: IT security versus like application
Ev: yeah. Yeah. So then you realize, oh, they have a security team within it.
Grant: Yeah.
Ev: and then they also have security team within platform engineering. And it was like, okay, now we need to be really careful to only talk to the latter team. Not, I'm sorry. Yeah, the latter team, not the former. 'Cause first of all, you don't need additional cook in the kitchen, and secondly, you could tailor your message to that one particular individual.
So studying org charts of. Accounts you're trying to sell to, that is definitely helpful. But again, that only works if the average contract size allows you to do that. Because if you're closing, I don't know, 50 bucks a month deals, you just simply, like, there, there is no way you're gonna look at someone's org chart.
So, so that's the second actionable thing that we started doing and I think it's it's bearing fruit.
Grant: yeah. I think, [00:41:00] you know, I, it is interesting. So like, one of the things that, I've almost say a different approach to it, I've actually pushed our team to make sure that we, 'cause we generally end up selling to director of DevOps and maybe a product person. And like CS has a little seat at the table and support has seat at the table.
It's like kind of the four people.
The director of engineering for us, or director of DevOps is kinda like the core buyer. But I've taken the approach of I want everybody at the table as soon as we can, so they all have a chance to say no. And they all know that there's like value that we're trying to bring them in our platform that like, it's gonna make this easier.
And so I, my position has been like, get 'em to the table as early as possible, right? That way like they're involved in the process, they feel like they can support it. And rather than like try to keep them out of it and then just try to do something that, that drives that consensus so they can all get aligned around like, oh yeah, this is valuable,
Ev: Can do you allow me to play devil's advocate here?
Grant: please. 
Ev: So here's an alternative. Look, I'm not saying you should do that. It's really easy [00:42:00] to say like, to give like unsolicited advice, but it's much harder when you actually run a company. So imagine an alternative situation where you say, you know what, let's take our product and double down on just one capability, which is license enforcement.
Grant: sure. I.
Ev: We just don't do anything else. Just like shrink the scope of what you can do, then it probably means that the contract value is gonna be smaller. 'cause now there's like less of a benefit, right? So we're not gonna help you take your software all the way to like on-prem, your customers we're only going to help you like collect revenue and do license enforcement, then your deal's gonna be faster though, because you don't need to have all those four people in the room.
Like support now, doesn't matter. And it's really tricky to kind of calculate that trade off. Do you go with a smaller product with kind of smaller scope, but highly optimized for a specific buyer In this case, I'm not even sure who [00:43:00] that would be. Maybe you probably know better. Who cares more about kinda licensing on the buying committee?
So. At least it's helpful to run these scenarios in your head. That's, what we are kind of circling around here. Like there's no right or wrong answer. 'cause it could be that if you gather four or five or six, whatever people in the room and you please all of them, but then you can charge like $10 million a they are from that account.
Like, yeah, maybe it's worth it, it's gonna take a year. But it's a pretty big contract. But sometimes it's just not worth it.
Grant: Yeah, totally agree. I mean, I think, you know, generally if you find the ASPs anywhere, you know, a hundred K or something, right? And you're selling to a group and then you exp expand and you plan for expansion, like you can, I'm, I think it's way better to be whizzed to your point. There's an advantage in being whiz and having, you know, and if you can really find, I'm sure they have some amount of buying committee like that, you know, 'cause it, they're selling really big tickets.
But if you can find where there's actual real benefit and the person who's [00:44:00] buying it has the problem is gonna use it like, you know, and has the budget and authority, all those things. That's a great
Ev: Yeah. Yeah.
Grant: yeah,
Ev: Like maybe even simpler example to understand would be Salesforce, again, I'm not old enough to remember how it was before, but think about like how like the original Salesforce product was sold. The buyer is VP of sales. So that person has the problem, like they need to keep track of what's happening with all the, you know, like, that person's gonna use it actually also 'cause they felt like how they have this reporting capabilities and so forth.
Of course, they have budget and of course they have authority. So your entire sale is like freaking, let's just, again, ideal one meeting. How sweet would that be compared to replicated or teleport or like most other companies?
Grant: yeah, it is. I've always said, and it's funny, you know, funny, I think there's a little bit of grass is greener sometimes. I always joke that like selling to revenue and rev ops teams is like the, I. They, they want to be the buyer that they like hope to someday encounter. Right? Like, and so they're, you know, they [00:45:00] try to be responsive and they try to, you know, tell you what you need to do in the deal.
So, yeah, I think selling to those teams can be a little bit yeah they like to buy, so,
Ev: Yeah. But if you if you put business aside and just think about quality of life in general, I would say that my favorite buyer is always in, is in engineering engineers. And the reason is I get to learn from them about their industry. So if you're talking to, I don't know, like some FinTech company, they do high frequency trading.
You learn how high frequency trading works. So then you doing a deal with I don't know, some kind of like government contractor that works at like, on like military technology and you learn like things about missiles and then you learn about like oil and gas. And like that to me is just, I'm absolutely addicted to serving this kind of broader engineering community because these people continuously educate me.
On how the world will live in operates that's the most kind of appealing feeling in the world. So, it probably means it's gonna be like I could be building [00:46:00] products for other engineers my whole life. I'm just addicted to that feeling.
Grant: that makes sense. I mean, the other advantage I'll say is they generally give very good product feedback and things that you hear and you're like, yeah, we should do that. Like, I can't, there's like so many meetings that I've been in and I was like, yeah, I don't know why we didn't think of that yet.
Like that you are absolutely right, we should do that right now.
Ev: Yep yep. Yep.
Grant: it's and that, that actually kind of, one other thing I wanted to bring up that, that reminded me of is this idea of like, okay, you get product feedback and you want to be able to implement it. Right away because you're like, it's just so good.
I need to build to, that's this concept that I'm pretty obsessed with that I call product velocity. Right? So it's the ability to like hear something from a customer that you're like, obvious, no brainer, we should do it. And instead of like creating a Jira ticket and then like, you know, maybe somebody, you know, has to triage it and put it through the PI pipeline and like, [00:47:00] you know, prioritize it.
And it's like, you know, six months before anything, ever touch anyone ever touches it. I think organizations with really amazing product velocity are able to like, turn that ticket around in like 24 hours, right? And just get that out and be like, that's a no brainer. We should do it. And then you just do it and there's a lot less process and there's a lot less like, you know, overhead or something happens.
How do you think about, do you think about product velocity? How do you think about driving that? Like, you know, I think Wiz has it, I think like CloudFlare has it, you know, but like who else has it and like, is, how do you think about it?
Ev: So first of all, thank you for suggesting I will, I'm stealing this term product velocity. We're gonna use it internally more frequently now because we definitely described the phenomena, but I don't think we ever had like a one specific term too in it. So we'll do that. Thanks. And it feels to me that it's one of these problems that simply don't have like one single solution because you can ask yourself where is that [00:48:00] feedback coming from?
And oftentimes there's a mismatch between your kind of expectations you're creating and what your product is actually delivering. And then they give you this feedback, oh look, this thing is missing. We expected it to be there. And yes, it makes sense. Especially in the very second when that feedback is delivered to you.
because if they're good at communicating, they will make you feel like, yes, it's badly needed and it's no brainer. But then if it's, that's obvious, how come you didn't think of that? And it goes back to this context that I was talking about earlier. Like, we make decisions within the context.
So it's mismatch of contexts, the context you are in when you design the capability, in the context of a customer when they suggest that to bridge that gap. So why did you allow those two contexts to diverge? So when you're making a sale, when you're putting solution in front of someone I would argue like first you need to invest into management of their expectations.
Grant: Sure.
Ev: So, [00:49:00] so that cre that creates a separation between meeting their needs. And just dreaming together. Because then once we make you happy, your product is like, like our product is in production, we solve your problem, everyone is happy. Like, come to our user conference or customer advisory board, whatever, then we can dream about all these like wonderful things we could do.
Like, that is different though, because there is like there's no money involved because you solve the problem. But if that becomes a requirement, suddenly, so that means you mismanage their expectations. So that's kinda one thing that, that we try to pay attention to,
Grant: Sure. I love
Ev: like managing expectations of customer.
And the second one is let's call it a human capital problem. So I think we would all agree that every single employee that we bring into our companies. If every single employee was just like genius, super energetic, extremely creative, PhD [00:50:00] of whatever, yeah, life would've been easier because we have super humans working for the, for us, but that's not the case.
There are all kinds of people, like people have families, people sometimes people get tired. Like, like humans are genuinely unreliable. And so it is our kind of role to to enable them, to elevate them. And if to give a, basically talent development is just as important as product development. Getting rid of underperformers on time.
So all of that plays a huge role. And why am I mentioning this? It's because a lot of 'cause when you shared this concept with me initially, I thought about like, I think we're pretty good at implementing customer feedback, but then I realized that, but there's this kinda long tail of feedback. There are things that have like a lot of dollars attached to them or build us this capability and we're gonna expand and it's gonna be like extra million of a RR like, oh yeah, we're gonna do this really quickly.
Come on. Like extra million of a RR if you spend like, I don't know, 48 man hours of engineering, like yeah, [00:51:00] it's an it's one of those node brainers, but then there's this kinda long tail of improvements that don't have direct kind of path to revenue attached to them. They make sense on the surface.
And sometimes it could be as simple as let's improve that error message because we're getting too many support requests. 'cause people are confused, not by the problem, but like the error message is as con confusing and they reach out and and then you realize like, okay, so these things are fixable, but you don't want your top engineers to spend their time fixing trivial issues or implementing kind of trivial feedback.
First of all, they will be unhappy and eventually quit if you keep asking them to do that. So then you ask yourself like, did I structure my engineering team in a way. I have basically like L one, L two, L three, L four, or five engineers that all have kind of equal amount of volume coming their way that matches their skill.
So then it becomes kind of hu basically human capital management optimization. And there are probably some other like, angles you could [00:52:00] look at. Like for example,
Grant: I've never thought about
Ev: IM, it's important also to,
Grant: that's great. Yeah.
Ev: I think it's also important to have a vision. And in that vision, you, yeah I think it's probably related to articulating expectations, but having a discipline to say no to obviously good ideas, that probably also adds a little bit to increasing that product velocity.
Like for example, at Teleport in the early days, we started hearing requests for adding support for RDP.
RDP is a Linux. It's a Windows equivalent of SSH for those who are not familiar with Windows. And yes, it makes perfect sense because if you zoom out, if you just if you go east of Silicon Valley, like most of the world, like the windows is still like predominant operating system.
So not supporting our DP is just strange. And we didn't have immediate customers who were willing to pay us millions of dollars for it. So like, yeah, how do you treat that [00:53:00] feedback? It's like people say, it would be nice to have windows, particularly when not a single person at your company is like a deep windows level expert.
So this is where vision needs to come in, where you say, we believe in such and such things and here's our long-term roadmap. We're gonna do it no matter what. Because if we don't do that, like we're not gonna realize our vision and Windows was on it. So yes, we had to go and make that painful. Step, acquire deep expertise in Windows internals and like kernel and kind of, and security model, and eventually become like one of the best implementations of remote access into Windows.
But that, I think, plays a role as well. Just sticking to your original vision and being disciplined about it.
Grant: That's really interesting and has like, just has the windows like kind of investment paid off.
Ev: Yes, because again, our vision, and I'm like trying not to sound [00:54:00] like a, like an ad for teleport, but look I do think it's important. So here's what teleport business is fundamentally about the, all the hacking that happens at the end of the day, it's about exploiting human error. If humans would. We're never making mistakes.
It's impossible to hack into anything. So if you look at vulnerable software, so let's say you're running kind of vulnerable version of WordPress and someone goes through like zero day exploit and runs code and on your server, that's a human mistake. Like someone made that mistake when they were developing like a WordPress plugin or something.
Or if you get like a text message that says, Hey this is Mike. You're, I don't know, you're like one of your engineers. Can you please like help me? So like, that's a phishing attack. They tricking you into making some kind of mistake. So you might enter your credentials into like a fake login portal so that your credentials will be stolen and they will be later used to get access to your infrastructure.
So again, it's again, human mistake. So, and that's [00:55:00] ultimately if you think of it's kind of first high on, so on a high level, it's always human error. That's the first step towards ex a breach. So then are you ex, are they exploiting a behavioral error? So that's an identity attack. It's when they're tricking you into do something you're not supposed to, or are they exploiting a vulnerability and software that someone made?
So that's a malware attack. So now we have two classes of attacks attacks, malware and identity. So malware is much harder to do now, because we have patching, we have supply chain security. So we as an industry, we're getting better and very quickly at preventing malware class of attacks.
So they keep shrinking. So now over, like, it depends on which report you're using, but between 75 and 85% of all attacks are identity attacks. It means that attackers using human errors, finding a way to impersonate someone's behavior like someone or something. Okay. And [00:56:00] there are plenty of cybersecurity products.
There's a huge industry called cyber. They had this, rSA security conference just happened a couple weeks ago and they essentially all, like all of these solutions are trying to prevent human error, like, like in one particular kinda aspect. But we believe that instead of treating symptoms, we need to look at the root cause.
And the root cause goes like this. How can you design your infrastructure security that it's immune to human behavior? Like there's no relation between human behavior and probability of you getting hacked. And you can even follow this logical kind of set of questions that I could be like asking you like imaginary security engineer.
So if I say like, do you agree with me, the probability of you getting hacked during this podcast? It's directly related to probability of one of your engineers making a mistake during this like hour. It's like, okay, it's a reasonable assumption to to make. I'm like, okay do you think that probability is low or like too low or too high?
How do you [00:57:00] feel about our security? And it's like, well, it's low enough that I'm not worried. We have good engineers and we have like systems in place and like, okay, but ask you. But if I ask you, is that probability zero though? No one will say it's zero. If they're smart, they know that there is something stupid someone can accidentally do that will lead to you losing your customer data.
Okay? So it's not zero. Now start looking at what needs to happen in order for that probability to go up. The obvious thing is what if you hire twice as many engineers next year, will that probability go up? Like yes. Will it double? Probably. Yeah, it'll double. So you double the number of engineers. Then the probability of someone making a mistake goes up.
It also doubles the probability of you getting hooked. Doubles. Then I ask you, what happens if you grow your infrastructure? You now have like more like servers everywhere. Most people will agree that yeah, probability will increase as well because there's just more things that mistake. Exactly. So then you start deploying more workloads onto [00:58:00] these things.
So you put, like you started life with being MySQL shop. Now you also have like Mong DB for some something else. Then you add, I dunno, like Hadoop, and then you add Kubernetes. Then you add like you, you deploy gr, all of these things. They create opportunities for misconfigurations. Every single thing has its own kinda authentication authorization.
So, will that increase probability of human mistake? And you will say yes. Now let's take a look at these two curves. The curve, how quickly your startup is growing, and then the curve of the probability of human error. And it's growing faster. It's actually growing exponential. So you're growing linear, but probability of human mistake goes up exponential.
So then the obvious question is, at some point that probability will be so high that you getting hacked is basically guaranteed, right? So, which means that as you scale, so my point here is that security and scale are extremely related. So at some point in your scaling [00:59:00] journey, you will have to solve for your infrastructure.
You need to decouple infrastructure from human behavior. When people ask me like, is it even possible I point in the past I was having trouble because like I could point like at some like, companies out there that I know internally how they operate, but I cannot disclose that information. Right. But like look at Apple documenting their data center design.
They have this Apple PCC private compute. They say, this is how we run our AI workloads. And that is the computing model that Teleport is trying to implement. So the basic idea is that you make it impossible to per impersonate someone or something else. So let me break that down. In a typical computing environment, you want to make sure that there is no anonymity that's going on, that every piece of hardware, every [01:00:00] human and every piece of software, they're all accounted for. They all have I IDs of some kind of identities. And everyone realizes that this is why we have machine identity solutions.
This is why everyone uses Okta with SSO. This is why we manage identities of laptops with like endpoint management systems. But if you use a, if you manage identities, different types of identities using different vendors and different solutions, you are creating an anonymity. Okta doesn't know anything about your production or staging or test servers, like it's a completely different silo of identities.
So whatever you're using for a machine identity knows absolutely nothing about your laptops. So this is why it makes it easier for attackers to exploit this anonymity that exists between different identity types. Like, for example, like you have a table in a database with sensitive data and most security people say, oh, we need to secure your database.
You need to have like, authentication. Like the connection needs to be encrypted. But the attacker says, but I can actually attack SSH. Like I, I could attack Linux [01:01:00] essentially, and I will bypass your database security. So then you, oh, now I need to go get solution for, you know, SSH security to protect my Linux and whatnot.
But then I say, I can go through your EC2 E, like API 3 3 3 A WSI gonna bypass Linux bypass database, gonna get data out this way. It's like, oh, we need to make sure we have robust, security configured for our AWS. But then I was like, okay, hold on a second. You're also running Kubernetes. It also listens in the network, right?
So I could go through Kubernetes, API, so you need to go and close that. But I can keep going. I can say, I can actually get into Jenkins. Jenkins has access to your database and they're pretending to be Jenkins, I can go from there. So what makes, so like there are basically infinite number of access paths that exist, and that's what attackers like.
Keep trying to find creative ways to impersonate someone, something to get in. So if you are mentally in this mode of enumerating every single access path, you will make that mistake. That's really where it comes from. So what you do instead, you [01:02:00] need to say, just like from operating system design, you see, this is why that concept is so central to my thinking in operating system.
There is no such thing as access path. Every application, every human, like they all have identities issued by the OS, and the policies enforce when they interact. So the access, like the path, how you get to that interaction doesn't matter. That is the core value of teleport that we say you need to have.
An in your computing environment needs to have a layer identity layer that, that knows everything about your laptops, that engineers use. Everything about engineers themselves. All of your servers, all of your environments are staging and production are different than your identities.
And then all the workloads that you run, like things like Kubernetes and clusters and databases and microservices you deploy and AI agents you put in there. So once you have identities for everyone in one place, then. Access path question goes away because you could simply say like, only these two [01:03:00] identities can interact like together in some way or shape or form.
How they establish that connection doesn't matter at all. Like how many intermediaries it doesn't matter. And the second thing you have to do, you need to implement identity in a strong, like it needs to be strongly implemented. What I mean by that is when you say, my identity is username and password, like, that's not true.
You just described an account. It's a record in a database that has econ or username and password, like, hello world. Your identity is actually me. Like identity is stored in the physical world. Sometimes customers ask me, f what database you guys use for storing identities? And I'm saying, planet, earth, physical world.
That's where your identity is stored. Your identity is combination of your biometric. It's some kind of like a pin code or a password in your head, and it's a trusted platform module on motherboard of your laptop.
Grant: sure.
Ev: That. So those are physical world objects. You cannot upload a TPM. You cannot clone it.
Grant: Yeah.
Ev: So if all of your identities and [01:04:00] your infrastructure is implemented in this strong way, so you've basically got this two extremely important things. First, identity becomes non spoof. And second, all interactions within all identity is always enforced. Now, it doesn't matter how many servers you have, how many workloads you deploy, how many engineers you hire, your security posture will stay the same.
And the interesting thing is all tech companies bigger than certain size, they all adopted this model. This is why you don't hear like China or Iran or Russia hacking into iPhones over the network. It's just not possible. Even though phones are made in China is interesting. Like we, like the security model is so strong that we can actually allow, a country that we're not friendly with to manufacture our hardware, and then we trust that hardware enough to run critical workloads on it. That is what we try to offer to everyone with cloud computing environments.
Grant: That's cool. I have [01:05:00] never heard the story or the pitch in that way. So that's a, it's a very interesting way to approach it, and I'm guessing it's like, I mean, and assuming you do this by assigning or, I don't wanna say, I guess managing those identities for everything, not just for, you know, for one thing, but actually everything, 
Ev: Yes.
Grant: identity around.
Ev: And again, the original use case was exactly that. It was gravity. It was deploying on premise because when you deploy a SaaS application into someone's environment, you don't know ahead of time what kind of components, what kind of workloads. I. Will be included, right? So some customers want to deploy MySQL on-prem, others want Postgres.
Like some, like want both. And then there's Kubernetes and SSH. So, that is where that requirement came from, that you needed like we needed an identity system that supports ev every possible type of workload. And the analogy to operating system is just undeniable. So, 'cause that's how, like, for example, [01:06:00] like this model of computing, sometimes people call, it's a trusted model of computation.
So you need to make sure that your computing environments are trusted. Again, it came from operating system research, like Linux originally didn't support it actually, but so this is where C Linux came from because military, they looked at Linux and said, we want to use it, but it's just it's not secure enough.
So we need to have this kind of complete trust. And they funded, if I remember correctly, development of it. C Linux. So we see like deploying software on-prem is like really hard if you don't have that capability. So we built a capability, but then we found that capability is actually in, there is enough demand for trusted computing outside of on-prem deployments.
Grant: Interesting. That's, yeah, it's a really great story and just like, I guess like, tell me how it's been going. Right. Like, you know, I, obviously, once you exited the direct competitor world for me, you know, I obviously followed along a little bit and saw that you know, continued have some success, but.
What's it been like? How's it, you know, have you, we I'll [01:07:00] be right. We had some ups and downs, right? Like we, you know, we kind of had this big boom. We raised a ton of money in 21, then we had to, like, the market kind of collapsed. We had to re-figure out a lot of things in 22. And it's been kind of this like, you know, like steady but slower growth over the last three years for us.
Like how's it been for you? Have, you've had to, you know, manage these similar headwinds or have you been able to it seems like you've been able to grow a bit better than that throughout, but like, how's it going overall?
Ev: so the value prop is really appealing. So the rate of growth teleport actually is directly related to how well we can optimize this GTM. Because if you were to close like a large deal like hey, we're gonna convert your tr computing to trust and computing model. Just imagine how many buyers, like not buyers, how many people are gonna be in the room that you need to convince.
And all of 'em are gonna be skeptical because like, if it's so obvious, how come like, we haven't done this before? So like, as we gradually. But like the first couple years were actually super high growth. As I said, COVID [01:08:00] definitely helps, which by the way makes all, it always makes me feel guilty. Like I moved out of San Francisco where I was surrounded by tech people.
So now I live in East Bay and like my neighbors are from all kinds of, you know, industries. And sometimes when we, you know, like you, you get together, like you, you talking to these people and you say like, oh, COVID was great. Like we tripled our Arabia a couple years in a row. And you're like smiling and you're holding beer in your hand.
And then someone says, but my dad died during COVID and that brings you down real quick. It's like, so, but it is true COVID definitely forced. So kind of SaaS industry or tech industry to look closer at their security posture. So the first couple years for us was just like amazing series A, series B.
Series C was also really competitive. Yeah, we became like unicorn, like valued a billion dollars even though our revenue at the time was less than 20 million, if I remember correctly. So that was like [01:09:00] in 2020, end of 21 maybe. Yeah. but then like the. The bubble burst it like, right. So we ended up with interest rates that are greater than zero.
Every, like a chief financial officer, CFO started to be involved in these deals. They need to evaluate, like if you bring enough value, so you start looking closer at your pricing. 'cause at the, up until then we didn't care about pricing. Oh, let's just make it that, like, can we close these deals? Oh, sure.
Like, let's increase it a little bit. So we were kind of cavalier about pricing. Now you start to be more disciplined. Like for example, when people look at solution like teleport, they intuitively assume that we are going to charge according to how many engineers use solution. Okay. But then you look at your vision and our vision says that infrastructure should be fully autonomous.
Why do you need engineers touching your production? Think about that, right? Like particularly if you are wildly successful company with like million [01:10:00] servers in productions, prink all across multiple data centers all over the world, or cloud environments, doesn't matter. You don't want engineers to touch production.
And I say that to our customers and they sometimes, but that means you guys are gonna be out of business. 'cause, and I'm like, no. The value that we deliver is in identity management. That every server, every process, every, like, everything you have in all these different corners of your infra globally, everything needs an identity.
That's what we're gonna charge you for. But that's the conversation we didn't do in the early days. So then you acquire a bunch of customers who believe that your value is directly correlated to how many engineers you have. So essentially, I'm saying that when economic, when macroeconomics become, when macro conditions become tougher, it forces you to actually realize, you know what, like those MBA.
Types that we make fun of as engineers. They actually know something about like designing pricing properly making sure that customers connect your pricing to [01:11:00] value that they're getting out of the platform, communicating your prep value correctly. So, so for us, 22 and 23, those are two years where we had to actually go and do that education.
And yes, we rebuilt our GTM model and now we're back into like the growth is now actually accelerating. And again, I don't want to say that's simply macro. It was really tempting to say at the time, like, like you get in the board meeting and you, all of the investors say, yeah, everyone is struggling.
So it's just like, oh, okay. So it means we're doing okay because everyone else is in the same boat. But I'm kind of proud that the leadership team at Teleport, we, we took that as an opportunity to examine closely. If there is something we could do better, it turns out there was a lot that we could do better.
And like in again, including things like pricing, packaging, messaging, and all of that.
Grant: Yeah, it's a great point. I mean, like we, when the market kind of fell apart for us, I, we realized like, we didn't even have like much data about how customers were using it. [01:12:00] We didn't know who was really successful. It was like it went, we had to like, we know first it was like we were like, get the data.
Then to your point around earlier on expectations, we were like. We had been telling everyone like that our product was like the easy button, and I was like, that's bullshit. Like, it's it selling, doing on-prem software and installing, it's hard as fuck. Like we need to tell people it's a hard thing to do.
We make it better, but like, you're gonna do get an F by yourself with us. You're gonna get, like, at that point I was like, tell people they're gonna get a B eventually. I want to, I wanted to get an A or an A plus, but like today it's gonna, it's just a B, right? Like, but just set realistic expectations and then we can exceed 'em later.
That was like a core thing for us early on,
Ev: But I but look, I kept actually following your trajectory because again, I st I believe that it needs to be done like eventually. In fact, I believe it's going to be a predominant model. And the one thing that I thought that you guys did that was really smart, you cannot decompose your product into things that are kinda useful.
Like essentially it's kinda same thing that we've done with [01:13:00] Teleport, but you went further. So my understanding is now replicate is kinda multiple things that you can combine in a way that fits you. and I do think that's probably the solution. Or at least direction that's the right direction. We could say like, here's like five tools you could use to build your own on-prem deployment system.
And it'll be custom to you and it'll be a journey. Actually, I used to be afraid of saying that people would say, 'cause everyone wants the easy button, and it's tempting in a sales conversation to say yeah, you're gonna get the easy button and then you're gonna keep your fingers crossed that it'll happen.
But I actually now tell people it's gonna be a journey. Transitioning to trusted computing is not instant. You have a lot of legacy and we have a huge roadmap and we've already built a bunch of integrations and we'll continue working with you moving forward. We are going to be a trusted computing partner.
This is not one time interaction, but not transaction. And surprisingly, like a lot of people find that appealing because they see that you're not bullshitting them. You [01:14:00] are acknowledging the fact. There is a probability that they have, I dunno, like an application written in old version of PHP running on Sento six in the corner of the basement of their giant bank and it's making 'em $200 million a year.
And they're afraid to touch it. And you say, and we could still secure it, but it's not going to be easy and it's not good to be instant. I it buys trust. And I do like to say that if we're like a trusted computing company, so we need to pay attention to everything. Trust building, including honest communication of expectations.
Grant: Yeah. No and I love that. And to your point, like, one of the things that kind of decomposing parts of it do is it makes it a little bit more like a Lego kit that you can, and then honestly, it's like when you're putting together Legos, you're not like, oh, the Lego people are so great. You're like, I made this right.
And so it
Ev: That's a great observation. Yeah.
Grant: It gives you a little bit more ownership of what you've made. It gives you like, it's a little bit more custom to you [01:15:00] and it and somewhat makes that person who's like that led the project a little bit of a hero, right? Which, to your point, like, which is actually another thing that we've really tried to focus on is like, how do you take that?
'cause for us, and I mean, I guess maybe to your point I hadn't thought about this, I hadn't made this connection until you said this, but like we realized that the most important person for us, once the per, once the purchase has happened, and honestly sometimes leading up to purchase is actually not the person who's buying it.
It's not the person who's, it's a person who's implementing it. When we have a really sharp person who just gets it, or a couple people that just get it and they're super, like, they're just on it. They know Kubernetes, they understand how this all goes together. They can like pull the pieces together.
Those customers thrive and they grow and they use it more and they like, they're really successful and we track this installation success rate metric and they're getting 95% install success or 98, you know, and they're just, they're winning right when they leave [01:16:00] and they don't get replaced by someone equally good that you, there's like, for us, there's like that customer trails off and like eventually, like they're like, they have a lot more support issues and they're not having a great experience and like, and it's because they don't have that deep subject matter expert there anymore.
And maybe we lost connection when didn't, you know, build the next one and build a couple of them in there. But I didn't connect that fact that it is, 'cause it's like a Lego kit that's a.
Ev: It's I was always like, in the early days, I remember you guys had, I think, quote from like one of hash corp founders on your website. Maybe you had them as a customer, but that was like hashtag's approach. I have multiple tools.
Grant: Yep.
Ev: That work really well and they do one thing really well.
And I'm kinda surprised that I haven't considered this early. Like even the fact that Gravity was always abstracting, teleport away,
Like it was a while before we built like teleports native command line tools. And [01:17:00] now I wonder away we did that maybe because it was this kinda easy button kinda appeal.
Yeah, there's a lesson here somewhere. Like when do you go for an easy button? 'cause maybe sometimes it is actually the right way to do it. And when do you expose complexity to a customer and just become open and honest with them that we're gonna help you to deal with complexity. But complexity is there.
Grant: Yeah. And maybe now we're gonna get into the AI thing a little bit. Like maybe now with ai it's like, you know, that's gonna be an assistant in helping them kind of manage complexity and pull these things together a little bit easier and, you know, and, yeah, I don't know.
Ev: So I have this it's kinda interesting that I was starting to think about AI like about like two seconds before you said it out loud. And also I feel this urgent need to apologize to the listeners. 'cause I believe all of us are suffering from ai fatigue at this point. Everyone is talking about AI everywhere, but when we talk [01:18:00] about get at the at the end of the day, like things like gravity are replicated.
Like there are tools, like, I really like your analogy with Lego like blocks that engineers could use to like assemble their own solutions. And when AI comes into play, what I, maybe it's me kind of crying and not exactly for help, but I do want like new generation of entrepreneurs to think about.
Like a few considerations. So there are a lot of AI companies today that are launching and actually pretty successful. They try to make AI solutions that reuse the tools we already have. What I mean by that is look at, for example, all these like machine coding companies that help you generate code. But what is the code itself is a tool.
Like programming language is a tool. So it was invented to help convert from English to assembly language of a platform you're running on. Okay. But even assembly language is also a tool that helps you convert from like really [01:19:00] kinda limited like a really small kind of formal system of symbols into a machine code.
So that's another level of translation. And why, because humans are terrible. At thinking in machine code. Even though I learned X 86 assembly language when I was in high school and I was really proud of it at the time, I never bothered with machine code. It was just like crazy. Now ask ourselves like, why do we need all these intermediate steps today in the era of ai?
Why can't you then have a machine, like, can we have a new generation of programming language that is designed specifically for AI to be the one that's doing the programming? And how would it look like, would it be different? And I was experimenting with generating, essentially using AI to generate binaries directly.
So that is the, they cannot do that. But you could, you can generate an assembly language and then you can even do like a fun experiments. So you could come up with like a fun project and ask AI to [01:20:00] write you now like c plus or C or Python code, whatever. In my case, I was playing with C and I was generating like a little application and then I would like compile it and then see how it runs.
But then I will work my ass off, try trying to get the exact same thing done in assembly language. Basically trying to talking to an LLM and I tried like all of 'em. And then eventually, yeah, you can have LLM generate an assembly that is actually way more efficient than assembly generated from c by a compiler. Right. So then you're asking yourself what's the value then of having compilers and like languages, like Python and c plus. And the people will say like, well, because the code that AI generates like it needs like human review because it's probably gonna be not optimal like ai, like hallucinates and all of that.
And I'm thinking, is that gonna be like that forever?
Grant: right?
Ev: If we all agree that like the rate of improvement of models is actually impressive, that they're gonna get better and better. So why are we clinging to use this kinda human [01:21:00] readable, old school programming languages? And then if you think about this for a while, it's kind of fun topic to have over beers at the bar with your programming friends, but it actually applies to everything.
Like look at the browser, like we, both of us are steering at, like we have Slack and we have all these different buttons, all the different, everything is designed for humans. That was the user it was built for. So then the next question is, what would be equivalent of all of these things built for ai? And that's kinda a little, almost like a hobby of mine that I keep looking for.
Like AI startups, AI announcements, or even just ideas or even like comments on hacker news. They describe the tools that we need to build for ai. So that's that's kind of where my obsession with AI currently lives. 'cause like a lot of things they stop making little, like, for example, and look, if I'm talking too much about it and we wanna move on, let me know. Okay. So think about the concept of a software library. So we, we have all these languages [01:22:00] with libraries included. Like you have Python that has huge standard library, Golan has libraries for encryption and you know, making HT P requests and all of that. But the libraries exist so that we don't have to reimplement these things from scratch.
'cause it takes time and humans are expensive. But if AI can do it, why do you need libraries?
Grant: Yeah. I thought, yeah, if I had
Ev: you could have a AI generate the whole freaking thing from scratch with no dependencies whatsoever.
Grant: yeah.
Ev: And again, I tried that and it worked really well. And. So essentially your entire kind of program then becomes basically a series of prompts because like in, in my case, the little project I did just for fun that Ike so I used, I think it was Gemini, maybe to make a library that parses exif metadata of digital images.
You know, you could see like aperture and the camera model and the lens and like whatnot. And it generated me this thing using like, in assembly and it was highly optimized. I was like giving it hints, like, like, [01:23:00] can you use these instructions of those instructions? And and then once you have it, like you don't need, like, there is no need to have exit library anymore because it can regenerate it again and again.
Again, it's not usable in production today, but because technology is new, like that's one thing you learn about tech, that it gets massively better very quickly. So then it looks like we no longer need the, these libraries like in the future. So, so that's what I'm excited about. AI native tools that are made to be used by ai.
Grant: I the biggest, the, so it's funny, I, you know, I like that you're gonna try to solve it. 'cause I feel like I just, I can't reason about how they actually work yet. Like what's, like, what's happening underneath the hood. Like some non-deterministic, you know, way of like, I'm like, I don't know. I like, I struggle with like how they actually come up with these things.
Right.
Ev: Yeah. But do you, like, do you struggle with not understanding what's happening inside of [01:24:00] your compiler? When you like using programming languages and people say, oh, it's
Grant: what happens inside head even, 
Ev: yeah, it generates the same code all the time. Like, no, it's not true actually. Like Golan, like, like the last language that I've been coding a lot in is Golan.
And look, compilers went through dramatic transformation from like version one to where it is today. It's gotten like, it learned to do new types of optimizations and look, we're comfortable 'cause we trust it. So eventually once the models they get, get into that same state where we don't care about black box anymore, it's gonna be same thing.
And then you will ask yourself, why do you even need to stare at this kinda c plus or goal line code generated by the thing? Just gimme a binary. But
Grant: I agree with that. I agree with the future. I'm just saying, like, I, I struggle with actually trying to figure out like how, what the AI native tool tooling will be, because I, like, I just, I think I'm like, yeah I mean, I understand what they talk about in terms of like how we train these things and how this stuff, what's it retrieving, and maybe it's like a compression thing, but [01:25:00] I feel like I don't understand it well enough to like.
Build a tool for it, right? It's like, I don't know my user well enough, right? Like, it's like I can't get, it's like I want to like get in the mind of my user. I wanna observe my user. I wanna like, you know, I wanna have the, it's like, and I just don't I struggle with being like, oh yeah, I can like, you know, deliver something that this thing actually is gonna be great at using.
So,
Ev: I think what you're struggling with is what so let's call it like the difficult middle. It's really easy to dream about this beautiful world in the future we're gonna be in. And then it's really easy to recognize the limitations of the present, but it's the stuff in the middle that's so freaking hard to figure out, particularly the sequence of it.
Oh, first this needs to happen and that this needs to happen. Yeah, that, that's just really tough. I struggle with this too.
Grant: Yeah. That's a great point. You're like the broad vision and then that, like, how do we get from here to there? Like how do we, you know, how do we go
Ev: Yeah. So the one AI topic that I do believe that I should say a few things about because, so that's our area [01:26:00] of expertise, is that when companies now starting to deploy AI into their data centers, and I'm hesitating to use the word AI agent because there are two different kind of meanings people have.
Some people believe that AI agent is something that runs kind of like your co-pilot on your desktop that's kind of helping you to kinda interact with different applications and websites and whatnot. So that's an AI agent and some other people that think that AI agent is essentially like LLM running, like as a microservice and the Kubernetes and is processing requests and producing inputs and outputs.
So I'm speaking about the, kind of server side ai. So right now, there are plenty of companies that are deploying those things or trying to deploy 'em in production. And the interesting thing about AI is that it's vulnerable to both types of attacks at the same time. Remember we talked about neur at the beginning of conversation, that there are malware attacks, that your microservice implementation might have a vulnerability, and also [01:27:00] their behavioral attacks, identity attacks and AI is vulnerable to both.
So it, like, there could be like a zero basically a zero day exploit that I could just exploit as an attacker or it could convince your agent to do something it's not supposed to. There was a funny story actually a few weeks ago. I wish I remember more details about it because I read about it, kinda laughed and moved on.
Now I realize I should have maybe like saved that announcement. So there was some kind of company that I. Exposed like LLM publicly and say, and they said like, you can interact with your checking account with your bank via this model. And we made it so secure, like you will never be able to get any money out of it.
And if you do, you can keep the money. I believe they put like $50,000 into checking account in 30 minutes. I think it was wired out. So the attacker convinced it, it reframed the meaning of, it kinda swapped the direction of, like the LLM was thinking that it was wiring [01:28:00] money in, but in reality it wired it out.
Ah, like I wish I remember the deals. Like it was really cool. So, so the question is, how do you secure these things? So you have an LLM running and ideally you want to enable it to have real time runtime access to all the data sources you have. 'cause you want the LLM to be useful to you. So the more data you give it, the more utility you extract out of that.
Investment. But at the same time, you don't want that model to have, like when it took, like when that model interacts with different people, it needs to be guardrail, right? So for example, if I talk to an LLM and I ask, Hey, how much my like, peer makes over there, and if it's had access to like HR database, like that obviously is not an information you want to disclose, but if the head of HR is asking the question, like, print me a table of like top compensated salespeople, we have for example, like it should respond to that.[01:29:00] 
So there is a kind of debate now happening in cybersecurity circles. How do you actually solve this problem? And I do want to share our view because I feel strongly about it. And again, I don't want to sound like a teleport ad, but. Our view is that LLMs, they need to be treated exact same way as humans and machines and laptops and everything else because there is a great temptation that currently exists, particularly in kinda startup ecosystem or LLM is a new thing.
We need to come up with like LLM identity and we need to have LLM authorization and LLM authentication, LLM audit and kinda AI versions of things that we've built for humans before. And I think it's tempting from kinda investment perspective. Like if I'm a vc, like yeah, I should like, invest into this e ai companies that trying to secure ai.
But AI we believe needs to be incorporated into this kind of operating system concept that it's just same identity as humans, machines, laptops, applications, microservices, because you want, [01:30:00] because otherwise you're gonna end up with another silo and then it'll be impossible to tell. It be like impersonation again becomes possible.
Identity spoofing becomes possible. So, so that's our strong view. So we we actually announcing now secure support for MCP. So MCP is the protocol that that AI is using or more and more it's a standard protocol that we want, not we, as teleport, but I think like Google and Tropic and OpenAI, they're all investing in MCP adoption that it needs to be used by AI agents to interact with data sources or with each other.
And so we, we just launched the secure implementation of it. I think we're probably the only vendor right now who takes it seriously. But the whole point there is that like, AI identity is the same identity as everything else you have because if we don't do it properly I'm very much concerned that.
That's just not going to be good outcome.
Grant: the one thing that I would [01:31:00] say that is maybe a nuance here is WI, I feel like AI need to be far more dynamic in terms of what I actually have permission for, right? So like.
Ev: Yes.
Grant: and that system needs to be external. Like the, to your point, like the AI should not be able to like, be like, oh, I need to change my permission.
Right. Like, there should be some deterministic system that,
Ev: Yeah. Like there are basically two things there. So first of all, like your AI should not be assuming your permissions because that's just not fair, right? 'Cause you don't want to see your name in audits where like an a agent that you launched that did something on your behalf, but.
 The really important realization, even before we talk about [01:32:00] AI, is that in access control theory, there are kinda two predominant models that exist. There is role-based access control and attribute based access control. So the difference is that like, well, we all know how our back works. Like pretty much every engineer had to deal with like, am I in the, like a, do I have administrator role or do I have like a regular user role and whatnot?
But attribute based access control is simpler. So when there is some kinda interaction between two subjects and access control theory is basically about interaction of subjects. That's basically identities. Humans, machines, applications, and objects of data. So all when subjects are trying to access objects, you just check certain attributes in real time and the moment when it was happening.
So let's just say for example, you wanna do deployment in the organization. And what kinda attributes could be checked to determine whether you have permissions to do that or not. Like I would argue that a really good signal is if there's a ticket created like in Jira or, you know, like whatever you use to [01:33:00] create like a deployment ticket.
It's like, like, so, so there's a digital artifact that says you need to go and do this unit of work complete deployment. So then you give permission to like EV for example, because I'm assigned to that ticket. So that's an attribute. And also you issue permissions, for example, to Jenkins 'cause they're gonna do deployment using Jenkins.
So, and you make sure that I'm not on vacation and you can make sure that I'm using companies laptop. You could check like arbitrary number of attributes. And if they're all set in a certain way, then the access is granted. But then when you complete that unit of work, the ticket is closed, all of that evaporates.
You go back to kind of empty state. It's really important because. This approach is much more scalable than roles. 'cause roles are static. They don't, they never change. And the interesting thing is that every company, every customer we have that I talk to, they all have more roles than they have employees.
Think about that. Like our back is completely broken. you're like a car dealership like it'll work for you. But if you're anything bigger than [01:34:00] that, you need to move away gradually from role-based access control everywhere. So now we come to ai, and you correctly pointed out, if you try to plug an AI agent into this kinda static role-based access control world, you are going to have a very hard time because AI is a really dynamic thing.
So in certain contexts it needs to behave like CEO of the company. Like for example, it's trying to generate like a panel statement, right? And in some other context, it needs to be an intern. This is maybe when you want to check what's the holiday schedule like we have. So you need then to guardrail that model based on probably who it is talking to or what kind of like the nature of a request.
Grant: Yeah. Yeah.
Ev: You can't even answer that question. So this is why adopting attribute based access control for AI is going to be absolutely critical
Grant: That's really interesting. I hadn't, I, one, I don't think I've ever even heard of [01:35:00] au attribute, you know, based authentication or auth authorization. Yeah. That's very interesting. 'Cause to your point, like it, it is, you need, we need something more dynamic. And so that's, if that's what it is, that's a really interesting approach to it.
Does tele, is teleport, is that part of the platform or is that
Ev: It's, we, so we have to support both. So you have to support our back simply because you are integrating with things that are like our back is how they already.
Grant: That's what every everybody does. Yeah. That's the world.
Ev: and then we do have a back capability via access requests that we like evangelizing. So in a, in this kinda happy end state you need to have a back just in time, a back maybe it's worth explaining in a, maybe in a better detail, that like today, even pretty much at any company, if you look at what's happening in their infrastructure, you will make a very obvious observation that 99.999% of the time, there's no need to access anything.
Servers are working, processing [01:36:00] transactions, making you money. You know, things are fine. It's really the, like, when there's something to change, that's where humans need to be involved. So therefore you need to take a look at a timeline and you could say, this is my steady state where there's no change happening and this is when change is happening.
And then you need to take the steady state out of your mind completely. You need to say in a steady state, my infrastructure is not accessible. How do you enforce that? You say, I have no users. Like all of my servers are clean. They have no users on them. They have no rules, no groups. Same thing for Kubernetes.
Same thing for MongoDB. Like everything is like squeaky clean. Like they're not even, like, there are no accounts anywhere. Like even theoretically no one can access it. Wouldn't that be wonderful if you could say that? I don't have to think about it. Basically it means you can go to sleep every night without being like, without afraid of someone breaking something and you only create, so then you need to create user A, a accounts on these things and you need to issue them [01:37:00] privileges according to what change needs to happen.
And now it becomes much simpler 'cause you're not deploying things 24 7. You're only doing it maybe like twice, maybe three times a day. So then you create privileges and you and you assign identities to a unit of work. And then when unit of work is completed, like deployment happened, like backup job, like was started whatnot.
So when it's done, the ticket is closed and you go back to steady state. That's much, much simpler and therefore much more scalable. Access control kind of method that using static role-based access that exists all the time. And this one is much friendlier to AI
Grant: Yeah, for
Ev: because you can create like essentially every conversation that agent has with the, with someone or like from the outside world, you can then guardrail around that particular context for that conversation, which is really hard using roles hard to do using roles.
Grant: no, that makes a lot of sense. That's a very. Interesting approach and perspective on it [01:38:00] and honestly seems very relevant because again, I've, I'm like, rback long-lived rback for an agent. It's like, no, it can't have all access to everything that it needs to have access to. Sometimes it needs all that access, and then other times it needs to minimal access.
So that's cool. I'm, that's I'm glad that there's people out there solving that problem because I think it's going to be a very large opportunity for you. So that's cool.
Ev: Again, we need to give credit to people who invented all of this stuff, and it goes back to like sixties and seventies and eighties again, in the con like it's not exactly new. We actually published a book last year about, it's called Identity Native Infrastructure Access Management. I know it sounds really boring, but there is a, like a kinda short history lesson there too, like where all these concepts came from.
So, when we bring people into teleports during onboarding, we, so we cover like multiple operating system, like one of the original operating systems, and we use that as a. Kind of vehicle to describe kind of fundamental [01:39:00] concepts of access control. So the point is, like in academia, we solved these problems many years ago.
We just need to modernize it and scale it up and make it accessible to to AI and to all, and to other forms of modern workloads that we deploying in production.
Grant: I also love that as like a source for kind of like inspiration to modern problems is like look to the kind of, the original, you know, like answers from academia or computer science or, you know, like how do we, it's like, to your point, there's, we've the operating system has probably solved this 30 years ago.
You know, how do we apply that more broadly? So I think it's a really good paradigm to look at these problems from. So.
Ev: Yeah, like I like think of like, what would operating system now even mean if you have, so back in the day, it was designed for applications and for humans. So there were kind of two subject types, like, shall we treat AI as yet another? And if that's true, what changes to the operating system do we need to introduce?
Which is kind of related too to this like earlier [01:40:00] conversation we had about changing our tools to account for AI being yet another user. So 'cause operating system at the end of the day is also just a tool.
Grant: Yeah, that's a good point. I know you got a hard stop, so I wanted to give you a moment to wrap up, but ev this was super fun. I, you know, this is the, so the listeners can know the first real, like, deep conversation we've had, right. So,
Ev: Yeah, I really enjoyed it.
Grant: Yeah. It was really fun. I'm looking forward to a dinner or something in not too Destin future.
Ev: Let me know when you're Bay Area, we're looking forward to it.
Grant: Awesome. Thank you. E.
Ev: All thank you. Bye.
​