Scaling to $150M ARR and Beyond with Grafana Labs's CEO Raj Dutt and Lightspeed's Alex Kayyal

Please welcome to the stage Raj Dutt, co founder and CEO at Grafana Labs, and Alex Kahle, partner at Lightspeed.

All right. Feels like a classroom setting. This is good.

Yeah, it feels like I'm on a game show or a late night show or something like that. So this is fun.

That's right. Well, great. Great to be here, folks. Thanks so much for joining us. I'm psyched that we get to chat with Raj today. As you probably could tell from that video, the company's just been an absolute rocket ship. And us at Lightspeed have been delighted to get to work with Raj from the series A. For those that know Lightspeed, global venture capital firm investing really across all stages and global investor. You know, we started investing in Europe over a decade ago and so really excited I get to be here. And Raj, congrats on what is just an incredible company. I'd love to sort of rewind the clock a bit. It's always fun to hear the sort of founder story, the origin story. How did Grafana come to be in the early days?

Yeah. So obviously the company is centered around this open source project that my co founder, Torkel Odegaard created back in 2014. So that's really the origin story. It was actually New Year's Day 2014, he released this project that he'd been working on and he'd been working on it all throughout Christmas and New Year's. Completely annoying. His family being in the basement in his house in Stockholm. And basically my other co founder and I found this project, found Torkel, and the three of us decided to start a company around it. And that was almost 10 years ago. So that's how the company got started.

Did you ever think it would get as big as it is today?

If I'm being honest? Absolutely not. Yeah.

I think it's a quality we see of a lot of humble founders. It's sort of, you have this idea in the beginning and then it sort of blossoms into something. And at every stage of the company, it's sort of amazing to see the new limits and sort of new challenges.

Absolutely. I mean, I think our expectations have been reset, sort of our expectations about what's possible has been reset almost every year. Yeah.

One decision you made really early on that I want to spend some time talking about is sort of this decision to be remote. Now, the company started way before COVID and so, you know, during COVID obviously a lot of companies had to be remote because that's how the world became. And now actually what we see is for the Most part companies that have gone back to the office. You have bucked that trend where you were remote to begin with. You obviously stayed remote during COVID but even now you've decided to be remote. Why is that?

Yeah, I mean, we really believe in. And it's remote first, not remote friendly, to be clear. And I think there's a big difference with that and we feel really strongly about that. It's like you can make an office culture work, you can make a remote culture work, but I think when you try to mix it up, you really get into trouble. But it really started from the beginning of the company, right? Because things. Three co founders, one in. You know, I was in New York, my Torkel was in Sweden and Anthony was in Australia. So it doesn't get much worse than that in terms of time zone coverage. And so from the very beginning we were remote. You know, always felt that talent was global. You know, a bunch of us love to travel. I've been on the road since COVID basically, you know, it's fun building an international business. And then there's examples of some of the best software in the world that have been created by, you know, geographically distributed teams working in a async manner. Right. I mean, take a look at something like the Linux kernel, right? That's, you know, the way that you build, you know, very high quality software is kind of proven out. And you're right. Before COVID this was a little bit unique. You know, it was a recruiting advantage. We tell people like, you know, come work at Grafana Labs, we're a remote company and they go, wow, that's amazing. And now it's like, yawn, whatever, which is unfortunate from a recruiting standpoint, but I wouldn't do it any other way. And I think the interesting thing is that we're in 40 plus different countries and I think we get a really good perspective from across the team. And even our customer support and our on call shifts, we generally don't have to. People generally don't have to wake up to deal with an issue. Right. So our support kind of follows the sun, which is also really nice.

Yeah, you said New York, Sweden and Australia. For the three co founders, that definitely makes it spicy. For time zones, you're now 1200 people. I guess the biggest knock that I hear for companies that are remote is the culture piece. The fact that it's not as easy to build culture. You know, you're not as often together. How do you do that at Grafana? What's been the approach?

