Building Glean with Arvind Jain: Scaling Enterprise Search with AI Innovation

0:00LinkedIn News.

0:30product that would actually connect with all of those systems that we had and actually make things searchable within them. I was surprised, like this is not a problem that's unique to us. That's Arvind Jain, the CEO and founder of Gleam, an innovator in the enterprise search space that is on a mission to finally unlock knowledge sharing within a company. He's talking to me about the pressing need that put him on this amazing entrepreneurial journey to build Gleam. We're going to get into that and so much more, so stick around.

1:03If you worked at a company long enough, you've definitely felt this pain. You wanted to find information that you knew existed but couldn't locate. Maybe it was the company's dental benefits policy, or the specification document your colleague wrote right before she left, or maybe even your own files. And you might have wondered, why is it so easy to find something on the internet, but so hard to find it within my own company? I've long believed that this new wave of AI will have its greatest impact actually in enterprise products, and Glean is a great example of that. That's why I'm thrilled to be speaking today with Arvind Jain, the CEO and co-founder of Glean.

1:39Glean is a search service and assistant for enterprises that allows workers to ask questions and search across the company's entire knowledge base. You could say it's like Google for enterprises, but that might be oversimplifying it. It helps retrieve and synthesize information within a company, while respecting a number of security protocols and other factors that are extremely important within an enterprise. Arvind founded Glean in 2019, with a deep background in search, having joined Google as an engineer when it was still a startup. At Google, he innovated on everything from web search to Google Maps to YouTube and more, eventually being elevated to Google's rare, distinguished engineer title.

2:19In 2014, he left to co-found Rubik, a cybersecurity company, before ultimately coming to grips with the problem that led him to found Gleam. There's a lot of interesting insights in this episode, like why he built Gleam for massive scalability right from the start, how Gleam looks at explicit and implicit signals to gauge its success, Arvind's approach for balancing scalability with customization, which most enterprise startups struggle with, and his thoughts about entrepreneurship and competition in emerging fields. Let's get into it. Before we go to Gleen, I'm curious, when you look back at your journey, what was your drive?

2:56What was your motivation? And in some way, how did it turn out differently, your journey, than what you actually expected at the beginning? I feel like that I've been really, really fortunate and have achieved more success than I ever dreamt of. It's actually interesting. When I started my career, I had this big desire to be an entrepreneur. There's something about like, you know, just my upbringing where I grew up and there was this like deep respect and fascination for people who set out on their own way. So I wanted to be an entrepreneur, but actually never became one. And I think like over time, that desire for entrepreneurship sort of actually, you know, went away to some extent and it got replaced by a desire to actually build great products with great colleagues and make an impact on the world.

3:41This was something, you know, that changed for me when I was at Google because it really gave me that opportunity to actually build something that then like, you know, every friend of yours, everybody who you know, your family, everybody uses these products. So that became a big thing for me, like, you know, build great products, make an impact to the world. Google gave me that opportunity. And then ironically, when I was not really thinking about entrepreneurship is, you know, when my entrepreneurship journey started, you know, very, it's interesting, like, you know, where life takes you. And when you think about the Glean backstory right now, like one of the reasons I enjoy working with entrepreneurs so much is that they bring this profound understanding of an unmet need.

4:17Yeah. Like when you talk with entrepreneurs about what they're building, usually there's something very specific that they feel they know really intimately. They can describe every aspect of it. And you shared once that, I'm going to quote this, I always thought that people became entrepreneurs when they encountered a problem that nagged them and that nobody else wanted to solve or knew how to solve but them. And I'm curious when you think about the insight for Glean, It came for you when you built Rubrik, but what was the insight behind it so we could understand it really, really well? Yeah. So before Glean, I was working on this startup Rubrik.

4:51In a Rubrik as a company, we grew very rapidly in about four to five years. We were more than 1 ,500 people in the company. As the company grew, we saw that we're not keeping up when it comes to productivity. In fact, you'll always see that when companies grow, that things become more complex, it takes more time to do things. Which is a common axiom, right? Like diminishing returns in a way? That's right. But I think it was stark in our case. We had actually tripled the size of our engineering team, but our commit charts were flat. And so sure, I can expect 20%, 30 % reduction in productivity, but it almost felt like there was a ceiling and we just couldn't get more work done after some time.

5:29So there was a big drop in productivity across the board, not just developers, but sales. And we used to run this pulse survey. And one of the questions in that survey was that, hey, do you have the information that you need to do your work? You know, do you have the help that you need from people inside the company to do your work? And we would score like very, very low on that question. That was one of the lowest scoring questions for us. People were complaining loud and clear that I cannot find anything in this company. I don't know where to go and look for things. And I don't know who to go and ask for help.

