Vollständiges Transkript von Why Super Intelligent Models Write Super Dangerous Code | Varun Badhwar, Endor Labs

people comfortable with data security and privacy and regulation? 00:04:26.480 --> 00:04:30.079 Is what we built the first company around, a company called CypherCloud. 00:04:30.240 --> 00:04:31.839 Uh, and that's what we did. 00:04:32.079 --> 00:04:40.639 And I did that for about five years, had a great run, learned a lot of things about how to build and scale, but also learned a lot about the mistakes we make. 00:04:40.720 --> 00:04:45.600 And thankfully, I was not in the CEO seat where the pressure and stakes are so much higher. 00:04:45.759 --> 00:04:49.040 But I got to be kind of the right hand to the CEO and really learn. 00:04:49.120 --> 00:05:06.959 And then in 2015, I uh felt confident and comfortable and found the opportunity to build something in the cloud infrastructure security space because now the talk of everybody's kind of conversations at dinner and coffees was why are we building data centers anymore? 00:05:07.040 --> 00:05:09.759 There's AWS, there's Azure, GCP. 00:05:10.000 --> 00:05:28.800 And so Redlock is the company I founded in 2015 that was focused on securing all of your applications as you entirely shift from a perimeter you control in your four walls of a data center to compute your rent from third-party hyperscalers. 00:05:28.959 --> 00:05:56.319 And so the commonality in CypherCloud and uh later Redlock, and as we talk about Endor, I'm sure we'll get to that, but was always these big technology shifts and its implication to cyber and cybersecurity and safety, um, and really creating new markets for problems most people couldn't even comprehend, and how we had to educate the market, create budgets, and eventually create category-defining companies. 00:05:56.720 --> 00:06:04.800 So, how was the journey, you know, when you became ultimately the CEO at Red Lock, raising money, getting the first few customers? 00:06:05.199 --> 00:06:09.040 Because before that, you were mostly on the product and engineering side. 00:06:09.920 --> 00:06:14.160 Look, I've I've always been obsessed with customers, customer needs, customer use cases. 00:06:14.240 --> 00:06:25.360 And I've generally been um I've had enough uh to be dangerous knowledge on product and technical side as well as on the business and sales side. 00:06:25.519 --> 00:06:29.519 And so I think for me it was a natural thing to become CEO. 00:06:29.680 --> 00:06:32.240 But I'll tell you like nothing gets nothing prepares you for it. 00:06:32.639 --> 00:06:33.600 It's a lonely job. 00:06:33.839 --> 00:06:36.879 First thing I tell people is the buck stops with you, right? 00:06:36.959 --> 00:06:42.560 The consequences of decisions you make for days, weeks, months, and years are based on what you chose. 00:06:42.959 --> 00:06:47.519 As a founder, there's no book you you know you have read and you follow the track on. 00:06:47.680 --> 00:06:55.120 The reason we're creating something is because you're trying to do something that hasn't been done before, or you're solving a problem that hasn't been solved before. 00:06:55.279 --> 00:06:58.879 So it's not like I can follow somebody's playbook and do it. 00:06:59.120 --> 00:07:02.639 And I think it's a lot of part art, part science. 00:07:03.040 --> 00:07:05.120 So intuition matters a lot. 00:07:05.439 --> 00:07:06.879 Instincts matter a lot. 00:07:07.040 --> 00:07:21.279 To this date, I usually say that, you know, when I'm interviewing candidates as an example, usually I feel like in the first five minutes, I have a high degree of confidence if this person is gonna be the right fit for us or not. 00:07:21.519 --> 00:07:26.800 This next 55 minutes or longer that I spend in the conversation is really getting to the details. 00:07:27.040 --> 00:07:29.600 So instinct development matters a lot. 00:07:29.680 --> 00:07:32.959 And I feel like I had developed that over my first two startups. 00:07:33.120 --> 00:07:38.639 Uh, I'd also learned about just how important it is not to take shortcuts. 00:07:38.720 --> 00:07:43.040 I think usually people will think about, well, I just got to get this out. 00:07:43.120 --> 00:07:44.160 Let me just create something. 00:07:44.319 --> 00:07:53.759 But if you think about Redlock, you know, in three years, we went from uh first idea to an exit, a very large successful exit. 00:07:54.079 --> 00:08:01.279 But three years and one day later, we were thinking about how to service 65,000 Palo Alto networks customers post-acquisition. 00:08:01.439 --> 00:08:05.839 And we took that business from five, 10 million ARR to 100 million error. 00:08:06.079 --> 00:08:09.040 And I'm talking about doing this in 2018, 2019. 00:08:09.600 --> 00:08:15.439 We couldn't have done it if we had all these shortcuts on our platform and everything was held by Band-Aid and Duct tape. 00:08:15.600 --> 00:08:20.639 So, yeah, I think some foundational aspects of build for scale from day one. 00:08:20.959 --> 00:08:24.399 Yes, you got to be scrappy, but you've got to really look around the corners. 00:08:24.639 --> 00:08:31.199 Intuition and gut matters as much as science and what you've learned in school matters, were probably the big things I've taken away. 00:08:31.279 --> 00:08:34.720 And the importance of investing in the right team upfront. 00:08:34.960 --> 00:08:39.840 I think we made the mistake early on in the first couple of companies where it was like, well, we don't have a lot of funding. 00:08:40.240 --> 00:08:42.399 Let's figure out how do we cut corners. 00:08:42.639 --> 00:08:46.480 And I just realized eventually, even like your equity, right? 00:08:46.559 --> 00:08:49.120 As a founder, you don't want to give up too much equity. 00:08:49.279 --> 00:08:57.919 Um, but you can only build a successful company if you share the wealth and you find the best talent and kind of unconstrain yourself to do that. 00:08:58.240 --> 00:09:02.080 So, so let's compare your journey now in Redlock, right? 00:09:02.240 --> 00:09:06.799 How much did you raise in the first few

rounds and how big did your team get before you got acquired? 00:09:07.440 --> 00:09:15.519 So with Redlock, we had raised a 2.5 million seed and about an$8 million Series A. 00:09:15.600 --> 00:09:17.279 So we were very capital efficient as a company. 00:09:17.360 --> 00:09:19.840 We'd raised under$12 million in funding. 00:09:20.080 --> 00:09:26.559 The company was about 85 people, split half and half between India, uh, Bangalore, and US. 00:09:27.360 --> 00:09:35.840 And um, you know, we were closing in on the first 10 million of ARR, a short amount of time actually, from inception to that point. 00:09:36.080 --> 00:09:45.440 And the exit was uh, you know, close to$250 million exit for the company, which was an incredible return for all our investors. 00:09:45.679 --> 00:09:55.600 It was life-changing for every employee because, again, I believe in investing in people, you know, a lot of times people say, well, in India, when you're hiring employees, they care more about cash, less about equity. 00:09:55.679 --> 00:10:02.879 And I would always educate people like, look, salaries pay the bills, but life-changing moments come from equity. 00:10:03.120 --> 00:10:11.360 And I think it's really interesting, even when I look back now, many years from now, I'll get a text message from somebody saying, Look, I bought the second vacation house. 00:10:11.440 --> 00:10:17.919 This is all thanks to you know the redlock run I had, or you know, I've got this nice new car, couldn't have it done without redlock. 00:10:18.000 --> 00:10:25.679 So I think it's very fulfilling knowing that it was not just a wealth creation event for investors and founders, but for every individual that worked in this company. 00:10:26.799 --> 00:10:34.799 And uh you ultimately created Prisma Cloud, which became uh one of the core infrastructures of Palo Alto. 00:10:35.120 --> 00:10:35.440 Yeah. 00:10:36.240 --> 00:10:36.480 Right. 00:10:36.639 --> 00:10:40.080 So how was that so strategic to Palo Alto? 00:10:40.320 --> 00:10:43.039 Did you realize that at that point in time? 00:10:43.679 --> 00:10:48.080 I I don't know if anybody could have realized how strategic it could have been. 00:10:48.240 --> 00:10:51.600 It was certainly strategic, and I'll tell you a small story around this. 00:10:51.840 --> 00:10:57.919 Um Nikesh had just come in, Nikesh Aurora had just come in as the CEO of Palo Alto Networks. 00:10:58.159 --> 00:11:01.360 Um it was the first acquisition he was making. 00:11:01.519 --> 00:11:10.480 Remember at the time, people were wondering why this non-cybersecurity person is a Googler coming in and taking over the realm of a cybersecurity company. 00:11:10.720 --> 00:11:14.720 Palo Alto was known for firewalls and network security. 00:11:14.960 --> 00:11:28.639 And the craziest part that most people don't remember is a couple of months before Nikesh joined, Palo Alto Networks had made one of its biggest ever acquisitions of a direct competitor of Redlock, a company