It's definitely Harder. And that's kind of back to this point that I think there's a difference between remote first and remote friendly. So if you're remote first, you can really try to build a culture that's, you know, really purpose built to be remote. Right? Because if you're remote friendly, I think the pattern that you get into often is you're basically going to have a almost second class career if you're a remote employee at a remote friendly company because you're just not going to be part of the water cooler conversations. You're not going to be close to the center of power and decision making people. So it's really hard to be remote friendly I think. But when you're remote first, you can make an attempt at least to fix the culture and purpose build the culture to be remote. I think you need to get the team together pretty often even as a remote company. How often we still joke and kind of nervously laugh when talking to VCs like you guys. And some of the comments are often like, oh, you're remote, that's great, you'll save a lot of money on office space. And I go, yeah, but we're going to spend it all back and more on travel. So we generally get every person in the company either together at an all company event or a team event, like generally two or three times a year.

And how often is your exec team on the same room?

We get in the same room about five or six times a year.

Five or six times?

Yeah.

And I guess from a sort of hiring perspective, what have you seen? Does it mean you can hire people that traditionally, you know, you wouldn't have recruited and remote first, does that mean there's no physical office space at Grafam?

Exactly. No physical office. You know, even when we have a lot of people in a single city and we allow people to go get WeWorks, we don't allow people to be in the same WeWork, which is ridiculous. Right? So like let's say we have a bunch of people in Berlin and let's say we have 20 people who want to get WeWorks. We won't allow people to be in the same WeWork because that creates an office. It creates a hub, right? We'll be like, just go into 10 different weworks around Berlin.

That's incredible.

Which upsets people. But that's, that's part of the way we try to build a remote first.

I'm imagining these like shadow WeWork Slack groups that the CEO doesn't know about, you know, or it's like they sort of happen to show up at the same coffee shop Monday to Friday. That's very cool. And I guess from a sort of going forward perspective, any plans to change this or you're 1200 people now, 2000 and then 10,000 at some point.

No plans to change it. I think it's pretty much built into our DNA at this point. I think it's definitely got its disadvantages. Don't get me wrong.

What would you say are the biggest disadvantages?

I mean, there's a feeling whenever we get people together for a few days after an off site, at the end of the off site, people go like, oh man, this was great. Imagine if we were all together all the time, the amount of work we'd get done. I don't think that's necessarily true because you couldn't keep up that level of energy all the time. And I think it's good to kind of get people together, do some planning and then go off and execute. But there's no doubt that if everyone was in the same office, you know, we'd kind of have easier communication. We'd have, you know, we'd be able to ramp people faster, we'd be able to hire more junior people. But then the trade off is, you know, again, talent is global and we wouldn't have been able to put together the incredible team that we have today if we were all, say all in San Francisco or something like that. Yeah.

I'm curious, by a show of hands, how many folks here are fully remote? That's actually a good number for the ones that didn't raise their hand. Any advice that you would give in terms of something that you've done from. Hey, whether it's the way you document things, the way you do communication, recording sessions. I'm just curious from this issue of time zones and even for companies that are not fully distributed and fully remote, you still have this issue of collaboration and sort of sometimes I think the second class citizens that are not in hq and I think companies like you that have sort of pioneered this, you know, 1200 people, there is no one office. There's things that have happened there from a process and internal sort of, you know, setup that allows for that to happen. Is there anything that, you know, comes to mind there that you'd really recommend everyone do?

I don't think there's one silver bullet or, you know, any kind of like very sort of obvious thing that we do. I mean, like, there's a few things, right, we, we try to have, we try to be very async in our communications, we try to write a lot of things down, record a lot of meetings, record a lot of zooms, you know, allow people to consume information sort of on their own schedule, on their own time zone. Initially, it was really hard having teams that were spread across different time zones. But with scale, you get to solve some of those problems by being able to have local leaders in every time zone and teams that aren't necessarily split all across the world. But it's definitely harder. It definitely takes more work. I think there's more demands placed on people managers to be better people managers, honestly, and not sort of, you know, rely on shoulder surfing or people, you know, being, you know, ad hoc conversations. You have to kind of plan things more. But I wouldn't say there's a silver bullet. And honestly, we're still figuring it out and it's definitely far from perfect. So. Yeah.