5:57You know, we didn't have any notion of an employee directory which described who works and what. Like, you know, like as a startup, like, you know, things just sort of come together. You know, there's a time when everybody sort of knows everyone and they know who works and what. But then like, you know, as you grow, like you certainly lose that and you haven't built any systems to make it easy for people to understand those things. So we went through that journey. And, you know, that was a pain point that I myself had. Like, you know, whenever I was looking for something, I could never find it because, you know, at Rubrik, we were using about 300 different cloud-based SaaS systems.

6:27All of our company's knowledge and data was really spread across all those systems. So very hard to sort of find things. So I saw that it's not just my problem. It's like everybody in the company is facing it. So I said, okay, let's go and solve it. This is not hard. We have knowledge across many different systems. Let's just go and buy a search engine that can actually sit on top of all of that knowledge and help people find things. And when we actually tried to go and buy a product, we realized that there's nothing to buy. There's no product that would actually connect with all of those systems that we had and actually make things searchable within them.

6:56I was surprised. This is not a problem that's unique to us. I actually talked to some of my friends who were running companies. and everybody who I would go and talk to would actually tell me the same thing that, hey, look, this is a big problem for us too. Like, you know, if you solve the problem and then come and tell us, you know, how you solved it, but nobody actually had answers for me. So that was sort of the journey that I went through. Like, you know, trying to solve this problem, I recognize that, you know, this is big. Every single person in the world has this problem and yet there are no products to buy.

7:23And that got me excited. Like, you know, I do have background in that, the search engineer, you know, I felt I could actually go and build a good product in this domain. and that's what got us started to build lean. Yes, I think in many ways, the idea of knowledge searching inside of a company is a big pain point for many. It's a constant complaint. I wonder what was the pro survey average across the industry. I'm sure it was pretty low also. But not many actually decided to go after it and try to solve it. And for you, it was a cause and effect with engineering productivity in many ways. I'm curious, did you ask yourself why would like a Google or a Microsoft not solve it?

8:01Like coming from Google, working on search, again, search enterprise, search web is very different. But when you looked at those two giants that basically have a lot of big footprint within enterprises, did you have that fast process about they cannot solve it or actually maybe they try, but they're trying to build something different? These companies, you know, they can of course go and solve this problem. In some ways, you know, the way I think about it is that they have basically pretty much more of everything than you. Like, you know, they're more engineers, they have great people, they have resources, they have the brand.

8:35It's not like, you know, whether they can build it or not. It's the question of whether they will, because they also have like a few other thousand things that they need to focus on. And at Google, like, you know, I was there for a long time and solving search for the enterprise was not, I think maybe, you know, they felt that was not a big enough opportunity or business for them. Google actually had a product, but it never worked well because we just didn't put enough, you know, R &D attention to it. but it's an interesting question like you know my learning now like you know after all these years in the industry like i've come to this conclusion that if you see a problem that is unsolved right now then you can assume that nobody else is going to solve it and that you actually have the right to go and solve it and you know achieve success with it it's just so hard to build products like it's not competition that is actually ever going to be the the reason why we buy you won't succeed.

9:26Yeah, I think you just described the entrepreneurship leap of faith kind of thing. Yeah, and there is enough opportunity. You know, think about this problem of search. I'm, you know, we're building a product that every person in every company in the world is going to benefit from. It's not the case that there's going to be one company that's going to actually serve the entire world with it. Like, you know, different people are going to have different types of needs. So you have a big space, you can actually go in, even if, you know, other people are going to come and build some products. There's also the law of large numbers, when you actually solve a new problem, you know, even if there are, you know, five other companies that are actually trying to solve the same problem, there's a very low chance that you will actually overlap at a particular customer, right?

10:06So I sort of have this firm belief, I don't think competition matters. What's more difficult is that can you actually go and build a good product? In many ways, I think this was almost like a destiny for you because we've had knowledge search products inside of our company. We tried them. They just were awful. And I think in many ways, they were trying to do a lot more. They went back to the same problem set that you went from. And instead of trying to solve that very focused in a very simple way, like Lynn is doing with a search bar, and literally, it's like it's an experience we've all learned to use.

10:39So like, we've been taught how to use search bars for such a long time with basic information. And actually just finding the artifact I need to find, they've built this kind of repositories and collaboration tools, which is fine once you solve the core problem. but you haven't solved the core problem yet as a product. So I think what in many ways was, I don't know if it feels like a destiny for you to be in that position was that I know how I can solve that core pain point. And then from there I can grow, but that core problem has to be solved for before I build some kind of complex SaaS tool on top of it.

11:13That's right. When I was asking people about Lean, one of the things that was mentioned to me was it's a rare company in the sense that it's a company that can actually scale with some of the largest enterprise customers in the world as a startup. And that was pretty unique and actually highly resonance with me because usually when startups pitch selling into LinkedIn, the biggest problem we have, even if I like the product, it doesn't scale with what we need. It doesn't scale to our solutions. And I'm just curious, what are some of the key product engineering or engineering principles you made early on to ensure the scalability?