called Evident.io. 00:11:29.519 --> 00:11:39.200 And the interesting thing is after that acquisition, you know, Endor, I'm sorry, Redlock was really deep into um winning even more accounts. 00:11:39.279 --> 00:11:52.960 Like we got even more momentum after the acquisition while Evident was busy getting acquired, and you know, they were limited to AWS, Endor, uh, sorry, I keep saying Endoor, Redlock was much more gravitated around multi-cloud. 00:11:53.200 --> 00:11:55.519 And you know, the architecture was fundamentally different. 00:11:55.600 --> 00:12:00.159 And so we were scaling and we were beating Evident and Palo Alto Networks on a lot of deals. 00:12:00.320 --> 00:12:08.960 And so when Nikesh came around and the team said, Hey, you should come meet Nikesh, I just said, like, you're my biggest competitor, you know, I'm not going to waste my time. 00:12:09.360 --> 00:12:13.120 And long story short, Nikesh and I met had a meeting in the minds. 00:12:13.279 --> 00:12:16.879 He said, Look, I'm making a bet in this, you have to make a bet in me. 00:12:17.200 --> 00:12:21.039 He created very big goals that I thought were fundamentally unachievable. 00:12:21.200 --> 00:12:30.080 But kudos to him because the only way it was possible to scale this thing up is to not tuck Redlock as part of the network security business. 00:12:30.240 --> 00:12:34.000 But he allowed us to create an entirely new business unit that had never been done before. 00:12:34.159 --> 00:12:35.679 We used to call it a speed boat. 00:12:35.759 --> 00:12:42.559 So if you think about the big network security business as a mega yacht sailing in the middle of the ocean, cloud security was a new business. 00:12:42.639 --> 00:12:49.039 You needed a speedboat to be scrappy, move fast, and catch up to the core business. 00:12:49.200 --> 00:13:11.840 And so Nikesh was incredible at funding me and my team and giving me the opportunity to not just scale that team of 80 people up to eventually close to a thousand people in three years, but in that midst, we acquired nine other companies to fold them into the Red Lock architecture and really create this monster platform, which was for cloud security. 00:13:12.000 --> 00:13:30.879 And to a great degree, I'll take a little bit of credit for Wiz's success because we showed such a great acceleration of revenue and path that Wiz eventually and the founders there were building something else, pivoted to cloud security, got funding on the backs of Palo Alto Network's Prisma Cloud Success. 00:13:30.960 --> 00:13:32.159 And obviously, kudos to them. 00:13:32.240 --> 00:13:36.639 They've built uh you know a 32 billion outcome for themselves and the teams there. 00:13:36.879 --> 00:13:38.240 Did you angel invest in Wiz? 00:13:38.480 --> 00:13:38.879 No, I couldn't. 00:13:39.039 --> 00:13:40.639 I mean, it was a direct competitor to us. 00:13:40.879 --> 00:13:41.200 Got it. 00:13:41.440 --> 00:13:48.240 But but they started, I think, just at the time that you were leaving Polo to start Endor? 00:13:48.639 --> 00:13:50.159 They started about 18 months before that. 00:13:50.240 --> 00:13:55.519 They started right when COVID started, like at the beginning of 2020 is when they pivoted to cloud security. 00:13:55.600 --> 00:13:57.759 They started a little bit before in 2019. 00:13:58.000 --> 00:14:02.159 Uh, but yeah, 2020, and then I was still at Power Also Networks for another 18 months. 00:14:02.399 --> 00:14:09.919 Yeah, probably, you know, if you hadn't known it's inside of 2020, that it was so strategic, you could have asked for a billion dollars. 00:14:10.799 --> 00:14:11.919 People tell me that all the time. 00:14:12.000 --> 00:14:13.679 They're like, hey, you sold Redlock too cheap. 00:14:13.759 --> 00:14:16.960 And I like my my theory is I never look back and have regrets. 00:14:17.039 --> 00:14:19.679 I think it was an amazing outcome even till this point. 00:14:19.919 --> 00:14:27.679 Uh for those of uh the people that held on to the Palo Alto network stock, that stock is you know 15 times higher than what it was. 00:14:27.759 --> 00:14:32.000 So, you know, if you take that bet that that was a multi-billion dollar acquisition now. 00:14:32.240 --> 00:14:34.799 But but no, look, life is a matter of learnings. 00:14:35.039 --> 00:14:43.519 I think startups, the the people almost think about the initiation and the incubation of a startup as the hardest part. 00:14:43.759 --> 00:14:46.960 And I think in the moment it feels that way because it is really hard. 00:14:47.120 --> 00:14:49.360 But I think startup building gets harder. 00:14:49.759 --> 00:14:53.120 And um across the board, right? 00:14:53.200 --> 00:14:55.519 When you're raising, you're raising on a dream, you're raising on an idea. 00:14:55.600 --> 00:14:59.039 If you're a repeat founder like myself, we don't have to prove anything. 00:14:59.279 --> 00:15:00.240 Money comes easy. 00:15:00.320 --> 00:15:06.879 Fortunately, if you're a young founder, you still have to prove conviction in the business, but you're not showing for revenue and scale. 00:15:07.039 --> 00:15:11.120 You're selling the TAM and you're selling the product architecture insights. 00:15:11.360 --> 00:15:15.360 And you can raise the, you know, whatever valuation these days we see crazy valuations. 00:15:15.440 --> 00:15:20.799 There's a bunch of cybersecurity companies starting out with$100 million seed funding now with near zero revenue. 00:15:20.960 --> 00:15:21.600 And that's fine. 00:15:21.679 --> 00:15:24.080 But what do you do when you have to scale revenue? 00:15:24.240 --> 00:15:32.720 Now you could be the smartest founder with product instincts, but if you don't understand how to build go-to-market for scale, that's another hard problem to crack. 00:15:33.039 --> 00:15:36.000 And engineering can be scientific. 00:15:36.559 --> 00:15:40.799 Sales marketing is art and science, so it kind of starts getting more and more complicated. 00:15:41.039 -->

00:15:50.080 And then initially you have one building block of engineering, then you had engineering and marketing and sales, and all of these building blocks have to connect. 00:15:50.159 --> 00:15:56.320 And then people start asking you about go to market and efficiency and eventually CAC and LTV. 00:15:56.399 --> 00:16:02.080 And so growing and scaling a healthy, sustainable business, I think over time gets harder. 00:16:03.039 --> 00:16:05.919 So, what was the trigger point for you to start Endor? 00:16:06.320 --> 00:16:11.519 Because you started during COVID time, a very uncertain time to begin a company. 00:16:11.679 --> 00:16:17.840 You can you could have continued building Prisma to multi-multi-billion dollars in business. 00:16:18.159 --> 00:16:21.759 That was my wife's uh argument against me starting a company, yes. 00:16:22.000 --> 00:16:25.840 Uh look, you know, they say founders have this bug. 00:16:26.240 --> 00:16:29.759 I mean, why is Travis Kalinick starting another company after Uber, right? 00:16:29.919 --> 00:16:42.799 Why I I feel like us founders have this crazy gene in us, and that gene doesn't let us sit comfortably or see and be a part of status quo. 00:16:43.279 --> 00:16:48.159 I feel like the natural instinct is if you see a problem, you want to go fix the problem. 00:16:48.559 --> 00:16:55.120 And in 2021, while us were building this incredible business, um I saw a problem. 00:16:55.279 --> 00:17:01.440 And that problem was software development was radically shifting from development to assembly. 00:17:01.840 --> 00:17:07.440 18% of our code wasn't even being written by developers, it was open source, it was all of these other things. 00:17:08.000 --> 00:17:12.240 We had no idea who's written this code and published it on GitHub. 00:17:12.480 --> 00:17:20.160 Yet we were blindly trusting all of this code and just in the spirit of moving fast, bringing it in and using it. 00:17:20.640 --> 00:17:22.240 That's one side of the change. 00:17:22.559 --> 00:17:32.319 The other side is you are analyzing this with incumbent tools and security scanning tools for code, and they would find a bunch of stuff. 00:17:32.559 --> 00:17:37.119 And you would check a box and compliance reports that says, yes, I scanned my code for vulnerabilities. 00:17:37.279 --> 00:17:45.119 But the reality was the volume of problems that were being discovered and the fidelity of that volume was really low. 00:17:45.440 --> 00:17:47.759 So engineers just didn't trust the results. 00:17:47.920 --> 00:17:53.119 So you're building apps, you're using all this code, you're relying on third-party open source. 00:17:53.759 --> 00:18:01.119 And at the same time, you have all of these potential security issues, you couldn't figure out what's real, what's not, and how you're going to fix them. 00:18:01.359 --> 00:18:03.440 And I think ignorance was bliss. 00:18:03.759 --> 00:18:09.839 But like for me, as a problem solver, I was like, look, this is a bubble waiting to crash. 00:18:10.000 --> 00:18:11.839 Like it this cannot sustain. 00:18:12.480 --> 00:18:16.240 And you look forward, two years later, LLMs were starting to write code. 00:18:16.319 --> 00:18:20.880 And if you look at 2026 today, what is the biggest topic of conversation? 00:18:21.039 --> 00:18:28.079 The fact that every security vulnerability can easily be discovered faster than ever before by LLMs. 00:18:28.160 --> 00:18:30.240 Like they're really good at finding bugs. 00:18:30.400 --> 00:18:40.799 And so now the problems become well, if LLMs can find so many problems, why can't we secure that code and build it correctly from the first onset? 00:18:41.039 --> 00:18:44.240 And the reality is historically, it's been a friction point. 00:18:44.319 --> 00:18:47.839 Do you either ship code fast or do you ship it securely? 00:18:47.920 --> 00:18:49.200 It's never been an end. 00:18:49.599 --> 00:18:57.519 And our mission at Endor that I took on is we can help you ship fast and ship securely. 00:18:57.680 --> 00:19:05.279 If you build the right architecture, the right technology, the right insertion point in the software development lifecycle, you can solve all of those problems. 00:19:05.519 --> 00:19:07.359 We started that in 2021. 00:19:07.519 --> 00:19:19.279 And I couldn't be happier because sitting here today, we've had the time to build and scale a platform, prove it out with the world's most amazing customers in technology, finance, insurance, et cetera. 00:19:19.839 --> 00:19:27.279 And now this is the number one problem that is constraining us from adopting a gentic STLC is code generation is not the problem. 00:19:27.440 --> 00:19:33.119 It's security, it's quality, it's everything to do with releasing of the software much faster, and we're primed to solve it. 00:19:33.440 --> 00:19:36.400 And you operate on the left side completely? 00:19:36.799 --> 00:20:03.440 The way I describe to be bill where Endor fits in is um if you want to draw a box around the entirety of the agentic SDLC from cloud code cursor, pick your favorite ID, agentic ID, through your pull requests, through your um CI CD pipeline till you have an artifact that is ready to be deployed in the cloud, container or jars, whatever, that is our zip code. 00:20:03.680 --> 00:20:25.519 From the first intent of writing code to writing the code to checking it into your pull requests and GitHub to CI CD pipelines, securing all of that such that what is ready is the most secure piece of software you could possibly create without compromising on speed is the outcome that Android uh drives for our customers. 00:20:25.759 --> 00:20:32.240 And kind of that, unfortunately, in security, that workflow continues post-deployment because now I deployed the product yesterday. 00:20:32.480 --> 00:20:38.400 Now, today, 10 new things were found in security, like vulnerability discoveries. 00:20:38.640 --> 00:20:44.160 Now you've got to figure out off that code base, off those 10