I love that you're investing, though, on the sort of the office savings in travel, because I heard this term the other day that resonated this sort of trust battery. And when you're on zoom, you sort of, over time, you deplete that. And then as soon as you get back together, you sort of refill this battery and then it gives you the chance to sort of go another three months before seeing people in person. And so it feels like that's just a critical part. At the end of the day, we're social, human creatures, and bringing people together.

Just feels 100% agree. 100% agree, I think. And that's why it's really important to get the team together. Because when you're fully remote and everyone's just a box on a screen, on a zoom, it's easy to think that you're almost like playing a video game and these people aren't real. And, you know, it's easier to, you know, pardon my language, it's easier to be an asshole to someone that you don't actually know. It's easier to not give those people the benefit of the doubt. And when you meet people in person and, you know, go out to dinner, you know, have a beer with your colleagues, that really matters. It's not just a touchy feely thing. There is something fundamentally human and innate that builds trust, like you say, and I hadn't heard the term trust battery, but that, that really resonates and makes a lot of sense to me because recharging that trust battery is what these events and off sites are all about.

Yeah, I love it. I want to switch gears a little bit in the video that was on it was kind of incredible to see some of the logos I saw. NASA is using Grafana, which is really cool. And one of the decisions that you've had to make is how to approach monetization and when to do that and how to do it. And that's oftentimes for an open source company, one of the biggest decisions to make. Can you just give us a little bit of insight as to sort of how that came to be in terms of how you all approached it?

Sure, yeah. So the first few years in the company we didn't think at all about monetization. And those were like our innocent salad days that I look back on fondly because we had no customers, no revenue, no responsibilities. We were just trying to. Fun days, fun days, exactly. No VCs and we were just trying to build really popular open source software and build a community. And look, the goals of open source and the goals of our commercial ambitions are in stark contrast to each other. Open source is all about value creation and our go to market teams are all about value capture. And balancing those things is honestly really hard. And we struggle with it all the time, we struggle with it every day. And I think if we stop struggling with that balance, that'll be the day that something is going wrong. And our open source software is not by any means crippleware. It's not demo ware. It's used by some of the largest companies in the world who don't pay us. You mentioned NASA. They're not a customer. Right? We have.

Not a paying customer.

Not a paying customer, exactly. We use the word customer at Grafana to mean a paying customer. Right. And so we have almost a million companies using Grafana and we have about 6,000 customers. Right. So if you do the math, that's less than 1% of the people using Grafana pay us. And you know, when we first started talking to, when we first started to raise money and in fact obviously Lightspeed was the first VC that we started working with, we had a slide of logos and they were really impressive logos but none of the logos were customers. And our pitch was sort of like, look, we have all these amazing companies using our software. We will figure out over time how to make some of these companies customers and we've done that. But the balance is really hard. We try to have features and capabilities that we hold back that really appeal to large enterprises, more so than the kind of startups and the mid market companies, things around compliance and security and. But it's a really tough balance And I'd say that the landscape of open source companies is something that has changed dramatically over the last few years and something we watch closely. So when we started, there were a ton of open source companies that we looked up to and admired and drew inspiration from. There was like Red hat, there was MongoDB, Elasticsearch, Redis, HashiCorp, and sort of over the last few years, every single one of these companies has decided that being an open source company with an OSI license is not the right decision for them. And look, I still admire these companies and obviously they're going to make the decision that makes the most sense for us, for them. But for us, we're still an open source company and most of the work that we do is under an OSI license. But it's feeling, feeling pretty lonely these days because we're sort of one of the last remaining open source companies at scale. But we're still figuring out how to balance value capture with value creation. And I think having the cloud offering was a big unlock for us because as a delivery model, cloud is a very nice delineation to be like, if you want to use our cloud service and consume all this stuff that we have in a supported, scalable way, you're obviously going to pay us. But then the whole dynamic between open source and the hyperscale cloud vendors is a whole other topic too. So.