11:47Because that sounds like a pretty big part of the success of the company. First, I would clarify that, you know, in this company, I've been less of a technologist because my role has been the CEO. So it's our team, you know, that actually does that great work. And so first, some of these things have actually become easier over time. You get a lot of great infrastructure today in these cloud environments that actually allow you to build scalable systems in a much more like easier fashion. The level of infrastructure that you start building on top of is actually taking care of a whole bunch of things for you from a fundamental platform perspective.

12:21So the design choices for us. So first, when we started out, we knew that this is a pain point that large enterprises are going to have even more than mid-sized companies. So we built with that assumption that our customer is going to be these world's largest companies. So any system that we build, make sure that you are keeping that scale requirements in mind. You know, like in search, most of us actually came from Google. Building scalable system is sort of like, you know, in the DNA because at Google, you don't get that choice. Any product that you're going to launch is going to be launched to like, you know, a billion plus people.

12:53And so scalability, in fact, I would say that, you know, our engineering team may over-index on that. They may build a system that is even more scalable than what you will have the need for in the next one or two years. And you were not worried that like that kind of emphasis on scalability will take away from seeing if this is actually a valuable product first? No, like there was a focus on scalability. But I think it's sort of inherent. Like I think when you build search systems, you just build it in a way where you know that, yes, I'm going to build it in a distributed fashion to support a larger workload, just increase the degree of parallelism.

13:23So I think it's okay. Like I think I would say like these days, because of all the great building blocks in the cloud technology systems, the experience in making the right choices, you can actually build, you know, very scalable systems from the get-go. And then from a search system, like you do have to design. So there's a very simple sort of input metric, which is how many documents should the system be able to handle? When we started out, we said that, okay, look, build a system that should be able to handle 100 million documents. And that 100 million was actually good enough for us to actually cover 90 % of the market.

13:55And so we started with that as the goal that actually allowed us to make the right choices in terms of the design of the system, our search index and other things. And then like, you know, one day, you know, we actually get a client which has 250 million documents and that's new. And so most of the things actually still continue to work because they were built with the right design in mind. But some things start to break apart. Like one of the things, for example, I'll tell you, which broke apart was, you know, within our system, we have this concept of identities and group expansion. If you imagine like in any company, you have notion of, you know, users and then groups.

14:30Groups are like a collection of people who, for example, may have permissions to certain set of documents. So typically, like, you know, you'd imagine that a company will have a thousand groups, like maybe 5 ,000 groups at max. But then we ran into a customer, you know, they had almost like a million different groups inside the company. And that sort of broke the architecture because, you know, we just fundamentally didn't conceive like, you know, why would you have more groups in the company than the number of people? And so that sort of like, you know, then puts us back on the drawing board.

14:58And like, sometimes you have to then go and re-engineer. So it's a collection of both like making some good choices from the get go. But then also as you get more and more larger customers, they sort of force you to make the system scale like even more, fix some of those things that start to become bottlenecks. That's a great insight. You know, if we go back to the end of this is very early, but still early days. I think you said once that the market was not necessarily ready for Glean. So you kind of you wanted to offer it for free at first. It's a fun story about how you use LinkedIn to do cold outreaches.

15:29Yeah. You called yourself SDR number one, self-development prep number one. Yes. And, you know, as somebody who is naturally a technologist, I wonder, what was that biggest learning for you for that early validation? Was this about craft? Was this about really understanding the problem so well before you build something? Was this about making sure that before you charge, you actually build trust with customers? What was your motivation for that? And what was your biggest learning for that journey? So first you're right that building an enterprise search company was something that nobody was excited about.

16:01You know, even when I went out to actually raise funds, there were people like who were willing to invest in me because I've been an entrepreneur before and I'd shown some proof that I've built some products in the past. But that category itself was not exciting to people, partly because it was a product that people felt was optional, like that you can live without it. Of course, you're living without it already. So that's true that you can live without it. But you know, that life is not great in my mind. There's no existing budget for it, for example. Yeah, there's no existing budget for it. But I think for me, what kept me on this path, despite a lot of indication, a lot of guidance from the market that we need to do something different, was fundamentally it came back to my own personal pain point and the pain point that I knew everybody who I know has, which is that people do find it hard to find information at work.

16:53and I'm going to add value to them and I don't have any doubt about it. So we sort of continued on that journey. We had to go through that period of where to actually do a lot of convincing. People would always ask us that, hey, even if I buy this, how am I going to tell whether this was useful to me or how much productivity gains I'm going to be getting? What's the ROI on this? And I have no answers to any one of those questions. And so when you don't have answers to those questions, you will tell them that, hey, look, just try it out for free and see if it actually helps you. And so that's the path that we had to take.