vulnerabilities, what actually affects me? 00:20:44.319 --> 00:20:46.960 And how do I quickly pinpoint what affects me? 00:20:47.200 --> 00:20:51.920 How do I fix it without breaking my application and redeploy really, really quickly? 00:20:52.079 --> 00:21:09.279 And that time window to remediate used to be six to 12 months because, yeah, sure, somebody found a vulnerability yesterday, but the the likelihood that somebody's going to build an exploit and target you and come at you was like very low, 1%, 2%. 00:21:09.920 --> 00:21:12.400 Today that's that's reality. 00:21:12.559 --> 00:21:18.000 Within 10 hours, people have found and created working exploits for new vulnerabilities. 00:21:18.079 --> 00:21:24.960 And so this loop of remediate triage and remediation of what affects my code, what do I need to fix? 00:21:25.519 --> 00:21:28.960 Could literally become a full-time job for every engineering team on the planet. 00:21:29.279 --> 00:21:30.319 But it's not sustainable. 00:21:30.480 --> 00:21:32.559 So that's what we're automating for our customers. 00:21:32.960 --> 00:21:38.559 And why is security improving much, much more slowly than the generation of code? 00:21:39.440 --> 00:21:40.240 That's a great question. 00:21:40.400 --> 00:21:42.319 One of my favorite topics I spent a lot of time on. 00:21:42.480 --> 00:21:52.319 Because you know, conventional wisdom would say look, we these agents are getting so smart, models are getting so smart, we keep hearing how they can find every security bug. 00:21:52.480 --> 00:21:54.480 Well, why can't it write code security? 00:21:55.599 --> 00:21:59.200 We have to go trace back to the origins of how these models are trained. 00:22:00.319 --> 00:22:04.960 Model from every lab that is learning coding is learning coding based on open source. 00:22:05.119 --> 00:22:08.640 They go index the last 20, 30, 40 years of code that exists on the internet. 00:22:08.960 --> 00:22:12.640 Most of it is on GitHub, maybe Stack Overflow, maybe other places. 00:22:13.039 --> 00:22:19.440 That code has various forms and vectors of security, quality, reliability, et cetera. 00:22:20.319 --> 00:22:28.240 The models are learning not just the good behavior, they're learning all of the inherent security problems that these uh the training code has introduced. 00:22:28.400 --> 00:22:42.960 And it is a very hard technical problem to figure out how to piece away what the model has learned that subsequently was known to have security bugs, and how it was circumvented or fixed later. 00:22:43.200 --> 00:22:48.880 And so models are producing way more code that is insecure than humans. 00:22:49.039 --> 00:22:54.240 The other piece is at the same time, traditionally, at least we had some review processes. 00:22:54.480 --> 00:22:59.279 Human in the loop for every pull request for regulated companies that would review the code base. 00:22:59.599 --> 00:23:00.880 Today you can't do that. 00:23:00.960 --> 00:23:10.319 Like the volume of code being generated is so high, human eyes can't pay attention to catch every security bug, logic bug, architecture bug in the code base. 00:23:10.720 --> 00:23:16.319 And so, yeah, I think the combination of the models themselves generate more insecure code. 00:23:16.559 --> 00:23:24.400 You have citizen developers that don't even understand what is being built and output, and you don't have enough people to review all of this code diligently. 00:23:24.559 --> 00:23:29.279 That is causing much more of your code to be vulnerable. 00:23:29.440 --> 00:23:30.799 That's on your code. 00:23:30.960 --> 00:23:40.400 As it relates to all of the open source code you've been using and relying on, you're finding 10x more vulnerabilities there because, again, models are easily discovering more and more problems. 00:23:40.799 --> 00:23:44.640 And if you're in the open source ethos, whose responsibility is it to fix? 00:23:44.720 --> 00:23:47.039 If I was a hobbyist, I was a college graduate. 00:23:47.200 --> 00:23:50.640 Over the summer, I created a project that became popular. 00:23:50.880 --> 00:23:55.599 Now Anthropics is coming to me and saying, you got to fix these 20 vulnerabilities that we found? 00:23:55.759 --> 00:23:56.400 I'm not interested. 00:23:56.480 --> 00:23:57.920 I'm back to school, I'm busy. 00:23:58.160 --> 00:23:58.559 Right? 00:23:58.799 --> 00:24:02.079 So it's just a very strange world that we live in. 00:24:02.160 --> 00:24:10.400 We rely on all of the software that isn't written by us, and more and more and more vulnerabilities that continue to be discovered. 00:24:10.640 --> 00:24:13.279 But whose problem is to kind of fix things? 00:24:13.599 --> 00:24:22.640 I think it requires a very different shift in mindset because earlier, when code was written, it was assumed to be secure. 00:24:22.880 --> 00:24:32.400 And now we have to just give up with that mindset that any code written cannot be secure because the writing of code has become so easy. 00:24:32.799 --> 00:24:36.400 Yeah, I think I think you had, I would say, three core assumptions. 00:24:36.480 --> 00:24:37.039 That's one. 00:24:37.279 --> 00:24:40.640 Second was the person writing the code was at least a trained software developer. 00:24:40.880 --> 00:24:43.119 Right now, my mom and dad can write software. 00:24:43.279 --> 00:24:44.640 Uh scary thought. 00:24:44.799 --> 00:24:51.519 The third thing was if there was generally an implicit trust in open source. 00:24:51.759 --> 00:24:55.599 If I'm grabbing it from open source, people have had eyes on it, it'll be fine. 00:24:55.920 --> 00:25:10.319 Today, nation state actors, North Korea, China, Russia, others are completely dominating the ability to kind of push malicious code through open source because we have entirely left this space open. 00:25:10.480 --> 00:25:10.640 Yeah. 00:25:10.799 --> 00:25:14.000 It's like your doors may be locked, your windows are open. 00:25:14.240 --> 00:25:16.240 Anyone can ship you any

code. 00:25:16.319 --> 00:25:16.640 Yeah. 00:25:16.880 --> 00:25:20.640 And your pipelines are just pulling in automatically these updates. 00:25:20.880 --> 00:25:36.319 It's a wild thought to think about right now when you think about the fact that anybody can go take over an account without a lot of effort in open source and push malware that affects 500 million downloads a week. 00:25:37.359 --> 00:25:44.559 So I assume uh at Endor, raising money would have become much easier, right? 00:25:44.640 --> 00:25:48.720 Because you had already made so$250 million for your stakeholders. 00:25:48.799 --> 00:25:51.839 The first round on Endor was$25 million, I'm right. 00:25:52.160 --> 00:25:53.680 And second round was 90. 00:25:53.920 --> 00:25:54.559 Yes. 00:25:55.119 --> 00:25:55.599 Yeah. 00:25:55.839 --> 00:26:02.160 Yeah, look, I I am blessed to have a good track record, and fundraising has never been the issue here. 00:26:02.319 --> 00:26:05.039 Every round has been preempted in this company. 00:26:05.119 --> 00:26:10.000 We've never really had to go out officially and run a run a fundraise process. 00:26:10.079 --> 00:26:13.680 Uh, but you know, at the same time, the expectations get higher too. 00:26:13.759 --> 00:26:22.079 I don't think anybody is expecting Varun Badwar to go create another$250 million exit outcome, right? 00:26:22.160 --> 00:26:31.200 I think the the belief, my personal belief, my own expectation of me, let alone everybody else, is that I've did that before. 00:26:31.359 --> 00:26:36.079 I learned how to build a much bigger scale business within Palo Alto Networks. 00:26:36.160 --> 00:26:40.720 And now I want to build an IP oval business independently. 00:26:41.039 --> 00:26:44.960 So expectations get higher, pressure gets higher. 00:26:45.200 --> 00:26:48.000 Also, I think we just we haven't talked about the elephant in the room. 00:26:48.079 --> 00:26:57.279 Like building a business and navigating it through today is wild compared to 2020, you know, 2017, 2018. 00:26:57.839 --> 00:27:00.400 CI, like the speed of change of technology. 00:27:00.559 --> 00:27:05.920 I may have product market fit today, I may not have it in a quarter, even though I'm a scaled up startup. 00:27:06.319 --> 00:27:16.640 Or, you know, a company with one-tenth of the capital could potentially race to building something relatively competitive much faster. 00:27:16.799 --> 00:27:19.519 So the question always becomes like, what's the moat now, right? 00:27:19.680 --> 00:27:23.359 How much of it is, you know, people say this is a system of record mode, data mode. 00:27:23.599 --> 00:27:26.480 Sure, but I think I think those things matter. 00:27:26.720 --> 00:27:35.440 Um ultimately, I think what your customers believe about you and your ability to support and service them, because they're all going through the same shifts. 00:27:35.680 --> 00:27:48.079 Um, how we react, how we show our velocity of shipping with speed and thoughtfulness, um, how we help

them navigate all these changes uh matter the most. 00:27:48.240 --> 00:27:55.119 I think having loyal customers and loyal employees that help you navigate through this change is the best thing you can have. 00:27:55.359 --> 00:28:03.759 But I call it wild because of certainly those two things I mentioned about competitive dynamics, product market fit dynamics. 00:28:04.000 --> 00:28:10.000 Um but also it's like every morning when I wake up and before I get on my phone, there's this little thing in the back of my head. 00:28:10.160 --> 00:28:11.920 I'm like, oh, like what's what's today? 00:28:12.160 --> 00:28:13.519 What's today bringing out, right? 00:28:13.599 --> 00:28:15.839 What is the what is the next big launch from a lab? 00:28:16.079 --> 00:28:18.640 What is the next big thing happening in the industry? 00:28:18.880 --> 00:28:26.640 What you know, we not talked about regulation yet, but there's so much chatter right now about open weight models and is US going to regulate. 00:28:26.880 --> 00:28:29.200 Are certain things gonna get bought banned? 00:28:29.680 --> 00:28:31.119 Like this has consequences. 00:28:31.279 --> 00:28:34.400 These have lasting consequences for companies like us. 00:28:34.559 --> 00:28:39.440 And uh the good news then, I comfort myself thinking I'm not the only one. 00:28:39.519 --> 00:28:44.559 If you're Sam Altman, if you're Dario, it doesn't matter if you're running the best biggest labs in the world. 00:28:44.799 --> 00:28:48.559 That same paranoia has to be living in the back of your head every single day. 00:28:48.880 --> 00:28:55.599 Yeah, because uh Sam and Dario both have the fear of getting disrupted by Chinese open source, right? 00:28:56.240 --> 00:29:00.079 So everybody has the fear of I am not in full control. 00:29:00.559 --> 00:29:07.839 Uh, but you know, as a as a founder, multi-time founder, the last two times I built companies, I felt I have full control of this car. 00:29:08.160 --> 00:29:10.400 And then there are things outside I don't control. 00:29:10.559 --> 00:29:12.240 Now it's like I don't control the outside. 00:29:12.480 --> 00:29:15.039 Also, who knows what shifts, right? 00:29:15.359 --> 00:29:21.279 Um it's exhilarating, it's uh scary at the same time. 00:29:21.359 --> 00:29:24.640 And so you just have to have a very balanced view of what are the things I control. 00:29:24.720 --> 00:29:29.200 I usually chuckle when people ask me what's the two to three year roadmap of Endor. 00:29:29.440 --> 00:29:34.079 I'm like, if I could tell you with high degree of confidence what six months holds, it would be a win. 00:29:34.319 --> 00:29:49.279 Uh because I have now learned to live with situations where we literally last quarter, two of the products we shipped last quarter, if at the beginning of quarter you had asked me if we would be building those things, I would say no way. 00:29:49.839 --> 00:30:01.519 So that's the pace of change that we're living in, and that's the pace of change I'm