Yeah, and I'm sure that helps from a margin perspective, the fact that once they're hosting it in the cloud with you, then otherwise there's a sort of potential impact on.

Yeah, yep.

And what's been the, I mean, I guess a lot of those companies that you mentioned, the sort of OGs and open source, most of those are now public companies. Is that what do you think is driving that sort of decision? You become public and, you know, there's more of a focus on driving the revenue. I don't know.

I mean, I'm not here to speculate on what other companies are thinking.

Yeah, fair enough. And I guess on sort of in your mind, the 6,000 to a million, it's a pretty staggering sort of ratio in terms of how much usage there is of Grafana and how many are, you know, customers, as you say, you know, paid customers, is there a KPI in your mind in terms of what that becomes? Does it matter? How do you sort of drive the business around that? Is that even one of the things that you focus on?

I mean, we look at that stat, right? We sit around sometimes and we go like, wow, we've kind of monetized less than 1% of the people that are using Grafana. But at the end of the day we really want to make the overall pie as big as possible. And we know that our entire business model is sort of predicated on capturing a small piece of what is hopefully an extremely large pie. Right. I don't think it would be feasible for us to make more than a low single digit percentage of Grafana users customers. Like we have so many companies and individuals using Grafana for all sorts of crazy things that you know, they would never have budget to rail budget to pay us. Right. We have tens of thousands of people using Grafana for home lab stuff to monitor how their sourdough is being baked or what sort of media their plex servers are pirating that day, or how their EV is charging. I mean, all sorts of things like that. And so we're not really trying to monetize that, that part of the community. Right. But when we, you know, when we discover that there's a large global bank using Grafana, then we become really interested. We're like, how can we make sure that we monetize that customer? But a lot of our product strategy is kind of set around that dynamic. Right. We're very much set up to want to monetize people who have, you know, more money than time. Right.

In my mind I'm thinking of the sort of Grafana powered bakery which is like, yeah, that's awesome. Seeing that today the company's obviously been incredibly successful. You've crossed 250 million of ARR, which is just amazing. I'm curious. It feels like on that journey there's probably call it 3, 4, 5 chapters of a stage of company. You talked about the very initial days where it was just community focused only, no funding yet bootstrapped. What are some of the chapters since then? I mean as you think about that journey from 0 to 1200 employees, 0 to 250 million plus of ARR, what are some of the sort of markers in your mind and what's changed in each of those?

Yeah, that's a really good question. So you know, the first stage, sort of stage zero as it were, right. Was like no sales, no customers. We were just focused on building the community, nurturing the community, building open source software, giving it away for free. You know, our business plan at stage zero was, you know, literally like step one, you know, build freely available open source software. Step two, question mark, Step three, profit. Right. We didn't know what the, what step two was. And that was the first stage of the company that was the first few years. And then stage one, if you will, was really around our core open source project, Grafana itself. Right. I'm curious how many people here use Grafana. Whether you're a customer or a user.

That's cool, that's awesome.

But obviously like the company, it's named Grafana Labs. Grafana is still at the center of everything we do. So we wanted to have a product around Grafana itself. Right. So the first step that we took was we essentially made an enterprise version of Grafana and all we sold was the visualization layer. Right. Because Grafana is all about data visualization and, and we had no sales team. It was just the kind of founding, the founders and the founding employees sort of just trying to do sales and figure out pattern match and figure out how to like what resonated, what we had to build, tried to make it a little bit repeatable. And so that was sort of stage one for us. And then stage two, I think we became a multi product company. Right. We knew that we needed to do more than just visualization to really build a large business, particularly in the observability space. We knew that we needed to build some databases basically to store data because that was where all the pain was and that was quite frankly where all the money was. And so we built out these open source metrics databases around Prometheus. We built out open source logging backend called Loki. We built out open source tracing called Tempo. We bought a company called Pyroscope for profiles. And so we kind of built out this whole stack as it were. Right. And so how big were you when.

You became multi product?

