01:03:52 · Siddhartha Ahluwalia, Varun Badhwar
[01:03:52] S1: But but your agents are always watching the AI coding agents, whatever they be. Yes. [01:03:59] S0: 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. So when Claude is iterating on your spec and writing the code, Claude's job is not done till it has gone through Endor 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] S1: So whose responsibility is that uh the Endor's plan is executed? Is it Claude's responsibility? Is it Endor's responsibility? [01:04:46] S0: Uh it's a it's a shared responsibility. It's the way you um insert the product into the workflow. 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. And so using those things, specifically, uh Claude has something called Claude Hooks. You can actually mandate deterministically that Claude has to abide by the instructions of Endor. So that's how it works. We use their configurations to put ourselves in the workflow. [01:05:22] S1: So does Endor today become like a firewall, like omnipresent and um there are components of it that does.
01:05:22 · Siddhartha Ahluwalia, Varun Badhwar
[01:05:22] S1: So does Endor today become like a firewall, like omnipresent and um there are components of it that does. [01:05:32] S0: Actually, it's interesting you bring up the word firewall. With malicious open source, right? I told you this is free for all. 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. They are not real names, they're not real versions, or they're pulling really outdated stuff. So if you think about the Firewall concept. 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. We actually call it a package firewall. So in some use cases, yes. But I think firewall also annotates a slightly different meaning to me, which in package firewall case is like a yes-no. It's a guard at the gate. We're not just a guard at the gate that is one use case. It's also we're the fitness trainer, we're teaching that agents how to write more secure code for you. We are your house manager, right? 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. So I think it's all of the above, right? We we want to run your house as effectively as you can. So we're a house manager, we're a cleaner, we're a security guard, all of that.
01:07:05 · Siddhartha Ahluwalia
[01:07:05] S1: 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. Like only one by three, one out of three LOI LOIs get converted into. Yeah.
01:07:39 · Varun Badhwar
[01:07:39] S0: I think we can probably record a whole podcast on this topic. Um in a rapid fire style, no particular order, I'll I'll share a few things. 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. And I say, like, you're building for the wrong reasons then. Um, your job is to be bought, not to sell. And in order to do that, you have to be in a position of strength. In order to be in a position of strength, you don't think about and build a company to get acquired. You build it to be the best or the second best at worst case in whatever problem you're solving. So I think that's one thing for me. The second thing is these relationships start long before transactions. 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. 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. So that value and engagement needs to start way before, months to years before a potential acquisition. Because you want to show, like, this is so obvious. Like, why aren't we doing more of this? Um, most acquisitions also fail. Like, I think you talked about the LOI rate. I would say 90% of the acquisitions probably fail post-closing if just like didn't deliver the promise. 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. There's 500 people from this company I acquired. I'm a 5,000-person company, so guess what? The hundred engineers will go into my 2,000-person engineering org. And the 50 sellers will go into my thousand-person sales org. And you know, and you just break the entire culture of the company. And you'll usually put them under a GM of a business that likely has failed to solve this problem internally. Because if they hadn't, you would have not gone out and acquired a company. If you could have done it better, you would have.
01:09:53 · Varun Badhwar, Siddhartha Ahluwalia
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. And now you'll put this founder and this company under this individual. And I think all of that is so wrong. 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. And you shouldn't, on day one, split it up and break it. Maybe there's a day and time to do that. 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. The second thing is there's something to be said about the founder hustle and the founder mindset. And like there's instincts, there's a reason you were successful and the big company wasn't. And so I think you have to be very careful in the dynamics of who's leading what part of the business. 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. 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] S1: So, so in your case, did you have a relationship with Palo Alto much before the acquisition happened?
01:11:17 · Siddhartha Ahluwalia, Varun Badhwar
[01:11:17] S1: So, so in your case, did you have a relationship with Palo Alto much before the acquisition happened? [01:11:23] S0: 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. So, so no, we didn't have a actually my whole most of my rule on that one failed. That was just a very unconventional um acquisition, to be honest. [01:11:40] S1: So, why did they they they buy RedLock when they had already bought the computer? [01:11:46] S0: Uh because we were kicking their butt in the field. Like we were we were a better long-term architecture that was multi-cloud. Um and and frankly, I think that was one of the core pieces of like our architecture was much more extensible. Like you could build, sell, and scale a lot more capabilities on the uh Redlock architecture than the evident I.O. architecture. I would say that's probably where it came down to the most. And of course, the results in the field. Like Palo Alto customers were preferring Redlock. [01:12:26] S1: So they were hearing from their customers. I think that's the best way. [01:12:30] S0: That's right. [01:12:30] S1: 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] S0: Yeah. [01:12:36] S1: With only $10 million raised. [01:12:38] S0: Yes. [01:12:38] S1: But today Palo Alto is a very different beast from that point in time, right? [01:12:44] S0: Yes.