trying to help my employees understand is the new reality, is living in controlled chaos or organized chaos, as I call it. 00:30:01.839 --> 00:30:03.519 And how big is the team today at Endor? 00:30:03.839 --> 00:30:06.240 Endor is closing in to about 200 people. 00:30:06.559 --> 00:30:16.960 Uh Bangalore has about 55, 60 people now, and then uh 140, most of whom are in the US. 00:30:17.279 --> 00:30:20.079 And in US, everybody's here in the Bay Area? 00:30:20.319 --> 00:30:22.160 So Bay Area is a high degree of concentration. 00:30:22.240 --> 00:30:24.799 This is a headquarters where you're at today. 00:30:24.880 --> 00:30:30.000 Um, but you know, our go-to-market team is fairly spread out because we have more geographic focus. 00:30:30.240 --> 00:30:33.519 We also have an office in Europe, uh, in the Netherlands. 00:30:33.680 --> 00:30:38.160 Uh, it's a kind of a lot of our deep researchers and engineering talent is built there. 00:30:38.319 --> 00:30:39.599 Uh, and we're continuing to hire. 00:30:39.680 --> 00:30:50.640 So if anybody's listening here and interested in working at the intersection of uh the biggest change of our time, which is agentix software development and how to secure it, then you know, we're looking for people around the world. 00:30:50.880 --> 00:30:53.359 Why is there a Darth Vader in your office? 00:30:54.480 --> 00:31:02.640 So um, if you haven't guessed it with Endoor Labs, the name Endor comes from um kind of inspiration from Star Wars. 00:31:02.799 --> 00:31:14.480 The the quick story on that is you know, 2021, when I was starting the company, LLMs didn't exist, so I couldn't go to an agent and say, help me find a domain name and a uh, you know, uh company name that can align. 00:31:14.640 --> 00:31:17.279 Two hours into this process of trying to find a domain name. 00:31:17.440 --> 00:31:18.079 I was just tired. 00:31:18.160 --> 00:31:19.759 We're watching Star Wars in the back. 00:31:19.920 --> 00:31:26.160 And I needed this done that day because I had a term sheet, and literally the VC needed a name to put on the term sheet. 00:31:26.400 --> 00:31:32.079 So uh my brother-in-law were and I were just joking around and he said, Well, let's try some Star Wars stuff. 00:31:32.240 --> 00:31:33.680 And so I have to give him credit. 00:31:33.759 --> 00:31:37.519 You know, Endor was the name that came from him, which is a forest moon. 00:31:37.599 --> 00:31:45.839 It actually plays very nicely with the David and Goliath kind of storyline at Endor, you know, where the underdogs in security helping secure the world. 00:31:46.000 --> 00:31:53.119 And we play a lot of Endor and Star Wars themes around here, and like the team really wanted Darth Vader around here. 00:31:54.240 --> 00:31:59.839 And we also have Ewoks and little Ewok squishies around, and we call our employees Ewoks. 00:32:00.400 --> 00:32:05.599 So you mentioned that today, for any founder, the market is obviously not in control. 00:32:05.759 --> 00:32:08.240 Their product roadmap is also not in control. 00:32:08.319 --> 00:32:10.720 So, what are the things that are really in control? 00:32:11.759 --> 00:32:17.759 Um, I think the number one thing that is in control is the quality of talent you bring into the company, right? 00:32:18.000 --> 00:32:24.160 So that is non-negotiable because you may think you're building A, you might end up building B. 00:32:24.240 --> 00:32:31.839 Uh, you need the people that are first principles, system thinkers that will basically out-hustle the market. 00:32:32.000 --> 00:32:33.039 So that's one. 00:32:33.519 --> 00:32:42.079 The second thing you control is the culture you define in the company and some of the core things, like for us, customer obsession is critical. 00:32:42.240 --> 00:32:46.799 In times of uncertainty, how do I decide if I do A versus B versus C? 00:32:47.200 --> 00:32:54.559 We believe in our customers, we believe in understanding deeply their businesses, their pains, and understanding how to help them navigate it. 00:32:54.640 --> 00:33:00.880 Because if we can help them navigate their challenges, we will win because then by nature we'll build a good product. 00:33:01.119 --> 00:33:09.279 Uh, and the third thing I think fundamentally is I think entrepreneurship is not just always about solving the hardest unsolved problem. 00:33:09.519 --> 00:33:19.119 It's about solving a large problem in the most practical way with the best distribution and reach you can create. 00:33:19.279 --> 00:33:25.359 So oftentimes I talk to founders that I, you know, will come to me for advice saying, look, I've solved such a hard problem, but I can't get people's attention. 00:33:25.440 --> 00:33:30.480 I'm like, maybe you solved a really, really hard problem, but did you connect it to what the customers' needs are? 00:33:30.720 --> 00:33:47.279 The example I gave is if you're here in mainland USA and you're trying to build this amazing resort in a dream vacation place on an island, and you forget the transport problem, how are you gonna get people to come here to finally see your vision and realize your vision? 00:33:47.440 --> 00:33:48.480 Then you miss the mark. 00:33:48.640 --> 00:33:57.200 And so I always say you got to find a problem that is near-sighted for now, but there's a long path to build, and the arc is pretty uh significant. 00:33:57.440 --> 00:34:00.799 And then work with your customers to get them there to the dreamland. 00:34:00.880 --> 00:34:08.159 But don't be sitting there waiting for your customers, waiting where they are, because maybe you've missed the mark because you were just too far ahead. 00:34:09.119 --> 00:34:12.719 And and how are you thinking about distribution this time? 00:34:13.119 --> 00:34:17.280 And what have been some of the wins in distribution and GTM channels that you are built? 00:34:18.800 --> 00:34:23.440 Look, this is this is always an interesting one, and I wouldn't say that I have solved it end-to end. 00:34:23.519 -->

00:34:25.440 I think we are continuing to iterate on it. 00:34:25.679 --> 00:34:29.760 Um I think to me, tactics have shifted. 00:34:29.840 --> 00:34:34.880 For example, so we first and foremost, we are an enterprise-led, sales-focused company. 00:34:34.960 --> 00:34:37.119 We're not product-led, we're not open source. 00:34:37.840 --> 00:34:39.119 But even in enterprise, right? 00:34:39.199 --> 00:34:45.440 10 years ago, we would have big booths, large conferences, we would collect leads, we would follow up in leads, and we would close business. 00:34:45.679 --> 00:34:47.360 I think today that doesn't work. 00:34:47.599 --> 00:34:55.679 I think events are great to meet people you're already talking to, but not like the big funnel of people that you get leads for. 00:34:55.840 --> 00:35:02.159 I think a lot of how people want to buy today and be sold to is independent research. 00:35:02.239 --> 00:35:07.199 Like they, you have to be in the community, you have to have thoughtful content. 00:35:07.360 --> 00:35:14.000 Um, you have to be in the places where they're doing their research about the space, about your competitors, about you. 00:35:14.480 --> 00:35:19.920 Um, and you have to win them over without them having ever talked to you. 00:35:20.000 --> 00:35:28.639 Because I feel like 80% of the buyer's decision about who they're gonna go with for enterprise technology is made before they have the first sales call with you. 00:35:28.800 --> 00:35:49.199 So I look at that as a core part of opportunity or challenge and say, how do you build go-to-market messaging, brand, thoughtfulness, um, social proofs to make sure that people before they ever talk to you have already been won over by you, uh, even though you're not a PLG company. 00:35:49.599 --> 00:35:54.400 Can you give some examples like where customers found of you from which reports? 00:35:54.800 --> 00:35:55.039 Yeah. 00:35:55.199 --> 00:35:56.880 I'll give you one concrete example. 00:35:57.119 --> 00:36:02.960 We, you know, there's lots of benchmarks about how functionally correct the code is. 00:36:03.039 --> 00:36:13.519 And we said, well, look, everybody's talking about, oh, the coding agents are so good because they can write functional code, but there's no benchmarks that exist to talk about how securely they are writing that code. 00:36:13.760 --> 00:36:14.960 So we said, what can we do? 00:36:15.119 --> 00:36:19.679 Carnegie Mellon and Columbia Universities were working on some research in their labs. 00:36:19.840 --> 00:36:25.519 We partnered with them, we took harnesses that were believable and benchmarks that they had built, not us. 00:36:25.920 --> 00:36:28.239 As a vendor, how are you gonna believe my benchmarks? 00:36:28.480 --> 00:36:44.000 We took that, we invested around that, and we created the entire infrastructure and investment plan where now, every time there's any new model released within 24 to 48 hours, we will test the security efficacy as well as functional efficacy, and we'll publish those results. 00:36:44.159 --> 00:36:46.000 It's called Agent Security League. 00:36:46.079 --> 00:36:46.719 What does it do? 00:36:46.880 --> 00:36:50.800 It just brings people, you know, there's conversation, people are sharing some of these benchmarks. 00:36:50.960 --> 00:36:53.599 Those benchmarks are created by this company called Endoor Labs. 00:36:53.840 --> 00:36:57.039 Maybe people will want to know what Endoor Labs does, how it can help. 00:36:57.199 --> 00:37:00.000 But like we do a lot of unique research. 00:37:00.159 --> 00:37:03.679 We've invested heavily on the research side of this company. 00:37:04.159 --> 00:37:12.400 We uh, if you look at our blogs, most of our blog posts are written by engineers, not by marketing people and salespeople. 00:37:12.559 --> 00:37:16.000 So we're very thoughtful about the depth and quality of the content we create. 00:37:16.079 --> 00:37:18.000 So those would be a couple of examples. 00:37:19.119 --> 00:37:21.360 So, but you're still going to these conferences? 00:37:21.840 --> 00:37:22.239 Yes. 00:37:22.400 --> 00:37:31.679 But we're going from a perspective of not let's have the biggest booth and let's lead scan, but it's presence and like again, it's the halo effect, right? 00:37:31.840 --> 00:37:47.039 When somebody is ready to buy, they will come to us and want to talk to us because they have seen us at places, their friends talk about how great our product is, they have the best experience, we have solved really hard problems, they're seeing good quality research from us in the learning. 00:37:47.280 --> 00:38:00.079 So, you know, you never know when a buyer is ready to engage, but you want to be there at the time and you want to be the top name in their mind when they're ready to engage in a problem that you can solve. 00:38:00.239 --> 00:38:04.159 And so we create a lot more of that halo effect, the community, the content. 00:38:04.480 --> 00:38:09.360 As an example, last week was Black Hat, one of the largest cybersecurity conferences in Las Vegas. 00:38:09.599 --> 00:38:18.960 We didn't have a booth, but we had this incredible restaurant we had taken over inside the convention center that everybody had to pass through to get to the booth. 00:38:19.280 --> 00:38:28.320 We had brunches and lunches and talks and dinners, and people could walk in, spend five minutes, relax, sit down, have a coffee, follow along, move along. 00:38:28.480 --> 00:38:34.239 There's no sales pressure, there's nobody coming in, like, you know, forcing you to take certain actions to get in there. 00:38:34.320 --> 00:38:38.880 And and you know, our hope is it's a memorable thing people leave behind with. 00:38:39.599 --> 00:38:47.119 What are some of the things, you know, in Red Lock uh that you were not doing that you learned on distribution at Polo? 00:38:50.880 --> 00:38:52.079 It's a good question. 00:38:52.320 --> 00:38:56.400 Um look, I think the biggest thing is just scale and