We were, we were about 60 people. Yeah, about 60 people. And we probably had about maybe five or $10 million in revenue. And yeah, going multi product was a pretty big deal for us. And I think a lot of companies struggle with it and we certainly zigged and zagged too, but luckily we managed to make that transition. And then really the third stage was going fully all in into cloud. Right. So we actually deploy a lot of the new features that we develop on our cloud first and then kind of back port them, if you will, into open source, which is kind of the, the opposite of how one might think you, you would intuitively do it. And kind of along the way through stage one, stage two, stage three, we've not only grown, but we've shifted our revenue mix pretty dramatically. Right. So in the early days, all our revenue came from Grafana visualization. Today Grafana is actually, you know, not even our, our biggest product, like our metrics product is, is bigger than Grafana itself. Although Grafana has, you know, all the brand recognition and you know, the adoption. Right. And you know, stage one, stage two, we were still selling a lot of On Prem software and licensed software, whereas today most of our revenue comes from Grafana Cloud, our SaaS offering. And so as we've grown, we've kind of become a multi product company, but also shifted from On Prem to cloud and then also pretty dramatically shifted our whole go to market team and go to market motion.

Right.

Like we've built an enterprise sales team pretty fast and pretty dramatically in the last three or four years basically.

And that's kind of fascinating to think about how early you became multi product. I mean that's typically in the journey of a lot of companies, we see that happen later. What drove that in your mind? Was it sort of just customer feedback pulling you that direction? Was it an insight you had on the market?

It was customer feedback, I'd say, because you know, we'd go into customers or potential customers and you know, see what they were doing with observability and realize sort of like the intensity of their infrastructure. And you know, Grafana itself is so lightweight, right? So they'd be like, yeah, like we love Grafana and like, you know, it runs on a VM and it runs for 1000 users and it's great and you know, no problem and you know, we don't have any issues scaling it. But meanwhile, like for our logs or our metrics, like, oh my God, like we have, you know, 1,000 servers running, you know, needed to support these workloads and that was sort of eye opening for us. And you know, like with Grafana we charge by the seat, right. And we really wanted to get to a model that was more consumption based and we didn't really see a way to do that with just having Grafana. Right. And also customers quite frankly told us that if, if we wanted them to kind of bet on Grafana Labs for observability, then we needed to have a full observability platform. Right. I mean, the thing about Grafana is it works with every single backend, right? Whether you're using Datadog or New Relic or Prometheus or whatever, it'll allow you to visualize data from anywhere. But a lot of our customers said that that's great, we love it, but we want you to provide the full stack end to end. And so our customers kind of pushed us to basically develop our own databases which we Did.

That's amazing. It's always great to get that pull from the market when you're building product. And I'm curious on that journey. I think being a founder is incredibly hard. Not just because you're building something out of thin air and out of nothing and it's the roller coaster that we all know it is, but also because you sort of have to reinvent yourself as an individual. I'm sure your sort of management style when you were just the three of you versus when you were 30, 300, now 1200, and that also that founder relationship evolves. How have you sort of seen your management style evolve as a founder? What has been the sort of hardest part from going from 0 to 1200, folks in your mind?

Yeah, it's a really good question. And it's been really challenging. And I think a lot of people here are probably going through similar. Similar things, right, because you. You have to sort of reset and redefine, you know, how. How you interact with the. With the rest of the company at every level of scale. Right. You know, going from a company that was, you know, 30, 40 people where I knew every single detail and was involved in, you know, almost every single decision to now, you know, quite frankly, not even knowing who works at the company has been really, like, challenging. And I think I've had to every year reset sort of how I interact with the company. And at this point, you know, my level of influence is really around sort of the senior leadership team and making sure that we have the right people that are in the right spots at the right time that are hopefully aligned, and then just trusting them to kind of get it done, so to speak. And just personally speaking, that's been really challenging for me. And I'm still struggling to figure this out with every level of scale. Right. I mean, I've never done this at this scale before, so it's like you're constantly figuring out what altitude to fly at. Right. You know, in the early days, you can fly, like, above, you know, in the trees. Right. And now I feel like I'm kind of almost like a satellite. And that feels annoying, quite frankly, at times, but, you know. Yeah, I mean, still figuring it out. And don't claim to have the answers on that.

