00:51:03 · Siddhartha Ahluwalia, Varun Badhwar
[00:51:03] S1: 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] S0: Yeah, I think it comes down to the metrics of what what matters to you. It was the example I was giving you on cost efficiency. What matters to the CTO is can they move fast and can they ship fast? No CTO in the world wants to ship an unsafe application, but that's not the core metric. Like I don't know too many engineering teams that are obsessing about security, they're obsessing about speed and quality. And so for us, it's like we always think about Endor and our products called ORE, our platform, eugenic platform. Even actually, the icon of ORE is a bridge. And that's supposed to be a bridge between security and engineering team. Security wants to move fast, we need to give them the tools to move. Uh sorry, engineering needs to move fast, we need to give them the tools to move fast. Security needs to move safe, we need to give them the tools to move safe. The connective tissue is the developers should never get out of their workflow and should have minimal interrupts. So Endor runs where the developers are. Security gets the report where they want it, and that's how we design our interfaces of our product. [00:52:12] S1: 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 · Varun Badhwar
[00:52:20] S0: Um maybe let's actually I want to start with some of the going right versus going wrong dating back to my first startup. Because I think it's you know learnings have begun from there. Um as I kind of touched on briefly before, I have come to realize and appreciate just how important having the right talent is. At CipherCloud, our first company, uh, my co-founder CEO was self-funding a lot of that. And so I think initially, as a self-funded company, we're scrappy about talent. There's a lot of good talent, but very young, early in career talent. And we didn't round that up with the right mix of uh seniority and experience. And I think long term there was just a lot of technical debt in that architecture and that platform. 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. So I think that was kind of one of my learnings from there was the quality of talent. I'd rather have fewer people than like earlier and cheaper. Um and I think today, though, that's become easier because you just don't need the same volume of people with AI. You can do a lot more with fewer people. So that was kind of one there. At Redlock, um, one of my big learnings was like when you hire salespeople, hire in pairs. What I mean by that is oftentimes people will be like, oh, I'm hiring my first salesperson. And I always say when you're hiring the first salespeople, what first person, what territory are you gonna put them in? Right, how people on the west coast of US Buy is very different from how people on the east coast of US buy. Uh also, what background do you want somebody to be? Uh, do you want a startup background or is a large company background okay? So, you know, the individual's background matters. 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. And if it's not working, is the problem that individual? Is it the accounts you're targeting or your um product? And so at Redlock, I originally started with that following that principle of higher-end pairs. I hired two people, and I'm so grateful I did. I put one person in California, one person in New York.
00:54:50 · Varun Badhwar
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. The person on the west was just scrappy. 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. 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. The reality was we had not built the wrong product, we had built the right product. 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. And that's very hard to tell. 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? Are they ready and and willing and understanding of what it takes to be in a startup? 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. Because a lot of times we want that brand, right? I want to be able to go to an investor and say, look, I have five engineers from Meta. 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 · Siddhartha Ahluwalia, Varun Badhwar
[00:56:31] S1: And what do you say in Endor, finding product market fit is as hard as Redlock? Or has it become easier also as like a third-time founder? [00:56:40] S0: I wouldn't say it's easier. I think it's also not a fair comparison because um red lock was a market creation moment. We were creating a new category of products to solve a new pain. At Endor, we have been creating a new architecture and paradigm, an entirely new way of solving an age-old problem. It's almost like we at Redlock, we were inventing cars. Cars didn't exist. At Endor, we are moving from gasoline to electric cars. 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. So I think there's a completely different structure of how to compare a market creation versus a market disruption. Um, so that's kind of why I don't think it's a fair comparison. [00:57:44] S1: Got but has it been easier or more difficult? What would you say?
00:57:47 · Varun Badhwar
[00:57:47] S0: It's been different. And I say that because when when you are creating a category, there's no incumbency. So whatever you define either solves the problem or doesn't. 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. 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. The thing that then shifted and put this into hyperdrive for Endor was when AI coding came along. 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. The AI coding agent disrupted entirely what a workflow looks like, what an agentic STLC, how you create software. It completely disrupted this whole idea of, you know, today we're identifying 16 times more vulnerabilities than we can fix. That gap has widened more in the last year than it has in the last 10 years. That pain didn't exist for the last 10 years. 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 · Siddhartha Ahluwalia, Varun Badhwar
[00:59:26] S1: 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] S0: Easily, yes. Because I think the linear formula would say that. It's not just you're creating more software, you're also creating them at a more faster pace. The other challenge, I was with a CIO of a very large entertainment company. And he said, Varun, look, my problem is not just I have citizen developers. My finance team is building a forecasting app. And we happened to go analyze that code, we found a security bug. We emailed the individual who is writing that code, and we said, Here, could you please fix this vulnerability? Do you want to guess what the response of that individual was to the security team? [01:00:25] S1: I didn't create it. The agent created it. So please ask me.