density, right? 00:38:56.480 --> 00:39:01.599 As a startup, you're very scared about like I was, I'm a frugal guy. 00:39:01.679 --> 00:39:08.719 I mean, you know, I I've come from where we had$10 million to go build and scale Radlock. 00:39:09.199 --> 00:39:15.599 Um and what you realize, especially today, more so than ever, is the noise in the spaces is too high. 00:39:15.840 --> 00:39:20.239 You have to build all the way to and get much closer and have the density. 00:39:20.400 --> 00:39:31.519 Like if your competitor has 300 reps and you have three reps and you feel really good about your win rates, the problem is 98% of those conversations you're not even a part of. 00:39:31.840 --> 00:39:34.159 So, and and Wiz did this really well, right? 00:39:34.239 --> 00:39:36.000 You have to blitz really fast. 00:39:36.079 --> 00:39:41.519 Like when you feel like you have product market fit and repeatability, you have to scale faster. 00:39:41.599 --> 00:39:46.559 It's a bold move, it's a scary move, it requires heavy capital investment. 00:39:46.800 --> 00:39:51.119 Because, like with sales, you know, you've got ramp times and other things, but you've got to do it fast. 00:39:51.280 --> 00:39:55.760 The other thing that I'm a big believer in is you can't go at it alone. 00:39:55.840 --> 00:40:04.480 So, like the alliances, the channel, the partnerships matter even more because the customers want a holistic problem to be solved. 00:40:04.880 --> 00:40:12.960 No matter how much you try, you will solve maybe some part or a big part of that problem, but not chances are not the entirety of the problem. 00:40:13.199 --> 00:40:25.599 So you have to pair up with the right like-minded companies where you have technical alignment, but also core fundamental alignment on ICP and um core how you sell and how you position. 00:40:25.840 --> 00:40:31.679 And then you can take much stronger outcomes to the customer that don't necessarily have to be delivered by one company. 00:40:33.760 --> 00:40:37.280 So, so a lot around how to build an ecosystem. 00:40:37.760 --> 00:40:38.159 Yeah. 00:40:39.920 --> 00:40:45.119 How to build an ecosystem, how to build trust with buyers, not be transactional. 00:40:45.760 --> 00:40:48.880 Um I would say are probably the two big things. 00:40:49.199 --> 00:40:54.079 And can you share an example of how at Endor, without selling, you are building trust with the buyer? 00:40:55.760 --> 00:41:01.679 Um I think the you know, the the examples I gave you going back to the Asian Security League. 00:41:01.840 --> 00:41:07.440 Um one of the core beliefs in this company is most of the content on our website is not gated. 00:41:07.920 --> 00:41:13.920 You know, I believe you want people to come learn and educate themselves and not have to fill a form to read your white paper. 00:41:14.159 --> 00:41:19.199 Um so I think we just have to believe, and then we believe heavily in this idea of a hand raiser. 00:41:19.360 --> 00:41:26.000 When they're ready, they will hit the speak to sales button, but you don't need to kind of have that everywhere in your website. 00:41:26.159 --> 00:41:30.000 So everything is gated, a webinar is gated, and this is gated, and that is gated. 00:41:30.239 --> 00:41:31.840 So I think that's one example. 00:41:32.159 --> 00:41:49.119 The second example is um, you know, we had invested initial days, we we probably need to go back to more on this thing called lean app sec, which was this idea of building a community for application security practitioners to communicate with and speak to and exchange ideas with each other. 00:41:49.360 --> 00:41:50.880 Um, that's another one. 00:41:51.039 --> 00:41:53.599 Another one is like all of my sales team and go to market team. 00:41:53.679 --> 00:42:08.079 Anytime a customer says, Well, we're trying to hire for these security people, well, we don't have a recruiting business, but we are generally very particular and trying to help our customers navigate those conversations because again, it builds long-term trust as a partner. 00:42:08.400 --> 00:42:14.559 We basically do things that allow us to be a partner, not a vendor to our customers, if that makes sense. 00:42:18.880 --> 00:42:26.079 And let's say who would be the other players in this market that you respect in app security and code security? 00:42:27.599 --> 00:42:30.000 Uh that's a that's a good question. 00:42:30.239 --> 00:42:44.320 Look, I think the um the question I think I I maybe answer that slightly differently is where are the most logical places that we can insert security that is most native to the experience? 00:42:44.639 --> 00:42:48.159 And I would say like GitHub comes up as an obvious answer, right? 00:42:48.400 --> 00:42:56.239 If if you could have security just be transparent, you don't even know it is there, it just works. 00:42:56.480 --> 00:42:58.000 Developers love GitHub. 00:42:58.159 --> 00:43:06.960 If you and I think GitHub had initially made some really good investments, you know, I think over the last year or so they're trying to figure out their strategy on some of these things. 00:43:07.039 --> 00:43:10.960 But I have a high degree of respect for GitHub for what they've delivered around that. 00:43:11.199 --> 00:43:13.039 Um, so I think that's one. 00:43:13.519 --> 00:43:27.760 Uh beyond that, I think without naming specific companies, I'll say there are there are some of them that have truly taken the pain of figuring out what are real developer problems. 00:43:27.840 --> 00:43:30.239 Let's not just build another compliance reporting tool. 00:43:30.320 --> 00:43:33.440 But like what are real problems in the workflow and solve them? 00:43:33.599 --> 00:43:38.159 And I think those companies that will tend to do well versus ones that'll put some checkboxes. 00:43:38.480 --> 00:43:42.000 So let's say now coding market is getting reimagined. 00:43:43.039 --> 00:43:50.480 Uh so what percentage of coding market would be the app security and

the code security market? 00:43:52.000 --> 00:43:53.360 So it's a great question. 00:43:53.440 --> 00:43:56.960 And I kind of maybe go tie back to starting with the at the very top. 00:43:57.199 --> 00:44:05.920 Most companies security budget is about 6 to 8% of IT budget. 00:44:06.880 --> 00:44:19.199 Then kind of we use that same formula as we're defining cloud security to say, what should a company that spends a million dollars a year on AWS be spending for security of AWS? 00:44:19.440 --> 00:44:21.679 He said probably about the same. 00:44:22.639 --> 00:44:25.599 We solved this problem first at Red Lock and PrismaCloud. 00:44:25.920 --> 00:44:34.559 Then cloud providers started charging the same way for their internal security tooling built into their platform, 10%, X percent. 00:44:34.719 --> 00:44:49.679 So I think generally it's pretty safe to say if you apply the same formula forward, is that overall of your soft, of your STLC budget, about 10% should be security. 00:44:49.840 --> 00:44:57.679 Now the STLC is not just your GitHub license, because like I would argue with you, actually let's take GitHub as an example, very fascinating example. 00:44:57.920 --> 00:45:03.920 The GitHub Enterprise License costs about$25, give or take, as a number, right? 00:45:04.320 --> 00:45:06.239 Per developer per month. 00:45:06.719 --> 00:45:12.639 GitHub's own security product add-on to this costs about$50. 00:45:13.280 --> 00:45:20.400 So you can argue and say security is twice as much of value than the core GitHub. 00:45:20.559 --> 00:45:27.679 So I think it is value dependent, but overall, if you looked at IT budget, 10% of IT budget's usually security, so you can kind of play that, play that along. 00:45:29.599 --> 00:45:39.840 And do you imagine like how much people pay on cloud security and infra security, they would pay the same for code security and app security also? 00:45:41.599 --> 00:45:42.480 Probably more. 00:45:42.960 --> 00:45:43.840 Probably more. 00:45:44.079 --> 00:45:44.719 Why? 00:45:45.280 --> 00:45:47.599 Um just where in the value chain you sit. 00:45:47.679 --> 00:45:51.440 Like if you think about it, like your revenue as a company, right? 00:45:51.519 --> 00:45:58.079 If I'm Snowflake or MongoDB, my product, my software is my revenue. 00:45:58.400 --> 00:46:01.280 I exist as a public company because of my software. 00:46:02.639 --> 00:46:15.199 If I lose trust or erode trust, or there's an incident, or there's a security issue that affects my customers and my software, overnight I will erode 10 to 20% of my market cap. 00:46:15.920 --> 00:46:18.880 That's probably 20, 40 billion dollars. 00:46:19.199 --> 00:46:24.079 Will be eroded overnight if I have a security incident in my software. 00:46:24.639 --> 00:46:31.840 So I think your software, if software is your business and your lifeline, security matters significantly. 00:46:32.480 --> 00:46:41.199 But let's say for non-software companies like Ford or GM, General Motors, or anybody else, wouldn't that be still be critical for them? 00:46:42.079 --> 00:46:42.800 Great question. 00:46:42.880 --> 00:46:48.559 I guess the the thing I would ask you back is which company is not a software company today? 00:46:48.880 --> 00:46:52.480 Do you think GM and Ford can operate without connected cars? 00:46:52.800 --> 00:46:58.639 What if, and there's been lots of uh public um research on hacking cars? 00:46:58.800 --> 00:46:59.920 How are the cars hacked? 00:47:00.000 --> 00:47:01.519 Not through the engine, from the software. 00:47:01.599 --> 00:47:01.920 Yeah. 00:47:02.400 --> 00:47:06.719 What happens if somebody hacks and crashes cars now on the highway? 00:47:07.199 --> 00:47:10.559 So I think software fuels the world. 00:47:10.800 --> 00:47:16.480 Um yes, hardware is back again, not dismissing that, but software still fuels the world. 00:47:16.719 --> 00:47:30.320 And I think any company where the core of your product somehow fits in software, maybe it's not more than 10%, but I think on a base case it should be 10% spent on your overall IT budget for code security as well. 00:47:30.480 --> 00:47:32.960 Uh maybe take it from a different lens, okay? 00:47:34.400 --> 00:47:42.960 Most companies I talk to, the engineering teams spend 20 to 30% of their time on just security issues. 00:47:43.519 --> 00:47:48.559 Follow-ups, bugs, security bug fixes, vulnerability remediation, pen test report. 00:47:50.079 --> 00:48:06.000 So take that and say, if I can give you back half of that, that economic impact is about 15% of your total payroll cost, fully loaded headcount cost of your engineers. 00:48:06.480 --> 00:48:12.719 So if I'm gonna do that, arguably if you spend, you know, we're sitting in the Bay Area, so let's talk Bay Area salaries. 00:48:12.880 --> 00:48:18.400 You're spending$300,000 a year on um an engineer's salary. 00:48:18.559 --> 00:48:19.039 Yeah. 00:48:19.440 --> 00:48:28.480 If$90,000 worth of their time is spent on security, and I can fix that for$9,000 a year, I think you would happily pay that. 00:48:28.639 --> 00:48:28.960 Yeah. 00:48:29.360 --> 00:48:30.000 Right. 00:48:30.320 --> 00:48:46.400 And now is$9,000 a year for that security solve on where you're spending$300 for their GitHub license, you would still pay that if I can create the value connectivity and prove to you that I can give you back$90,000 worth of efficiency. 00:48:46.559 --> 00:48:49.039 So that's how I think about kind of value-based selling. 00:48:49.440 --> 00:48:53.679 And today, um, out of Fortune 500, how many logos would you have? 00:48:54.880 --> 00:49:06.880 Look, I think what's interesting about our business is for the reasons we were just having this conversation on like software is the lifeline for tech businesses. 00:49:07.199 --> 00:49:18.880 Um, a lot of our customers end up started out being the tech companies, companies like DoorDash companies, like the big labs that I can't name here on uh on air. 00:49:19.119 -->

