Alrighty then, ladies and gentlemen, welcome back to another episode of Privacy Please. I'm Cameron Ivey alongside my friend Gabe Gums. And Gabe, we got a we got a special guest today. I'm pretty excited about this one.
SPEAKER_02We've got a great guest today. We promised at the top of the year that we were gonna unveil a couple of really exciting um folks out in the industry. And we've got our first one on today's show.
Yeah, we got uh Girish. Girish, thanks for so much for the time, first of all, for joining the show. Really appreciate it, and we're excited to understand where you came from and how you got to where you are today. So I don't want to like steal too much time. I'll just kind of let you open the floor and kind of tell us a little bit about yourself.
SPEAKER_00Thanks, Cameron. Thanks, Cape. Uh, thanks for the warm welcome, and I'm excited to be here as well. Uh, thanks for having me. So, yeah, a little bit about me. I'm Guriesh. I'm uh one of the co-founders and also the CEO of a company called Sprinto. At Sprinto, our goal is to help other companies build trust with their stakeholders. And I specifically mean trust with respect to the security and privacy. You know, fundamentally, um, you know, every business that exists out in the world, in some way or the other, depends on other businesses to run its operations, and that dependency has a digital trail. And what's becoming increasingly important that let's say I as a company am dealing with you, Cameron, or with you, Gabe. And if I have a digital trail with you, I want to make sure that uh, you know, you give me certain assurances about the fact that you're going to treat the data that I share with you with safety, with security, and with privacy. And we're in the business of helping companies make sure that they can have the right practices and also be able to showcase the fact that they have right practices so that it reduces the friction in these con uh in these transactions that happen between businesses. So if we do our job well, uh, we actually believe we'll increase the GDP of B2B commerce. Uh, that sounds lofty, but that's exactly what we go after. Um, and personally, about me, I'm a programmer first. I'm happiest when I'm writing code and building product. Though as the company grows, I admittedly get to do less and less of that. But that's where I'm most comfortable at. Uh, Sprinto isn't my first startup. I did a startup before this. And funny, it was during the course of growing that startup that uh I landed on the problem that we solved today. Uh, you know, as an engineer, I was trying to build a security and privacy program. Long story short, I hated the way it works. Uh, thought there should be a better way of making that happen. And that was kind of the germination of Sprinto. So that's a little bit about me and the company, but happy to answer more questions as we as we go along.
You know, Guresh, you've got a very interesting and story background. And in particular, I really want to dive into a bit about what you've seen firsthand in the difference between what it means to pass a SOC2 or an ISO audit and how that compares to actually being secure. I think one of the things that the trust that you build up between organizations is exactly that, right? Like not just saying it, not just talking the talk, but walking the walk. But before we get there, I'm always fascinated when I speak to founders like yourself, technical founders, that love to be hands-on keyboard. And I've I've gone through some of this growth, call it uh an emotional struggle sometimes where you you find yourself getting further away from the technology as the company grows. Tell me though, what's that journey in particular been for you as that company has grown? And specifically, because AI is such a hot topic these days, has it allowed you to get a better balance of being able to still code, right? Do the things that that really just bring you joy while also being able to run a business?
SPEAKER_00Yeah, I think uh what you said at the end is exactly right. Uh, you know, AI has sort of produced the barrier of what it actually takes to do something productive, even in a company that has like uh, you know, massive code base that runs into millions of lines of code. So there was a point in time where I was actually scared of contributing anything to the company code in the with the fear that I might actually break something because uh you know the the software has grown to a size where it can't where I can't hold it in my hand anymore. And you have like a bunch of checks and balances to make sure we we ship something right. And so the the uh the the time cycle between you actually thinking about something and working on it and and actually making it production ready just keeps on having more and more steps in between. And that is kind of frustrating. Uh, what AI has done is that it has compressed that a lot. So now uh you know, I'm again in a zone where I can actually contribute meaningfully or at least uh do some side projects that can attach to our main code base, but it it actually has given back the joy of actually doing something that would otherwise seem uh you know a little daunting. So I, my co-founder and the gentleman who currently uh heads by engineering, we wrote most of the early code at Sprinto. But as a company grow, we sort of grew farther and farther away from the actual code that's been written and sort of get drowned into more of the operational aspects of running a business. But yeah, AI has actually made it more accessible. You know, it just uh allows us to sort of get back our hands on the keyboard on more than sending emails and drafting spreadsheets, but actually writing code again.
Right on, right on. So let me bring that full circle to kind of what your organization does. And one of the things that comes up in a lot of my conversations is, you know, as it pertains to the frameworks that exist around security and privacy, SOC2 and ISOs, how do you see AI changing those frameworks? And how do we still maintain trust between organizations as they essentially implement things that some people might think of as a black bar? Yeah.
I think the second part of what you said is really important. Think of compliance with certain frameworks more as a way of saying that there are certain practices at the bare minimum that you have in place. But the existence of those practices doesn't necessarily mean that you're completely safe or secure. It's definitely better than not having anything. It does give a certain degree of comfort, uh, but it doesn't go the entire way. So compliance doesn't necessarily mean trust. Uh, and I think the simplest analogy of this is uh, you know, uh you could be a straight A student and you have like high SAT scores, but that doesn't necessarily mean that uh, you know, you understand the topic. You can actually implement it in a real one. That's the difference between being compliant and actually being uh you know trustworthy to work with. Uh A doesn't imply B. It's it's a good stepping stone towards it, but it doesn't mean the entire thing as well. So I think what tends to happen as companies mature is your first goal is typically that, hey, can I at least do the baseline things, the foundational things that are important uh in order for me to be um uh in order for me to have some sort of a formal security and privacy program. And I think that's baseline, that's foundational, that's important. Uh, you can't go from where you are to where you want to be without passing that step. And you of course get an additional advantage that uh, you know, these are some industry recognized practices. So once you do them, you get the benefit of them. It helps you build trust with your customers along that. But that's the beginning and not the end of it all. So as companies grow more mature, they start asking a question about hey, I run these practices and I'm able to prove out these practices every time somebody looks at me. But what would it mean for me to be able to run these practices irrespective of somebody's looking at you? So that's the next step that companies go to, which is what we call as continuous compliance, in the sense that, hey, the fact that somebody's looking at you is just incidental. You you're running these anyway. It doesn't matter whether somebody looks at you or not. And so an audit or uh or due diligence that happens by a customer is just business as usual. It doesn't even clock as a blip on your radar, it's it's something that's that's completely fine. And then you go on from there to basically getting to a stage where, hey, I'm running all of these practices, uh, but can I actually stop bad things from happening? Uh, which requires you to go like another step ahead, which is saying that, hey, uh I'm I'm sort of uh avoiding bad things from happening. I sort of have all of these right things in place, but can I sort of uh foresee some of these things? Can I stop them in tracks? And if they do happen, do I have the right uh mechanisms to be able to react to it? Uh and and that is what basically what we call as resilience, uh, which is fundamentally a way of saying that hey, I can avoid bad things from happening in the first place, but if they do happen, I have like shorter reaction cycles and I know how to do that, and you sort of become stronger as a business. So you go from a point where you did the foundational stuff to a point where you actually doing the things irrespective of who's looking at you, to a place where you're actually stopping bad things from happening. And every company sort of goes through this cycle. It is a long trust, isn't a on-off switch, or it's it's not like you're whether you're trustworthy or not. There's a spectrum, and as a company grows and has more resources to sort of spend on this, and as it becomes more and more important for a business to lie on the right hand side of this spectrum than on the left-hand side, we see naturally companies go in that direction. And that's what we support companies to do. You know, you get started here, but you go the full mile, you know, but you need to.
SPEAKER_02I love your statement about resilience. I love it for a particular reason. I'm a hacker by trade. I break things for a living. When I'm not breaking things, I'm helping other people make their environment resilient because ultimately, in all of my years of being an ethical hacker, I haven't found many things that I can't break. Or someone else can't break. And so you'd mentioned offline that you know you found it's been to after realizing that compliance was essentially broken at its core somewhere, right? Like along the way. What did you observe that made you come to that realization?
So I'll share a little bit about specifically how my experience was. We had to become compliant with a couple of frameworks like SOC2 and ISOCRINES and Tabson 1. Uh the first place where there was a problem was that these seemed like walls of text that was just undecipherable for a normal human. Like I could read it, but I couldn't make sense of what it means for my business. What do I really need to do? So translating something like a framework to what I need to do on the ground as a business. Like, what do I really need to do? Do I need to make sure that my employee laptops are safe? If yes, how? What specifically do I need to do? Do I need to do something on my AWS environment? If yes, what? Do I need to change some of my employee onboarding and offboarding practices? If yes, what? And it just seems like a lot of degrees of freedom, a lot of opinions, and just uh, you know, uh nobody quite sure what exactly needs to be done. Very subjective. It was very subjective, and and the the honest truth is that uh, you know, a technology startup looks very different internally than let's say a services company, which would look very different from a manufacturing company. And these these frameworks are written in a manner that they're universal. Like you could take them and apply them in any context, and and therein lies part of the problem because then you don't know what it means for me specifically. And somebody needs to do that. And what we had to do at the time was we we hired a consultant to help us sort of make sense of it all. Uh, the second problem that was there is even if you did understand what needs to happen, uh actually doing it seemed like a lot of manual work. Uh so uh the people were supposed to actually audit you. Uh, they're literally at the end of the day, proving to them that you're doing the right thing was about passing pieces of paper, uh, a screenshot, a spreadsheet, uh a PDF, and and you literally like uh doing the right thing was one part. Uh, but then uh, you know, after doing that, taking evidence of all of that and then then showing it to them, and and they may or may not get what they want, which means they come back to you and then you're doing that whole thing again. By the time this whole cycle is over, sometimes it becomes stale, and and you're you you know you're back at the horse again and you have to start the whole thing again. It just seemed like you know, um, knowing what to do was a problem, then doing the thing itself was a problem, and then proving that you did the right thing itself was another problem. It just seemed to be a lot of just manual busy work, and that didn't sit right with me. It seemed like the important thing was to do to do the right thing. Everything else just sort of automatically falls into place, and especially as a as a young startup, where by definition you have very few resources uh as compared to large companies, and and you really got to pick your battles to fight. This seemed like something where uh you know you were just spending a lot of time and energy and effort and not much coming out of it. Long story short, we spent, I think, more than six months and tens of thousands of dollars uh in this entire exercise. You know, we barely got through. And it just seemed like uh, hey, if we had to do this again next year and year and year after, this was just going to be untenable. It didn't seem like a right way of running the process. It just was barely put together thing with the duct tape and and it would just collapse at any moment.
SPEAKER_02Yeah. So you point out that compliance and audits tend to be this point-in-time documentation exercise, the way I understand it from what you just described there. And I'd agree with that. They do often feel like that. I I personally go through one myself, right? Through it at a regular basis. Our organization is SOC2 compliant, and we too have to go through what is essentially a very heavy documentation process. We have a number of practices, because we are a security organization, where I feel that we have an advantage over folks that, you know, maybe it's not intrinsic to their business, but it's not intrinsic to most businesses. So, how do you take someone from a point-in-time documentation exercise to something that is meaningful, to something that you can trust?
Actually, uh, that's a great question. And uh, this is what we spent uh most amount of time figuring out as a company. Uh, for context, uh, one of the favorite pastimes that we did at the beginning of Sprinter was we used to just go to auditors and say, hey, auditors. And uh we were building a product along the way. So we got audited about a dozen times, and every time we were sort of dark fooding a product to understand how this actually works. Uh, but I think there are fundamentally three things that you need to do right uh in order to sort of go from a place where this becomes like a point-in-time document-based exercise to something that's just the way your business runs. The first thing that uh you need to be able to do well is map your program to the actual realities of your environment. Every business is very different internally, even though let's say the company that you work at and I work at are both technology companies. I'm pretty sure there are like many differences underneath about the way we use certain tools, what do we use them for? The business processes we have. Maybe we have some employees that are completely remote, some of them are on site, maybe a hybrid situation. And a bunch of these business realities have implications on what your program ought to be. Um, and the most important thing to realize is that it's not just about knowing what your program is today, your business realities are changing over time. So you might be using, I don't know, let's say you're on AWS today and you realize that some part of your organization needs to ship a new product, or you realize that some service extra needs to be on Azure tomorrow. You started that service. How does your compliance program know and the auditor know that this change happened? Your program could be in a completely different planet as compared to your business realities. And the the the first problem that you need to solve is how do you sort of make sure that your program evolves as your business evolves? And how do you even set up your program in the first place, which are which is true with your aligned with your business practices? And our approach for that at Sprint is to make sure that we talk to your underlying systems instead of depending on humans to tell us this happens. So, for example, when Sprinto connects with a bunch of underlying systems, uh, we'll talk to uh AWS and Azure and all the services that you might be using. And that's when you start picking up breadcrumbs of hey, something's changed in your environment. A new person joined your company, we'll see a trace of that in your HRMS system. Um, you started using a new service on AWS. We start seeing that within your AWS, and we can ask you, hey, by the way, I see this. Is this part of your program? What are you using this for? And the program sort of evolves on top of that. That's step number one. Uh, step number two, you need to make sure that uh whatever you are uh, whatever changes that happen to your environment, they uh to be just helping you point out the gaps on a continuous basis. It doesn't require a human to look at something, look at a database and say, hey, this doesn't look like it's encrypted and we it should be. This doesn't look like it's been backed up, but it should be. This is all happening programmatically in SprintO. So Sprintto is sort of encoding all the rules that you need to adhere to and automatically and continuously measuring those for you without a human having to uh be in the loop at all. Uh, so you're across all the all the entities in your environment that have an implication to your program, directly or indirectly, people, servers, machines, uh, code repositories, whatever you have, Sprinto is continuously monitoring them and telling you that, hey, this is where this thing seems to be out of compliance or it seems to be out of where it's supposed to be. And we're telling you that. Uh, number three, we're not just telling you this is a problem. Uh I think uh one of the common gripes I have with a lot of software is that they just create more homework for humans to do. Uh uh and uh then it sort of becomes this game where it's humans feeding the software rather than the other way around. Um, so we we're not just uh tell you where the gaps are, we actually go the one step ahead and tell you how you can fix those gaps. And in some cases, we have actually have agents that actually fix those gaps for you as well. So do that. And the last bit, which is uh after doing all of this, we also help you get all of that data, all of the evidence that SprintOS collected behind the scenes in order to do this in a manner that the auditor will be happy with it. Because at the end of the day, there's a human at the other end who's looking at all of this and saying everything is okay, not okay, et cetera, et cetera. But this again should not be a human process. So it's it sort of automatically collects all of these things, puts it in the right format that the auditor can look at it so that they actually can do the job better rather than doing all the chasing around saying that, hey, I don't have this document, this doesn't seem right, you need to rework this, etc. etc. They can actually spend the time on looking at the data and saying that, okay, this looks good, this looks good, this looks good, and so on. In fact, one of the most common things that we see with our auditors is that um if the amount of time that they actually spend on an audit is about 10% of what it would be if they were not using something like Sprinter. And the reason that happens is because 90% of the time is just chasing people and documents. The 10% is the actual value adding time. The the everything else is just uh you know busy work that happens around it. So that's fundamentally how we work our data at the sprinter. Interesting.
SPEAKER_02One more question, and I promise I'll I'll I'll I'll let Cam get in there. I have a bad habit sometimes of just No, let me let me jump in. Yeah, you go, you go. Well, just one more. This one's a thought exercise. We're gonna resurrect. Cam probably knows where I'm going. It's an old thought exercise that we like to ask guests on the show, right? But startups do have they have this intrinsic challenge of there's a limited amount of resources, namely time and money, and there are very lofty goals to be reached. And so you really have to, it is a constant battle every second of the day to bounce those things. So here's the thought exercise. You've got a hundred bucks. 100. That's all you've got. If the only you had was a hundred dollars, what would you use it for to move the needle in moving away from a simple point-in-time documentation exercise to something more meaningful? That's it. 100 bucks. It's a hypothetical. In the real world, of course, one would expect that 100 bucks is uh is not really much to do anything, but that's it. I've got a hundred dollars. What do I do?
SPEAKER_00Um actually, uh if you had a hundred dollars a month, let's assume that. I'm just gonna stand that a little bit.
SPEAKER_02Yeah, every everything is subscription based nowadays. I love that. Guriff just turned it into$1200. Go.
All right. Um, I think the most important thing that I'll do over there is uh, you know, spend 80 of those hundred bucks and just uh making sure um whatever it is that I do at a point in time, um, can I just automate that bit? Uh I don't care whether you use something like Sprinter, you use Cloud Code and sort of build your own version of it together, uh, or or just uh you know, in whatever manner that's possible for you. Uh and I think the the most important chasm to jump over is that this this doesn't require humans. You you said that uh you said a very important point. I think the the toughest battle for a startup to fight is which battle to pick. There are always a hundred things that go wrong, which is the one that I fix right now. And it's a hundred competing for that hundred bucks. Yes. And I think that the simplest way I look at this is that I I look at doing compliance well as not as a back office operation, but something that actually helps you win more customers. So this to me competes with, let's say, your advertising budget. Because what you don't want to happen is what you want. Like what what I've really seen companies do well is like when they actually do the programs well, they put it front and center on the sales tech. So you're you're saying upfront, not at a later point in your sales cycle, saying that, hey, by the way, you know, we we do right by your data, but it's it's upfront front and center on your on your sales. Stack where you're saying that hey, uh you know, we treat your data as a first-class citizen, we're going to make it secure and private. Here's what we do for it, and and you should be able to make that claim so that this doesn't become uh something that you're just playing defensively, like you can play offensively on that. And so I I personally uh I've seen like some of the best startups treat this as like the ad budget rather than thinking of this as a back office budget and just saving time and money. So that's the that's mentorship that I do, and then spend all of that money, at least 80% of that money, in just uh you know automating this. I don't care how you do it, but but at least as a as a technology startup, where the simplest way to think about it is engineering resources are the most most valuable commodity inside of your company. If that's the goal, then I'd try to say how much of that engineering resources are being spent on compliance today and just get it down to zero. They should be building product for your business, not worrying about all of these things. This should just happen for you.
SPEAKER_01Right on. That's really good. I'm very intrigued so far. I have so many questions, but I want to kind of keep hitting on where we're at, and maybe you've already given an example of this, but let's put let's put the mindset, and I'm sure most of us here deal with, at least you two deal with uh CISOs and CIOs when it comes to purchasing security or even privacy software. They're usually the ones that uh give the green light and say yes. This is for the CISO listening too. How do you move a CISO's mindset from let's get a PDF for the sales team and to let's use this framework to actually harden the infrastructure? Does that make sense?
Yeah, I think that's uh that that's a very important point, Cal. And I think uh, which is again goes through the three stages of maturity that I talked about. Uh whether you're a CISO or uh, you know, or or somebody who's just like at a senior position in the organization, you sort of climb the Maslow's hierarchy of needs in a way, like in the sense that at the base minimum, what you want to be able to do is arm your sales folks with whatever's necessary for them to build confidence. So that's that's what you need to do. But you do need to go to the next level. And the reason you need to do that is you and your competition and everybody is doing the same thing. And what is, in spite of you just being subto-compliant, I've seen many companies still spend weeks and weeks in proving that to their customers. So let's say you're suck to compliant, but it's it's rarely that here you show your SOC2 certificate and the company on the other side is, yeah, this looks okay. And what ends up happening is they still send you a security questionnaire that goes into you know hundreds, if not thousands of questions. I've been at the receiving end of some of those. I wouldn't wish them one of my worst enemies, but that's a reality of the space. That happens. And then tomorrow, God forbid, there is a there's a preach, your name is in the papers for the wrong reasons, uh, and that's such an erosion of trust. And you know, there's there's basically uh such a large amount of problems that happen as a result of that. So I think um as a as a CISO, uh they're they're reasonably aware that the job isn't just to get a rubber stamp, uh, but the job is to actually make the business more uh more resilient uh and be able to actually prove the fact that they're becoming more resilient to their customers as well. So I think uh what the really good CISOs are good at is when they make this jump in maturity from being just compliant to being more resilient, they're actually able to sell the fact that they are more resilient to their customers as well. So just not like, hey, I'm just doing this for internal hygiene reasons or because I'm the good guy and I believe in doing the right thing, but they're actually able to prove to their customers that, hey, by the way, uh we and a bunch of our competitors are all going to tell you that he are software compliant, but by the way, these are the actual things that we do over and over what compliance needs us to do to actually take care of the data. And here's a proof points to prove how. And when I was saying that these things eventually make it to your sales tech or they make it publicly on your website, that goes a long way uh in actually how can you win more businesses. So, in fact, uh really great CSOs are uh, you know, they think about their trust posture as a marketable asset and not just something that helps you check a box. And you're now thinking and you're flipping your brain in a manner that you're thinking about this is a this is something that actually helps me get more leads. It is actually something that actually helps me expedite my sales cycle. So they're actually thinking from a revenue standpoint and not just from a standpoint of hey, it helps me check the box and we are good over there. So thinking contracting the revenue cycle, they're thinking building more trust, and and that's the language that good CISOs are able to use. I think it was the Levi's CISO, Steve Zaleski, if I remember his name, right, who first framed this phrase that he he basically said, how does this help me sell more genes? Uh and his idea about is like I I could do anything within my organization, within my CISO organization. If I can't answer this question, you know, it's it's not useful for my board. So when I'm going to my CEO, when I'm going to my board and then talking about this, what I really need to answer in one way or the other is how does this help me sell more genes? And I think that's a that's an incredibly simple and powerful way of thinking about it. So when a CISO goes from you know meeting compliance to becoming more resilient, how does it help me sell more genes? Uh and a CISO needs to answer that. And there are many ways that CISOs are answering that. In fact, one of the things that we do at Sprinto is to be able to arm the CISOs with uh a bunch of things that helps them position and answer this question for their business.
SPEAKER_01Love that. You said you said sell more genes. Yes, fully wise. Yeah, as long as your butt looks good and if everybody's butt can look good enough, that's gonna sell more genes for sure. You haven't seen my butt. Jeans aren't gonna help. That's uh thanks for going into that. That was that was helpful for me. Okay, so we real quick, there's there's the term technical debt. Have we ever heard of something called like compliance debt? Is there such a thing? What what does that mean? What what's uh how do we kind of not get there? Like, do companies really fake it for years and years?
So uh it's a very real term, uh, and I don't think it necessarily happens because of companies faking it or because of bad intentions. Uh, but I think uh the reality is that the business runs at a certain speed, which is dictated by their environment, the competition, the the revenue needs to go at a certain pace, etc. And compliance is traditionally seen as the folks as a department of no. They're always saying, Don't do this, this is wrong, this is banned. And you know what happens as a result is the business eventually finds a way to circumvent it. Like you start doing things without asking or without necessarily ratifying and yes, compliance uh deck happens despite best intentions rather than somebody having any having any malintent, in all honesty. Uh, I'm sure there are cases where uh the opposite is true as well. But in in majority of the cases that I've actually seen is that everybody means well, uh, but the fact is that the business runs at a certain pace, uh, and compliance isn't just uh you know fast enough to catch up. And that's because of a bunch of things that I said. Your program is manually run, it's point in time, it's it's it's it's sort of uh divorced from the the business realities that you're happening, and your business realities are changing at such a pace that compliance never got a chance to keep up, and now you're like on just different planets. And uh the only way, uh especially as we move into a world where AI is a reality, and what that is only gonna mean is that the amount of software, whether it's built by the business internally or it's it's sort of bought externally, the amount of software that a business is going to use, it's just going to massively and exponentially increase. And what that means is the the gap between the speed at which the business runs and the compliance runs is only going to get wider. So if you don't move to a place where your compliance is sort of in sync with the business, it is allows it to run at the same pace, where uh you know different business leaders start looking at compliance as not a way for uh, you know, uh for that that stops them from doing what they really want to do, but it's sort of a way that it actually supports what they're doing. This is this gap is only going to get wider. And uh I think one of the flips that uh really good CISOs uh are able to do is they're able to sort of position themselves as somebody who helps the business rather than the department of no. That's a that's a simplest way to think about it. The most common experience that everybody has with the compliance department is the department of no. All they seem to do is say, don't do this, this is wrong, uh, this requires this additional thing. They keep coming back to us for some documentation, etc. So the compliance has to work in a manner where it just happens behind the scenes for you rather than you having to do something specifically for it. I think most people in the company want to do the right thing. What they don't want to do is the overhead that comes with doing the right thing, which is if if I'm a person uh who runs the HR department or I'm running the customer service department, et cetera, I would like to do the right thing. What I don't want is everybody to do, spend 20% of the time filing the right pieces of paper so that you know the compliance team gets what they want. So if the compliance team can get what they want, while the business functions do what they need to do, everybody's aligned, everybody's on the same page. And that's the only way to deal with the world which is going to be AI first. Otherwise, this gap just gets wider and wider until it sort of becomes like termites in a house, where until you figure it out, it's too late. Uh you know, you sort of shook the foundation.
SPEAKER_01So you have you have a unique perspective going back to your first startup, or I don't maybe you had other startups, but recruiter box, you you were able to grow over 3,500 customers. I guess I don't know if you hit the compliance wall and decided what was the turning point there that made you go to that next thing. Like you're like, I need I have this other vision for something bigger, or maybe you didn't at the time, but what was that switch there at the end of Recruiter Box?
Um, so yeah, the uh the answer, uh, to be honest, is closer to the second. It didn't occur to me at the time that, hey, I want to do a company about this. Uh, you know, as a founder, we started getting asked for compliance of the security questionnaires. I did the first thing, which was kick the can down the road as much as I could until it became like a bottleneck. At some point, it became clear that hey, we need to do this, we need to buy the bullet. And we said, okay, fine. So we hired the consultant, like I said, we went around the whole nine yards, we spent months and tens of thousands of dollars on it. We we got the compliance eventually, but just weren't happy with the entire process. And I think it was a year later or so that we successfully exited the company. Uh, you know, uh we sold it to a private equity firm. And I was uh, I and my co-founder were uh you know taking a break before deciding what to do next. And we had about three or four ideas that we thought you know we could work on. This was one of them. And I think the the most intriguing part about this idea work for us was that this is one of those boring and sexy problems that nobody wants to touch with a 10-foot pole. Uh like nobody wants to think about compliance. Uh, you know, but at the same time, it's so valuable in the sense that it actually helps unlock revenue for uh for you as a company. So it's it's one of those very unique problems in the sense that it's it's not something that somebody wakes up from the sleep and says, hey, it's an exciting problem to solve. Uh uh, neither is uh, but at the same time, it's it's it's a very valuable problem to solve. And I sort of uh I remember we what we did was uh you know we had like about 20 interviews with uh other folks uh and just trying to figure out if this is a problem that they really face or is this something that's just in our heads. Um and we realized that yes, this was a it was a common enough problem. It wasn't something that we just personally faced, it seemed seemed to be something that that others were seeing as well. And that's how we sort of slowly gathered the confidence that hey, this was something that was worth working on. So it was a rather gradual process. There wasn't like one light bulb moment where it went that, hey, there's a company here. It just happened over time.
Interesting. So one of the more fascinating things I I find about uh your organization and your background is you mentioned offline that what you guys spend over a year, year and a quarter or so, just getting audited, going through the audit process, having conversations around it before you wrote the first line of code. We wrote the first line of code. What was the primary takeaway you had from that exercise?
SPEAKER_00So here's the um I think there's some personal background to that. So I'll get to that first. Uh, you know, as an engineer, the most comfortable thing for me to do is to write code. Uh in fact, uh to an extent that it is harmful in the sense that I've been guilty of making a mistake in my previous startup. That any problem that the business had, I thought I thought I could code my way out of it. Um it was at times an excuse to not be in front of a real customer and actually understand what's what's really wrong. Uh maybe what's wrong is not a feature, but uh you know, there's a there's a way we need to change a process about how we deal with the customer or the way we actually take our product to market or how we talk about it. There were a bunch of other problems. But I I think as an engineer, I'm I'm just happiest when you know I could solve a problem by building more product. Um, and one of the uh things that I did, like I was saying, I was I had a break between uh you know selling my previous startup and and starting the next one, is we were just retrospecting on how do we do this better the next time around. And one of the promises uh sort of both I and my co-founder made to ourselves was hey, uh, you know, we're gonna do the uncomfortable thing, which is to go and talk to people, talk to businesses, understand if this is a real problem before we write a line of code. That was that was going to be like uh it's it's kind of like a pact that we made with ourselves. This is what we really wanted to do. And that's the reason why. Uh, you know, that I I think the the previous version of me, as soon as I realized that, hey, here's an interesting problem that we should go after, it would be right in front of a uh computer and they say let's let's code away. But but we said no, we're gonna actually talk to 20 people, evaluate if this is a real problem. There's a book, I don't know if you've come across it. It's called The Mom Test. Have you read it?
SPEAKER_02No, but we'll definitely put that one in the show notes. One more time. What's the name of the book? And do you happen to know the author?
SPEAKER_00I don't remember the name of the author. It's the mom test. The mom test. Yes, and it's it's quite a simple book. It's a very small book. I think it's about 7200 pages. Uh and the book is quite simply an engineer's perspective of how to interview prospective customers. And the idea and the reason the book is titled the way it is that a lot of customers or prospects, they tend to be nice to you the same way your mom would be. You're trying to do something, they all want to be encouraging, they want to be polite, and they say that, hey, this sounds like a great idea. But if you do build that and you take it to them, they won't necessarily buy that off you. So that's when the reality hits. And how do you really understand if what you're building is valuable enough before actually building that? And how you actually do this in a manner where people are not just humoring you or just being nice to you, uh, you know, to really realize that you're solving a problem. And I came across that book uh during the break, and it had a big influence on me as to how I wanted to go about solving this. So that was that was an impure. Yeah, so that was one of the um uh you know turning points in the way how I wanted to approach the business. Like I sort of did the the most comfortable thing last, which was writing code and building the product, because that I won't say it was easy, but it was still something that I backed myself to be able to do well.
SPEAKER_01Gabe, you got anything else before we head to the uh some of the fun questions?
SPEAKER_02No, no, I want to be respectful of time. This has been an amazing interview so far. I'll be honest, Gresh. I I 100% want to talk to you offline. Some of the things that you're saying resonate with me deeply for what we do as an organization. And I I want to make sure we connect after this and have a deeper conversation. But before that, you've got to get through the hot seat.
SPEAKER_01Well, well, actually, before the hot seat, uh Gresh, if there's anything that we didn't touch on about Sprinto uh that you want to talk about, anything that you want to mention, or if you just want to mention, you know, where folks can find you and find or connect with Sprento or yourself or anything like that that you want to kind of call out.
SPEAKER_00Uh yeah, I won't take much of your time, but uh quite simply we are at Sprinto.com. I am at Griesh at Sprinter.com. So very easy to remember. If there's anything you would like to check out about us or want to write to me, please feel free to free to do that. One of the things that uh we didn't necessarily talk a lot about, but I'm increasingly passionate about is we passingly mentioned about this thing about software creating more homework for humans. And I and I deeply feel that. You know, I've I've seen and used a lot of software, and then most of the times it's uh you know it feels like we are feeding the software, you're just putting things in the software in the right format, yeah, uh, and just storing it for us. And our vision with Sprinto is to make it more autonomous. And what I mean by that is that software should be doing work for you rather than the other way around. You shouldn't be working for the software, and that's something that we are uh we take very seriously at Sprinto now. You know, the leaps that have happened in AI actually enable us to build something where you could go as a company from describing business objectives that, hey, I want to become compact or I want to become more resilient. And Sprinto finds a way for you to get there rather than uh you know it just keeping on asking you that, hey, uh tell me this information, put this in this box and put this into that pigeonhole and so on and so forth, uh, which I think is an older way of doing it. So I'm really excited about you know how trust management is going to work in the future. Uh, and I believe like every company under the sun is going to need this, and the only way to make it more accessible is by making it more autonomous. Uh, you can't do that by uh saying that here's a software, here are the boxes in it, and here's what you need to feed in those boxes for me to get started.
SPEAKER_01That's great. That actually rolls into my first hot seat question, which I think you kind of answer, but this is just fun. So on a scale of one to the Terminator, how do you think AI is actually going to help with compliance, or is it just going to generate more paperwork for us in the future?
SPEAKER_00We actively working on making sure it's not more paperwork. Uh, you know, I I'd really, really hate to be in a world where it just creates more paperwork for us. If Sprinter does what it is supposed to do, uh, we should not get there. It should actually be a lot less less paperwork.
SPEAKER_01Is there one app in your phone that you use frequently or daily or weekly or whatever that you dislike? But you have to use it.
SPEAKER_00But I have to use it.
SPEAKER_02Yeah, let me just quickly alarm clock is a is a very viable answer.
SPEAKER_01That's a good one, yeah.
SPEAKER_00Yeah, that's that's probably not a bad answer. I think that in the calendar is is probably the uh the one that I use a lot. I just feel like it it could work differently, uh though I'm not really sure how. But but the way it currently works is just extremely hard. It it again leaks of the problem where it just shows you stuff and you can put stuff in the right box, but it is actually not helping you manage your day. Uh and I wish that could become a little better.
SPEAKER_01Yeah, that's a good answer. If you could uh sit down at a private dinner with any guest, any famous person, dead or alive, this really shows us who you kind of are underneath. What who would you have at that dinner with you?
SPEAKER_00Wow. Uh that's a tough one. It's tough. Right. We did see the answer is gonna be said hot. Yeah, I think the answer is gonna be somebody in the technology field. And I think, yeah, if I had to pick one in a short span of time, I I'd probably pick this guy called Rich Hickey. He is the creator of this very esoteric programming language called Clojure. Uh, and I feel like it's it's pretty much the best thing that's that a programmer has ever built. And pardon me for picking something that's uh that's that's not something that's out there in the uh, you know, as popular, but I really feel like uh he has some really, really good ideas about how software ought to get built. You know, I I've lapped up every talk that he's ever given, and he's kind of semi-retired right now or completely retired. I don't know. He's he's not really so much in the public domain, but but I would love to get an hour of his time just to riff about how to build software. What's uh you know, what does he think the future is gonna look like, especially with AI?
SPEAKER_01That's really cool. And just a coincidence, we have him on the other line. Let's bring him in. He's not he laughed.
SPEAKER_02I tell you what. I'm gonna reach out to him, see if we can't have you both back on the show. Seriously, that sounds awesome. What was his name again?
SPEAKER_00Rich Hicking? R-I-C-H-I-C-K-E.
SPEAKER_01Shout out to Rich. Okay, we'll try to we'll try to reach out to him. That's awesome. One more quick fun one before you we let you go. This is a pretty important question. We we ask a lot of our guests this. With uh in regards to toilet paper in your bathroom, is the toilet paper on the bottom or the top to grab it from?
It's it's about I don't know what you call it. Like it's it's about this height if I'm on the toilet.
SPEAKER_01Like sort of like is the is the um is the toilet paper on the top. Do you put it on the top or bottom? Like do you grab it from underneath? I have no idea, honestly. You know what? That explains Yeah, that's a good answer because it means you don't pay attention to silly things like that.
SPEAKER_02And you're obviously, you know, you're a serious uh too busy to to be that focused on whether or not the total paper is put on the right way in the role. That's good.
SPEAKER_00Yeah. No, I think uh yeah, that's that's definitely much lower in the in the hierarchy of things, including the stuff that I wear. My wife just puts those things there, I just picked what's at the top. And and that's that's what I'm waiting for today.
SPEAKER_01Well, uh Garish, this has been this has been awesome. Seriously, thank you for taking the time to join the show. Thanks for what you're doing, what you're trying to do for companies and for compliance. Uh I mean we need more companies like this. We need more, you know, founders that are passionate and also technical. Um so thanks for what you do and really appreciate you.
SPEAKER_00Thanks, Cameron. Thanks, Kate. I really enjoyed being here. Thanks, Fox. Uh it was it's really enjoyable to be here. Uh love the conversation. Thanks. Thanks for having me.