17:28We felt that we had to go and create that market, create that opportunity. And so get people to try your product out first. I think if you have a good product, if it solves a real need, then ultimately they will come and pay for it. It's a great story about leading with belief. You wanted to solve it because you knew the the problem so well, market or customers might have doubted. So in many ways, you're like, hey, try it out first and then see it. What was, you said, like they didn't know how to measure the productivity gains, ROI gains. Now that you're kind of past that stage and what is the kind of success criteria that you look at?

18:04Unlike in Google, successful searches, I'm sure it was a successful search session. You could look at bounce rate retention. But like, what is it that you look at right now for something that started off a bit fuzzy because there was no category for it? So from a product success point of view, we look at all these metrics that you mentioned. Like we want to make sure that the product is actually working well. And when people come and ask questions, that we are actually providing the right answers back to them. So that's the number one thing. We have to make sure that it solves the need for our people.

18:35For me, that has always been the most important metric, more important than like how many users within a company are using the product. because the mindset has to be that even if it's, you know, to a small set of people, make sure that you're actually being useful to them. So that's how we actually think about it. For users who are, you know, exposed to the platform, who have seen it once, like make sure that they are successful. They always find answers to their questions, that our session satisfaction scores are high in those customers. This is qualitative? Like you do surveys or? It's both.

19:07Well, there are three things, you know. Typically we don't do surveys. Like our customers will do survey. Okay. That's how they determine like, you know, whether this is a product that they want to keep in their enterprise or not. We look at both explicit and implicit signals that people actually give us just by using the product. As an example for search, you come and ask a question. After that, if you actually spend some good amount of time on a document, and then you don't do another search very quickly and refine your searches, that's a good indication that the user actually found something useful.

19:35as opposed to like, you know, if you did a search, you look at some results, you click on some documents, you come back and you actually change your search to something else. That sort of tells you that like, look, you know, you failed in the first one. Maybe you'll succeed in the second one. So you can actually collect these implicit metrics on user behavior that tells you how well you're doing. And then we use that, of course, to go look at bad queries, look at cases where we didn't do a good job for people and then improve our systems and then hope those metrics move up over time. And the ultimate goal is productivity gain.

20:05So for folks trying to understand how do I learn from Arvin how to tie this all the way back. So when I talk to the customer, I'm like, hey, look, this quarter, I bring in more builders to the company, but I'm necessarily seeing more productivity. And I was able to connect dots from a Polo server that they have a really hard time accessing knowledge. It doesn't matter if I bring more people, but they can collaborate, they can work. Are you able to connect that all the way through? Or is this kind of when you talk to the customer? Like for us internally, qualitatively, people are saying, I love Glyn.

20:37Like I just use it much better. It works across. Those are all kind of hallway conversations in many ways. Are you able to tie that all the way back to show like a percentage gain? Or that's a little bit coming from the people themselves? It's a very interesting question. Like there is that challenge that we still have. But if you think about it, there are a lot of productivity software where it's very hard to actually measure value, but you just know simply that you need them. For example, email, like, you know, like it's very hard to figure out what's the monetary value of email. We just try to take it away.

21:11Well, it just won't work. Yeah. And similarly, like, you know, if you have, you know, a video conferencing system like Zoom or Teams, these are fundamental tools that we need today. My personal belief is that having a really good search and question-answering service inside your company over your company knowledge is so fundamental. Many of our customers actually are of that mindset where they feel like, hey, this is so fundamental. I'm going to bring it in. I know my company needs it, and I don't need to go and measure its ROI. So we have customers who are like that. But then we have customers who want to actually see, I want to actually make sure that the system is actually working well.

21:50Like I want to see some qualitative metrics or quantitative metrics. And so they will do surveys. I don't know why it is so consistent, but typically people will say that like, you know, Glean saves them three to four hours of time every week. Now I can do the ROI math using that. I know how much each hour is worth. I can sort of come back and do a ROI, you know, analysis for Glean and see if it is actually a technology that's worthwhile. And, but it's still fuzzy. It's still fuzzy because like, okay, so what if you save time? Did it actually result in like more work or did employees just spend less time at work?

22:20So people have all these kinds of questions. So that's also not enough. But luckily, once you start to look into more specific functional use cases or departments, then you have very concrete business metrics that you already have in place. And you can see movement on those metrics after the introduction of Glean. What's an example, Arvind? So we worked with this really large telecom company, and they've actually put Glean in front of 60 ,000 customer care agents that they have. After they did that, they saw a 42 % reduction in case resolution time. So it's actually the number of how fast to resolve a case, and then as a result, how many cases an agent can now resolve in a day.