00:49:27.360 Cursor is a customer, Glean's a customer, Atlassian, MongoDB, Snowflake, Peloton, Robinhood. 00:49:27.599 --> 00:49:32.960 So I think for us, where we were trying to drive efficiency are the companies that were really manically focused on that. 00:49:33.039 --> 00:49:36.400 So you know, they weren't your legacy Fortune 500s, if you will. 00:49:36.639 --> 00:49:42.400 But you know, over time we have several Fortune 500 companies, several of the world's top insurers, financial services. 00:49:42.480 --> 00:49:55.440 But just as a metric, we focus and fixate less as our claim to success being the Fortune 500, versus we we kind of look at it more as are the world's most prolific software companies, how of those, how many are using an Endor? 00:49:55.679 --> 00:50:00.639 And that number continues to uh you know go up and to the right. 00:50:01.599 --> 00:50:04.480 And engineering wants to shift faster, always, right? 00:50:04.719 --> 00:50:06.880 And never been fast as today. 00:50:07.039 --> 00:50:11.360 And security wants to hold back and slow things down, making sure nothing breaks. 00:50:11.599 --> 00:50:17.519 So you think that uh the equilibrium has further distorted than five years ago? 00:50:18.239 --> 00:50:20.000 I I think it's a challenge and opportunity. 00:50:20.159 --> 00:50:22.320 For sure, we're producing more code than ever before. 00:50:22.480 --> 00:50:24.639 And so the bottleneck is no longer code generation. 00:50:24.719 --> 00:50:25.679 That's not your constraint. 00:50:25.840 --> 00:50:27.280 Generation is a solved problem. 00:50:27.519 --> 00:50:33.360 Everything after that is where the bottlenecks are, security being a major one, quality being another one. 00:50:33.599 --> 00:50:43.920 Um but yeah, I I think I think as people are moving even faster, now security looks like even slower because of that reason, unless they're retoolable. 00:50:44.159 --> 00:50:54.400 And and I think this is also a great opportunity because all of the things that were unsolvable security problems, you can now do more efficiently with agents. 00:50:54.559 --> 00:51:03.519 And so I think the whole idea here at Endoor Labs is how do you use a genetic software security solution to keep up and deliver far more effective security programs. 00:51:03.920 --> 00:51:13.119 So, how do how do you make uh the engineering team and the secure team work in in uh in the same harmony at the same pace? 00:51:13.440 --> 00:51:16.480 Yeah, I think it comes down to the metrics of what what matters to you. 00:51:16.559 --> 00:51:18.800 It was the example I was giving you on cost efficiency. 00:51:18.960 --> 00:51:22.960 What matters to the CTO is can they move fast and can they ship fast? 00:51:23.280 --> 00:51:28.079 No CTO in the world wants to ship an unsafe application, but that's not the core metric. 00:51:28.239 --> 00:51:34.559 Like I don't know too many engineering teams that are obsessing about security, they're obsessing about speed and quality. 00:51:34.880 --> 00:51:41.280 And so for us, it's like we always think about Endor and our products called ORE, our platform, eugenic platform. 00:51:41.440 --> 00:51:44.559 Even actually, the icon of ORE is a bridge. 00:51:44.719 --> 00:51:47.199 And that's supposed to be a bridge between security and engineering team. 00:51:47.360 --> 00:51:50.239 Security wants to move fast, we need to give them the tools to move. 00:51:50.320 --> 00:51:54.079 Uh sorry, engineering needs to move fast, we need to give them the tools to move fast. 00:51:54.320 --> 00:51:57.599 Security needs to move safe, we need to give them the tools to move safe. 00:51:57.760 --> 00:52:03.599 The connective tissue is the developers should never get out of their workflow and should have minimal interrupts. 00:52:03.840 --> 00:52:06.800 So Endor runs where the developers are. 00:52:07.119 --> 00:52:11.679 Security gets the report where they want it, and that's how we design our interfaces of our product. 00:52:12.079 --> 00:52:20.320 We would love to know some of the stories of what went right, some of the visions that went right in Endor and what didn't go right as planned. 00:52:20.800 --> 00:52:28.320 Um maybe let's actually I want to start with some of the going right versus going wrong dating back to my first startup. 00:52:28.559 --> 00:52:32.559 Because I think it's you know learnings have begun from there. 00:52:32.960 --> 00:52:41.199 Um as I kind of touched on briefly before, I have come to realize and appreciate just how important having the right talent is. 00:52:41.760 --> 00:52:48.079 At CypherCloud, our first company, uh, my co-founder CEO was self-funding a lot of that. 00:52:48.320 --> 00:52:52.800 And so I think initially, as a self-funded company, we're scrappy about talent. 00:52:52.880 --> 00:52:56.880 There's a lot of good talent, but very young, early in career talent. 00:52:57.119 --> 00:53:02.880 And we didn't round that up with the right mix of uh seniority and experience. 00:53:03.199 --> 00:53:08.400 And I think long term there was just a lot of technical debt in that architecture and that platform. 00:53:08.639 --> 00:53:16.559 Because yes, we could deliver features really, really fast, but it was hard to understand at what cost and what we were compromising in doing so. 00:53:16.800 --> 00:53:21.360 So I think that was kind of one of my learnings from there was the quality of talent. 00:53:21.599 --> 00:53:28.320 I'd rather have fewer people than like earlier and cheaper. 00:53:28.480 --> 00:53:35.039 Um and I think today, though, that's become easier because you just don't need the same volume of people with AI. 00:53:35.199 --> 00:53:37.039 You can do a lot more with fewer people. 00:53:37.119 --> 00:53:38.320 So that was kind of one there. 00:53:38.480 --> 00:53:45.440 At Redlock, um, one of my big learnings was like when you hire salespeople, hire in pairs. 00:53:45.599 --> 00:53:49.280 What I mean by that is oftentimes people will be like, oh,

I'm hiring my first salesperson. 00:53:49.440 --> 00:53:56.559 And I always say when you're hiring the first salespeople, what first person, what territory are you gonna put them in? 00:53:56.639 --> 00:54:02.880 Right, how people on the west coast of US Buy is very different from how people on the east coast of US buy. 00:54:03.440 --> 00:54:07.760 Uh also, what background do you want somebody to be? 00:54:07.920 --> 00:54:11.519 Uh, do you want a startup background or is a large company background okay? 00:54:11.679 --> 00:54:13.920 So, you know, the individual's background matters. 00:54:14.079 --> 00:54:28.000 And the third thing is with sales, unlike many other functions where like I'll know in the week or two weeks or three weeks if this is working or not, in sales, you may not know for six months, nine months, maybe even twelve months, if it's actually working or not. 00:54:28.079 --> 00:54:31.679 And if it's not working, is the problem that individual? 00:54:31.920 --> 00:54:35.519 Is it the accounts you're targeting or your um product? 00:54:35.760 --> 00:54:39.920 And so at Redlock, I originally started with that following that principle of higher-end pairs. 00:54:40.000 --> 00:54:42.239 I hired two people, and I'm so grateful I did. 00:54:42.320 --> 00:54:45.920 I put one person in California, one person in New York. 00:54:46.559 --> 00:55:00.800 And I would say the person in New York probably had way higher of a more experienced background and became way more well referred and reputable, et cetera, et cetera. 00:55:00.960 --> 00:55:03.360 The person on the west was just scrappy. 00:55:03.679 --> 00:55:12.800 And it turns out nine months later, the person on the west had closed five deals, the person on the east had closed zero deals. 00:55:13.039 --> 00:55:21.280 And I swear, if I didn't have the person on the west coast, I would have believed that Redlock, we had built the wrong product. 00:55:21.519 --> 00:55:25.039 The reality was we had not built the wrong product, we had built the right product. 00:55:25.360 --> 00:55:37.519 We actually were even targeting the right kind of accounts, but the individual was going through some life issues, personal life issues, and other things we didn't know at the time, that was affecting their ability to execute and perform. 00:55:38.000 --> 00:55:39.440 And that's very hard to tell. 00:55:41.840 --> 00:56:00.960 So I think come like tying all of that together today to uh endor, and you kind of asking about like what's working, what's not, I think you you have to when you're looking for talent, you need to find people that are you finding them at the right point in their career? 00:56:01.119 --> 00:56:07.119 Are they ready and and willing and understanding of what it takes to be in a startup? 00:56:07.199 --> 00:56:16.800 Because they could be extremely successful where they are, but the fit of your company, your stage, and your needs matters way more than you think. 00:56:17.039 --> 00:56:18.639 Because a lot of times we want that brand, right? 00:56:18.719 --> 00:56:22.480 I want to be able to go to an investor and say, look, I have five engineers from Meta. 00:56:22.639 --> 00:56:31.039 But are those five engineers from Meta the right background and DNA of what you need to go find product market fit on a zero-to-one product? 00:56:31.440 --> 00:56:37.039 And what do you say in Endor, finding product market fit is as hard as Redlock? 00:56:37.440 --> 00:56:40.480 Or has it become easier also as like a third-time founder? 00:56:40.880 --> 00:56:41.840 I wouldn't say it's easier. 00:56:41.920 --> 00:56:48.480 I think it's also not a fair comparison because um red lock was a market creation moment. 00:56:49.039 --> 00:56:53.280 We were creating a new category of products to solve a new pain. 00:56:54.400 --> 00:57:05.199 At Endor, we have been creating a new architecture and paradigm, an entirely new way of solving an age-old problem. 00:57:05.519 --> 00:57:09.440 It's almost like we at Redlock, we were inventing cars. 00:57:09.599 --> 00:57:10.800 Cars didn't exist. 00:57:12.320 --> 00:57:16.480 At Endor, we are moving from gasoline to electric cars. 00:57:16.559 --> 00:57:30.880 Like we've changed the entire drivetrain of what a car looks, what is possible with a car, and introduce those self-driving capabilities that you can actually believe are safe and can work and scale that didn't exist. 00:57:30.960 --> 00:57:39.119 So I think there's a completely different structure of how to compare a market creation versus a market disruption. 00:57:39.440 --> 00:57:42.880 Um, so that's kind of why I don't think it's a fair comparison. 00:57:44.079 --> 00:57:46.719 Got but has it been easier or more difficult? 00:57:46.880 --> 00:57:47.679 What would you say? 00:57:47.840 --> 00:57:48.559 It's been different. 00:57:48.719 --> 00:57:55.840 And I say that because when when you are creating a category, there's no incumbency. 00:57:55.920 --> 00:57:59.119 So whatever you define either solves the problem or doesn't. 00:57:59.360 --> 00:58:16.159 When you're disrupting an existing category that's been around for 20 years, you need to build the differentiation, but you've got to build the long tail of every other feature function that existing products have and support and integrations, because that's what a customer has been using for many years. 00:58:16.320 --> 00:58:29.760 So they need all of that that they use, and they need a significant order of magnitude differentiation to go through the work and pain of removing an incumbent tool and swapping it out. 00:58:30.559 --> 00:58:38.639 The thing that then shifted and put this into hyperdrive for Endor was when AI coding came along. 00:58:38.800 --> 00:58:48.159 Because until AI coding came along, it was like, look, you've had this problem, you've tolerated it, now you need to change your way so you can get a better experience. 00:58:48.480 --> 00:58:55.920 The AI coding agent disrupted