Yeah, yeah. Thank you for sharing that. And it's. I love that analogy of sort of like every year having to reset that. And to your point, it's like at 30, 40 people you've probably even hired, you've been the final interviewer for a lot of those people to you know, today it's really about driving the management team and the executive team. Have you, in terms of bringing amazing people around you and hiring folks, is there a lesson you've learned there in terms of being better at that?

It's really tough. I mean, I think that lessons around hiring, I think we, I think a lesson that I've learned is not to over index on someone's resume. Right. Like, it's tempting to look at someone's background and you know, look at all the amazing companies that they've worked at and sort of think like, wow, okay, so this person's had this experience at all these companies that, you know, maybe you admire or you think you know is applicable to your business. And, you know, you kind of can get wowed by someone saying, well, I have this playbook and I can apply my playbook to your company. And at this point that just scares me. I'm like, what do you mean you can apply your playbook to a company that you don't even know yet? That's ridiculous. Right? And so I think that would be the only. That would be probably the main lesson learned is optimize for things like drive, grit, intelligence, you know, willingness to learn, you know, culture, fit, as it were. And you know, those things matter a lot. And I think, you know, while it's nice to have different experiences or have worked at different companies, I think in the early days we, we sort of over indexed on that or got wowed by that. Right. And so, yeah, I think, I think at this point, the idea of someone applying a playbook that they have to accompany, you know, before they've even, you know, barely walked in the door at Grafana Labs, like, really gives me the shivers.

So, yeah, I love that. It's sort of like the importance of first principle thinking as opposed to just like copy pasting. Oh, I did it this way here, I'll just do the same exact thing. And it's, you know, some, some folks have that sort of beginner's mind and you look for that when you're hiring your exact team. That's awesome. I have one or two more questions and I'd love to open it up to the group. So if you have questions, we will take them. Grafana is your second company and I'm just curious, what do you feel like being a second time founder? How does that change both in terms of the ability to build something that's super valuable and has had the success it has had, but also in terms of some of the lessons learned the first time around having an impact on Grafana.

I love this question because I actually just kind of gave a similar answer at one of our recent go to market QBRs. So for me personally, and I think this will resonate maybe with people here, particularly founders that are very product oriented and I think a lot of founders are right. So there were two things that were big lessons for me. One was at my previous startup we didn't take sales and go to market seriously enough. We thought and we were super naive in this, but we thought that if we built a great product that the world would beat a path to our door, right? And we almost laughed at the idea of having enterprise sales team or the need to take customers out to steak dinners or talk to the cio. We thought literally we're just going to focus on building a great product and somehow the world will discover our great product and buy it. And that was so incredibly naive but an easy pattern to fall into. And we really tried to overcompensate the other way on Grafana Labs, right? So we took go to market very seriously. We really thought about it from the beginning. We wanted to build and have a world class sales team. So that's one learning and the other. My last startup was really under capitalized, right. So we were always struggling to make payroll. It was a capex intensive data center business, right. So like every excess dollar that we had we'd use to like try to buy more servers, right? And we'd always be late on payroll. We couldn't buy enough servers and we couldn't essentially execute on the opportunity that we had. And so we also didn't want to make that mistake which is why we ended up talking to people like you guys at Lightspeed, right? Because we wanted to have enough cash in the bank to be able to do the things that we knew made sense. So I think those were the two big lessons learned, right? Take go to market seriously because having a good product isn't enough and have enough cash on the balance sheet to be able to execute on the opportunity that you have. And yeah, I mean in many ways Grafana Labs is like a do over for me and a lot of the people who also worked at the last company, right. We want to do the things that again that worked but not make the mistakes that we made at the last company. And I think yeah, that's really neat.

Yeah, it's so tempting the sort of founder journey to build it and they will come just build a great product and hope.

I wish the world worked that way. Wouldn't that be great, but it doesn't.