entirely what a workflow looks like, what an agentic STLC, how you create software. 00:58:56.239 --> 00:59:05.519 It completely disrupted this whole idea of, you know, today we're identifying 16 times more vulnerabilities than we can fix. 00:59:05.760 --> 00:59:10.480 That gap has widened more in the last year than it has in the last 10 years. 00:59:10.719 --> 00:59:12.639 That pain didn't exist for the last 10 years. 00:59:12.719 --> 00:59:25.760 So I would say the hyperdrive is coming from AI coding agents are now saying, well, not only is this a disruption of an existing category, but it's an entire rewrite of the entire workflow of how you do the moving forward. 00:59:26.320 --> 00:59:38.000 So hypothetically, if you imagine at a company, a tech forward company, if 100x more code is getting written, are the vulnerabilities also increasing by 100x? 00:59:39.679 --> 00:59:41.280 Easily, yes. 00:59:41.440 --> 00:59:46.719 Because I think the linear formula would say that. 00:59:51.599 --> 00:59:56.239 It's not just you're creating more software, you're also creating them at a more faster pace. 00:59:56.400 --> 01:00:00.880 The other challenge, I was with a CIO of a very large entertainment company. 01:00:01.039 --> 01:00:06.159 And he said, Warren, look, my problem is not just I have citizen developers. 01:00:06.239 --> 01:00:08.719 My finance team is building a forecasting app. 01:00:09.440 --> 01:00:14.800 And we happened to go analyze that code, we found a security bug. 01:00:15.039 --> 01:00:21.039 We emailed the individual who is writing that code, and we said, Here, could you please fix this vulnerability? 01:00:21.280 --> 01:00:24.719 Do you want to guess what the response of that individual was to the security team? 01:00:25.039 --> 01:00:26.000 I didn't create it. 01:00:26.320 --> 01:00:27.280 The agent created it. 01:00:27.360 --> 01:00:28.079 So please ask me. 01:00:28.400 --> 01:00:31.280 Actually, even more fundamental, which is what's a vulnerability? 01:00:31.440 --> 01:00:46.880 Like now you're talking about securing an ecosystem of code that is being generated 10 times faster with more security problems, but also the dynamics of the individuals you're working with, is you're going back to their baseline. 01:00:46.960 --> 01:00:52.239 So at that point, to your, I basically where you're going with your idea is security just needs to be autonomous. 01:00:52.400 --> 01:00:59.440 Security just needs to be handled for the user, not being something that a user needs to think about and be trained about. 01:00:59.599 --> 01:01:01.119 And I think that opportunity exists. 01:01:01.280 --> 01:01:02.079 Think about this. 01:01:02.239 --> 01:01:08.880 For the last 20 years, for people who are on this podcast that are listening, that are software engineers. 01:01:09.440 --> 01:01:14.079 Every year in your company you go through an annual security training. 01:01:14.239 --> 01:01:15.440 They teach you how to write code. 01:01:15.840 --> 01:01:18.159 But then there are 20,000 of you in the company. 01:01:18.400 --> 01:01:25.119 Do we realistically believe that 20,000 people will remember and follow all the instructions on how to do things manually? 01:01:25.440 --> 01:01:26.320 Unlikely. 01:01:26.719 --> 01:01:35.440 But with agents, you can actually give agents consistent instructions to follow the same parameters if you can infuse that intelligence to them. 01:01:35.599 --> 01:01:41.039 So like at Endor, our product infuses that intelligence into cloud code, into cursor, into codecs. 01:01:41.199 --> 01:01:51.119 And just make sure when they are creating these loops of code, the security intelligence is fused in and they're instructed to fix the problems they're introducing right at the source. 01:01:51.280 --> 01:01:55.119 And I think agents are far more capable to do that consistently than humans can. 01:01:55.440 --> 01:01:59.440 I think that's the we've been talking a lot about like the risks of AI. 01:01:59.519 --> 01:02:00.800 But that's the boon of AI. 01:02:00.960 --> 01:02:11.199 We can now solve these problems that have been unsolved for 20 years, despite more volume, despite reduction in time we have to fix these differently. 01:02:11.360 --> 01:02:13.360 And that's what I'm most excited about. 01:02:13.760 --> 01:02:24.159 So uh at Endor, when the code is getting reviewed as it's getting written, is it completely autonomous? 01:02:24.559 --> 01:02:25.360 It can be. 01:02:44.480 --> 01:02:55.199 Some of our customers are in the everything is fairly autonomous unless it's a known large disruptive change, you gotta bring a human in the loop. 01:02:55.519 --> 01:03:01.840 There are others that are still using our context to create gear tickets and not be in the developer workflow. 01:03:02.480 --> 01:03:10.639 This goes back to my uh example of meet customers where they are and then take them to your promised land and dreamline. 01:03:11.119 --> 01:03:17.039 If we had designed the product to just be autonomous, what would we do with all the customers that are not ready? 01:03:17.119 --> 01:03:22.159 And so I think it becomes really important to think about designing your product for the masses. 01:03:22.320 --> 01:03:34.159 And that's kind of where one of the common fallacies a lot of startups in Silicon Valley have is they'll talk to their friends in Silicon Valley, understand the problem, build a product, and be like, oh, well, nobody else is really thinking of it this way. 01:03:34.320 --> 01:03:38.800 And so I always tell people when they're ideating, don't be in the bubble. 01:03:39.039 --> 01:03:51.360 Get out of the bubble and go talk to you know the company that has a 40-year-old code base or has 100,000 employees worldwide that is regulated entirely differently than how Silicon Valley operates. 01:03:52.000 --> 01:03:58.800 But but your agents are always watching the AI coding agents, whatever they be. 01:03:59.119 --> 01:03:59.599 Yes. 01:03:59.840 -->

01:04:16.960 So our security agents essentially get integrated into the um your favorite IDE, and they are established through workflow and requirements to be a step in the coding process. 01:04:17.119 --> 01:04:36.000 So when Claude is iterating on your spec and writing the code, Claude's job is not done till it has gone through Endorse feedback on that code, seen what problems it introduced, fixed them, re-verified them, and when Endor says good, that's when the plan is complete. 01:04:36.400 --> 01:04:42.400 So whose responsibility is that uh the Endor's plan is executed? 01:04:42.559 --> 01:04:43.840 Is it Claude's responsibility? 01:04:44.000 --> 01:04:45.920 Is it Endor's responsibility? 01:04:46.320 --> 01:04:49.119 Uh it's a it's a shared responsibility. 01:04:49.519 --> 01:04:53.519 It's the way you um insert the product into the workflow. 01:04:53.599 --> 01:05:01.679 So with Claude, with Cursor, they're now giving you more and more tools to enforce certain tools to be run or certain actions to be taken. 01:05:01.920 --> 01:05:06.639 And so using those things, specifically, uh Claude has something called Claude Hooks. 01:05:07.280 --> 01:05:13.280 You can actually mandate deterministically that Claude has to abide by the instructions of Endor. 01:05:14.159 --> 01:05:15.679 So that's how it works. 01:05:16.480 --> 01:05:21.280 We use their configurations to put ourselves in the workflow. 01:05:22.159 --> 01:05:32.320 So does Endor today become like a firewall, like omnipresent and um there are components of it that does. 01:05:32.480 --> 01:05:35.199 Actually, it's interesting you bring up the word firewall. 01:05:35.920 --> 01:05:37.679 With malicious open source, right? 01:05:37.760 --> 01:05:39.280 I told you this is free for all. 01:05:39.519 --> 01:05:52.639 You pull this, by the way, it'll surprise you to hear that the agents, a third of the time when they're recommending open source libraries and dependencies, they're making it up. 01:05:52.880 --> 01:05:58.079 They are not real names, they're not real versions, or they're pulling really outdated stuff. 01:05:58.400 --> 01:06:00.639 So if you think about the Firewall concept. 01:06:00.719 --> 01:06:17.280 What Endor will do is any developer or any agent that is pulling an open source package or an open source model or a skill that is malicious, that has malicious instant intent because we're evaluating them, we can block them. 01:06:17.440 --> 01:06:19.679 We actually call it a package firewall. 01:06:20.000 --> 01:06:22.719 So in some use cases, yes. 01:06:22.960 --> 01:06:30.800 But I think firewall also annotates a slightly different meaning to me, which in package firewall case is like a yes-no. 01:06:30.960 --> 01:06:32.480 It's a guard at the gate. 01:06:33.280 --> 01:06:36.559 We're not just a guard at the gate that is one use case. 01:06:36.800 --> 01:06:42.480 It's also we're the fitness trainer, we're teaching that agents how to write more secure code for you. 01:06:42.800 --> 01:06:45.920 We are your house manager, right? 01:06:46.000 --> 01:06:52.880 When all of this pile of more new vulnerabilities comes in, we're figuring out what you need to fix, how to fix it, getting that job done for you. 01:06:53.039 --> 01:06:54.639 So I think it's all of the above, right? 01:06:54.800 --> 01:06:57.679 We we want to run your house as effectively as you can. 01:06:57.760 --> 01:07:03.599 So we're a house manager, we're a cleaner, we're a security guard, all of that. 01:07:05.519 --> 01:07:34.480 And uh, you know, one of the things, you know, before we dive into the last part of the podcast, which is Rapid Fire, uh, is you know, for the founders that are listening and their companies are in acquisition discussions, what have been some of your best learnings on the ground on acquisitions, on the process, price, getting multiple LOIs to make sure that, you know, uh in US the uh the LOI drop rate is one by third. 01:07:34.559 --> 01:07:38.559 Like only one by three, one out of three LOI LOIs get converted into. 01:07:38.960 --> 01:07:39.599 Yeah. 01:07:39.920 --> 01:07:42.880 I think we can probably record a whole podcast on this topic. 01:07:43.039 --> 01:07:47.519 Um in a rapid fire style, no particular order, I'll I'll share a few things. 01:07:47.760 --> 01:07:56.480 One, you know, you can't when I start with saying as a founder, never a lot of people come to me and say, well, I'm just building this because I want to get acquired in the next year. 01:07:56.559 --> 01:07:59.039 And I say, like, you're building for the wrong reasons then. 01:07:59.280 --> 01:08:03.760 Um, your job is to be bought, not to sell. 01:08:04.000 --> 01:08:06.639 And in order to do that, you have to be in a position of strength. 01:08:06.800 --> 01:08:11.280 In order to be in a position of strength, you don't think about and build a company to get acquired. 01:08:11.360 --> 01:08:17.600 You build it to be the best or the second best at worst case in whatever problem you're solving. 01:08:17.760 --> 01:08:19.520 So I think that's one thing for me. 01:08:19.760 --> 01:08:23.680 The second thing is these relationships start long before transactions. 01:08:23.920 --> 01:08:34.800 So, you know, if you know that you would love to, or you think your target, ideal targets are these three companies, you should be finding ways to prove the better together stories years before. 01:08:35.039 --> 01:08:47.359 A lot of times manifests as potential investment, strategic investment, could be them being a customer of your product, could them being doing co-selling of your product, there being technical integrations and value delivery. 01:08:47.520 --> 01:08:53.920 So that value and engagement needs to start way before, months to years before a potential acquisition. 01:08:54.000 --> 01:08:56.479 Because you want to show, like, this is so obvious. 01:08:56.640 --> 01:08:59.359 Like, why aren't we doing more of this? 01:08:59.760 --> 01:09:04.000 Um,