It is a hard lesson though. And I think one thing that's particularly interesting, what you just mentioned is that transition from being sort of very R and D focused to also having a sales and marketing team. In my experience, there's always tension between those two sides of the house. The R and D team is like, can't the sales team just sell the things we have? And the go to market team goes to R and D and goes, can't you just build the product that customers want? How did you manage that tension? And how do you sort of keep that R and D core which is so important to everything Grafana has become, but at the same time recognize that importance of sort of the go to market piece? Yeah.

So the tension you just mentioned, I think that that exists, I've seen that exist in pretty toxic ways at a lot of different companies. Right. Where essentially the R and D team doesn't have a relationship with the go to market team and those teams basically hate each other, don't respect each other at all, and almost have contempt for each other. So I'd like to think that we really have that problem at Grafana Labs. And I think one of the main reasons is we really want our R and D team to be pretty focused on customers, talking to customers, involved in deals. You know, like we don't like our. A pattern for us is we want to hire engineers who are involved in sales cycles, are involved in customers, are involved, talk to customers all the time. A lot of companies kind of hide their engineers from customers or put like a lot of buffers or processes where customers and engineers can never interact. And I think that that can be dangerous, although I understand why companies do that. But honestly that's. That's also where a lot of my effort as CEO today is. Is put, is. Is trying to make sure that the relationship between R and D and go to market is. Is productive, you know, and so yeah, I mean, because back to the open source balance too, right. I think, you know, the stereotypical view is kind of true. Our average person in the go to market team would hope that every feature that we develop does not go into open source. And our average R and D engineer would hope that every feature that we develop does go into open source. Right. So yeah, that tension's tough at Grafana. We have a great CRO and you know, he really encapsulates Dave, really encapsulates sort of this idea of we're all in customer success, no matter your job function. And it's really a team sale at Grafana Labs. We have a Slack channel where every deal we win the rep kind of summarizes the deal, why we won it and who was involved in the deal. And one of the things that I really like is in almost all of those posts, there's dozens of people mentioned in every deal, not just on the sales team. And that's really cool.

That's awesome. Great way to sort of drive that cultural alignment and give credit. And I love that point around giving sort of non salespeople exposure to customers. I've seen in our sort of portfolio and in general the impact that drives in terms of what people are able to build and the empathy it drives for customers. And you're not just building in isolation. That's amazing.

Yeah, the empathy. That's a really good point, Alex, because that empathy drives a lot of the day to day product decisions when you have empathy for your customers. Right. And we're lucky enough where it's not like we're building, I don't know, tax software, where our engineers, they're kind of also subject matter experts in the kind of software that they're building because they use it every day. Right. We use our own software to run our cloud service. So they almost that empathy is almost felt not only on behalf of customers, but our own teams. And that's sort of a really nice feedback cycle too.

That's awesome. Well, I've learned a lot already. I mean, just some sort of highlights for me the importance of being remote first and the intentionality that you bring to that. Second is this sort of focus on community and not just monetization and how to drive that balance. Third is obviously the sort of reinventing of your role and that impact it's had in terms of every year sort of really defining what your job as a CEO is for the company and how that changes every year. And then lastly so much around the culture of driving that alignment. So I hope it's become obvious in this conversation to all of you. It has been at Lightspeed for a long time how lucky we are to have partnered with Raj. And thank you so much for that, Raj. So we're going to open it up to questions if folks, I believe there's two mics on either side.

I also wanted to thank you, Alex and Lightspeed, because you guys were the first people almost five years ago who believed that we had a business. So really appreciate you also.

Thank you so much. It's been a pleasure. Yeah, please. Great. Hi Raj. Yeah, over this way.

Quick question.

I'M curious how you handle compensation across 60 countries. So, for example, is an engineer paid the same regardless of location, or is it more location specific?

It's absolutely location specific, and I'm pretty opinionated on this. I know there's a lot of talk about, like, aligning on global compensation, and to me, that just seems absolutely insane. So for us, it's absolutely location specific. You know, an engineer in the Bay Area does not make the same amount of money as, you know, an engineer in, say, Eastern Europe. Thank you.