most acquisitions also fail. 01:09:04.079 --> 01:09:05.680 Like, I think you talked about the LOI rate. 01:09:05.760 --> 01:09:13.279 I would say 90% of the acquisitions probably fail post-closing if just like didn't deliver the promise. 01:09:13.520 --> 01:09:23.840 And as I've kind of inspected that much more closely as to why that happens, I think the fundamental mistake, the obvious mistake every company makes is great, I acquired this company. 01:09:23.920 --> 01:09:26.720 There's 500 people from this company I acquired. 01:09:26.960 --> 01:09:29.840 I'm a 5,000-person company, so guess what? 01:09:30.159 --> 01:09:34.319 The hundred engineers will go into my 2,000-person engineering org. 01:09:34.800 --> 01:09:39.760 And the 50 sellers will go into my thousand-person sales org. 01:09:39.840 --> 01:09:45.279 And you know, and you just break the entire culture of the company. 01:09:45.439 --> 01:09:52.319 And you'll usually put them under a GM of a business that likely has failed to solve this problem internally. 01:09:52.479 --> 01:09:55.359 Because if they hadn't, you would have not gone out and acquired a company. 01:09:55.520 --> 01:09:57.039 If you could have done it better, you would have. 01:09:57.199 --> 01:10:02.560 You're buying this because it's an important problem to solve and you haven't been able to solve it fast enough or well enough. 01:10:02.720 --> 01:10:06.800 And now you'll put this founder and this company under this individual. 01:10:07.039 --> 01:10:08.640 And I think all of that is so wrong. 01:10:08.800 --> 01:10:16.399 Because one, you take the entire existence of the company, is the culture and the operating rhythm that the startup has created to work together. 01:10:16.640 --> 01:10:18.960 And you shouldn't, on day one, split it up and break it. 01:10:19.039 --> 01:10:20.720 Maybe there's a day and time to do that. 01:10:20.880 --> 01:10:32.079 But I think for until stabilized, you need to keep that unit as tightly coupled as possible to keep doing what they're doing while it's they integrate into your acquired company. 01:10:32.479 --> 01:10:36.720 The second thing is there's something to be said about the founder hustle and the founder mindset. 01:10:36.800 --> 01:10:40.960 And like there's instincts, there's a reason you were successful and the big company wasn't. 01:10:41.359 --> 01:10:46.479 And so I think you have to be very careful in the dynamics of who's leading what part of the business. 01:10:46.640 --> 01:11:05.039 And I think going kudos back to Nikesh and Palo Alto Networks, they were very good at making sure the founders were leaders of whatever this business was they were acquiring and were continuing to lead to the greatest degree possible their integrated teams, as is, with maybe more fuel, more capital, to scale faster. 01:11:05.199 --> 01:11:16.880 Like the first thing wasn't break down the company, first thing was scale it 10 times faster and then go figure out the right natural multi-year uh

evolution of the organization. 01:11:17.760 --> 01:11:23.520 So, so in your case, did you have a relationship with Polo much before the acquisition happened? 01:11:23.920 --> 01:11:30.720 Uh not besides when they bought my biggest competitor, they had also talked to us and perceived us to be too small at the time. 01:11:31.439 --> 01:11:36.319 So, so no, we didn't have a actually my whole most of my rule on that one failed. 01:11:36.800 --> 01:11:40.640 That was just a very unconventional um acquisition, to be honest. 01:11:40.880 --> 01:11:44.479 So, why did they they they buy Red Lock when they had already bought the computer? 01:11:46.000 --> 01:11:48.399 Uh because we were kicking their butt in the field. 01:11:48.479 --> 01:11:56.479 Like we were we were a better long-term architecture that was multi-cloud. 01:11:56.960 --> 01:12:04.800 Um and and frankly, I think that was one of the core pieces of like our architecture was much more extensible. 01:12:04.960 --> 01:12:15.119 Like you could build, sell, and scale a lot more capabilities on the uh Redlock architecture than the evident I.O. 01:12:15.199 --> 01:12:15.520 architecture. 01:12:15.680 --> 01:12:18.479 I would say that's probably where it came down to the most. 01:12:18.880 --> 01:12:20.960 And of course, the results in the field. 01:12:21.119 --> 01:12:24.239 Like Palo Alto customers were preferring Redlock. 01:12:26.079 --> 01:12:28.479 So they were hearing from their customers. 01:12:28.720 --> 01:12:30.000 I think that's the best way. 01:12:30.239 --> 01:12:30.640 That's right. 01:12:30.800 --> 01:12:35.760 When you are able to beat them at their customers, which is a very tough thing to do for a younger startup. 01:12:36.000 --> 01:12:36.159 Yeah. 01:12:36.319 --> 01:12:37.920 With only$10 million raised. 01:12:38.159 --> 01:12:38.560 Yes. 01:12:38.800 --> 01:12:44.159 But today Palo Alto is a very different beast from that point in time, right? 01:12:44.399 --> 01:12:44.720 Yes. 01:12:46.399 --> 01:12:51.279 In your opinion, because you acquired nine companies for Polo, right? 01:12:51.439 --> 01:12:53.920 What makes Polo so successful? 01:12:55.600 --> 01:13:00.720 I think all the mistakes that I said most companies make, they don't make those mistakes. 01:13:01.279 --> 01:13:04.000 They keep the units as closely together. 01:13:04.079 --> 01:13:08.239 If you listen to a lot of Nikesh's public wisdom on MA, he says the same thing. 01:13:08.479 --> 01:13:17.119 Usually the founder of the business, the CEO, or the founder specifically, will get to lead this business inside of Palo Alto Networks. 01:13:17.279 --> 01:13:22.560 They will keep the unit as closely intact as together as they can. 01:13:23.840 --> 01:13:25.119 I think it's really the mindset. 01:13:25.199 --> 01:13:27.600 The mindset's not, hey, we're the bigger guys, we know what we're doing. 01:13:27.680 --> 01:13:31.600 It's like we bought you because you're doing something right that we couldn't do. 01:13:31.840 --> 01:13:36.399 And we want you to show us how it can be done even better at a bigger scale here. 01:13:36.720 --> 01:13:38.880 And we'll give you the resources. 01:13:39.119 --> 01:13:47.359 Like, think of it as you got a growth stage investor with a blank checkbook that's going to allow you to do everything you can with a long-term play in mind. 01:13:47.680 --> 01:13:52.960 But but then uh every founder that Paulo acquires would stay for an infinite period of time. 01:13:53.119 --> 01:13:57.520 Because if their incentives are aligned, they're getting infinite capital. 01:13:57.680 --> 01:13:59.199 Why would they then go out? 01:14:00.159 --> 01:14:10.960 Because remember, I told you at some point, it's unsustainable for Palo Alto to can't run 25, 30, whatever acquisitions they've done as 25 business units. 01:14:11.199 --> 01:14:14.880 Some point these things at their natural point come together. 01:14:15.279 --> 01:14:19.920 And look, that period of time is usually finite, two to three years. 01:14:20.159 --> 01:14:23.920 Um I will say though, a lot of founders there have stayed on. 01:14:24.079 --> 01:14:27.760 I stayed beyond my retention period and golden handcuffs period. 01:14:28.000 --> 01:14:29.680 Others I know have stayed beyond. 01:14:29.840 --> 01:14:37.119 So I will say Palo Alto is probably, by the track record, most successful at keeping founders around and motivated and excited to do what we do. 01:14:37.279 --> 01:14:40.399 It's one thing to be on payroll and just be there. 01:14:40.640 --> 01:14:43.600 It's another thing to be adding value and making a dent. 01:14:43.680 --> 01:14:53.600 And I think a lot of people are very motivated, Paulo, to I think they've had the highest success rate in terms of odds of acquisitions that have done well. 01:14:54.960 --> 01:15:02.079 So let's say if you start at some point of time acquiring companies at Endor, you would follow some of these principles. 01:15:02.399 --> 01:15:03.199 Yeah, I think so. 01:15:03.760 --> 01:15:04.319 Totally. 01:15:06.640 --> 01:15:09.600 Now, you know, one liner's question on rapid fire. 01:15:10.000 --> 01:15:13.359 What's one thing about AI you have changed your mind this year? 01:15:16.640 --> 01:15:26.000 Um it's more real and more impactful than you know the pessimist side of me wanted to believe. 01:15:26.640 --> 01:15:28.960 Three AI tools that you are using right now. 01:15:30.000 --> 01:15:33.520 Um Claud Code, of course. 01:15:33.760 --> 01:15:36.640 Um also codecs. 01:15:36.960 --> 01:15:48.960 And um we have a new tool we use in marketing that is showing very promising results, which is called AirOps. 01:15:49.920 --> 01:15:54.079 One interesting GTM hack that we never discussed during the podcast. 01:15:54.800 --> 01:15:59.920 I think I think it's just as a founder, you never get away from being the best sales development rep in the company. 01:16:01.279 --> 01:16:06.560 Uh founder, slash operator or slash investor, you wish that could be part of your team. 01:16:06.880 --> 01:16:09.119 I think Nikesh is phenomenal, as I said, right? 01:16:09.199 --> 01:16:11.760 Like I think his instincts on some things are incredible. 01:16:12.159 --> 01:16:12.319 God. 01:16:12.800 --> 01:16:15.199 A book that you would recommend for every founder? 01:16:16.000 --> 01:16:18.239 Uh I'm not a big book by book guy. 01:16:18.720 --> 01:16:20.720 Or a podcast or anything. 01:16:22.560 --> 01:16:27.439 I think in the AI world right now, I'm I was very skeptical about the all in podcast. 01:16:27.520 --> 01:16:35.119 And I think now and now recently there's just more insightful things coming out of there about just as a business, as regulation, as macro to think about. 01:16:35.199 --> 01:16:39.119 So all in podcast is kind of back on the top of my list again. 01:16:39.359 --> 01:16:40.399 Well, thank you so much, Varon. 01:16:40.560 --> 01:16:42.159 I enjoyed a lot this conversation with you. 01:16:42.479 --> 01:16:43.199 I learned a lot. 01:16:43.680 --> 01:16:44.880 Thank you so much for having me. 01:16:45.119 --> 01:16:45.840 It's been a pleasure. 01:16:46.000 --> 01:16:46.560 Thank you so much. 01:16:47.039 --> 01:16:47.600 Awesome.