Yeah.

Hi, Raj.

Thank you.

Really, really good session. I appreciate it.

The consumption model that you're pursuing with the cloud, what are your thoughts on that? Jason Lemkin talked about a pushback on spend. Do you have concerns about that in the long term?

Are you getting pushback?

Are you thinking about other models?

Yeah. So for US consumption model, what I mean by that is it's just tied to the amount of data that you send us. And one of the things that we've done, and I think companies like AWS have been pretty progressive with this also, is so about a year and a half ago, we had an internal conversation where we basically acknowledged that the entire observability space had done a pretty terrible job in aligning the consumption costs, especially when you look at the data volumes that have just been exploding exponentially with the value that customers get from that exploding data. Right. So, like, data's been kind of going exponential, but the value that customers get from that data is maybe growing linearly, maybe sub linearly, maybe even, like asymptotically. Right. And so we have a capability on our cloud which is now a differentiator versus our open source called adaptive telemetry. And so what that does is it basically analyzes what data you're sending us and allows you to start dropping data that you're not using. And when we launched this feature, you can imagine our sales team were completely freaked out. They were like, how can we do this? Because literally all our deals are going to get shrunk in size. I remember having conversations with our board. Same sort of reaction, like, are you sure you want to do this? Like, you're literally going to shrink your own customers. Right. And so I think, to kind of answer your question, we believe in the consumption model, but sort of with some caveats. And that's reflected in our product strategy. And have we taken. Have we lost millions and millions of dollars of revenue because of that product strategy? Absolutely. But we have a cultural tenant that we sold from Goldman Sachs where we say we're Greedy, but we're long term greedy. And so that's sort of like a manifestation of that long term greedy strategy. So we still believe in the consumption model, but I think you've got to sort of be nuanced in your approach for it and make sure that you're kind of aligned with customer value. And there's a lot of businesses out there that are consumption based, that are data volume based, that I think are, you know, sort of struggling with that, just like we continue to do.

Is it 100% consumption based now?

So we still price both by seat as well as by consumption on data, but the overwhelming majority of our revenue is consumption based. Yeah.

Thanks for the talk. Really interested in the point around linking the R and D and the sales team. Have you found any other ways to encourage or incentivize engineers or people on the R and D side to be involved in sales cycles outside of kind of shouting out success involvement at the end of a closed deal?

Yeah, a few things. Like, let me think of a few examples. So like many companies, we have the equivalent of a president's club, right? And normally a president's club, as I'm sure most of you know or have been familiar with, is like a reward trip for your best salespeople. Like we call it Grafana Club. And we actually invite not just the best salespeople, but the engineers and the lawyers and the HR people who exemplify being the best of grafanistas with a focus on people who helped with closing deals. That's one example. Another example is we have these hackathons every single quarter where we encourage our engineers to team up with, let's say our SES or in some cases even other people on our go to market teams and they kind of present projects back to the company. And so a lot of our roadmap is driven by not just our engineers, very bottoms up, but also our ses. And it's funny because you see our engineers team up with our sesame. And a lot of the winners of our internal hackathons win because their presentations are so good. And the reason their presentations are so good is because they have an SE presenting and collaborating with an engineer. And so that dynamic's also good. But just look for all these little things, I think, and they add up. I think people put too many boundaries in between sales and R and D and we just try to break those boundaries down. Also optimize who you're hiring, right? Like if, you know, we try not to hire engineers. Who would say that? Oh, talk to a customer, I'd never want to do that. Well, then, okay, well, maybe Grafana Labs isn't the right company for you.

Thanks.

Yeah.

This is also, I think, where the sort of remote has a big impact, because in a lot of companies, you have salespeople that are in every day, and the engineers are in once or twice, and they're at home. And so there is a bit of that natural disconnect in the office space. I think it also speaks to that remote.

Yeah, I think that's fair benefit.

Amazing. Well, thank you, Raj, so much. This was super fun and very insightful. Please join me in thanking Raj for his insights.

Thanks, Alex.