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

Grafana Labs CEO Raj Dutt built a $250 million ARR company from a 2014 open-source project by staying remote-first across 60+ countries and expanding from visualization into a full observability stack. He credits his previous startup's failures—under-capitalization and weak go-to-market—with teaching him to hire strong sales teams and manage cash carefully.
Chapters
Please welcome to the stage Raj Dutt, co-founder and CEO at Grafana Labs, and Alex Kale, 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 who didn't 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, you know, 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, you know, 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 a lot of sort 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 have been, 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 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 remote, and it's remote first, not remote friendly, to be clear. And I think there's a, 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, uh, 3 co-founders, one in, you know, I was in New York, uh, my, uh, 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, um, you know, always felt that, uh, talent was global, um, you know, a bunch of us love to travel. I've been on the road, you know, 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 an 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," you know, 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, you know, we're in 40+ different countries, and I think we get a really good perspective from, you know, across the team. And, you know, 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 3 co-founders. That definitely makes it spicy for time zones. You're now 1,200 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 an almost second-class career if you're a remote employee at a remote-friendly company. 'cause you're just not gonna be part of the water cooler conversations, you're not gonna be close to the center of power and decision-making, you know, 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, so we used to, 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 get the— we generally get every person in the company either together at an all-company event or a team event, like generally 2 or 3 times a year. So.
I mean, how often is your exec team all in the same room?
We get in the same room about 5 or 6 times a year.
5 or 6 times a year. 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? In remote-first, does that mean there's no physical office space at Grafana?
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 wanna 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, you know, 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 culture.
I'm imagining these shadow WeWork Slack groups that the CEO doesn't know about, where it's like they happen to show up at the same coffee shop Monday to Friday. That's very cool. And I guess from a going-forward perspective, any plans to change this? You're 1,200 people now, 2,000 and then 10,000 at some point.
No plans to change it. Pretty much built into our DNA at this point. I think it's definitely got its disadvantages, don't get me wrong. I mean, you know—
What would you say are the biggest disadvantages?
I mean, there's a feeling whenever we get people together for a few days, you know, after an offsite, you know, at the end of the offsite, people go like, "Oh man, this was great. Imagine if we were, you know, all together all the time, the amount of work we'd get done." And I don't think that's necessarily true because you couldn't keep up that level of energy all the time. Right? 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, in San Francisco or something like that.
Yeah? [Speaker:AUDIENCE] 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, 1,200 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 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 kind of be better people managers, honestly, and not sort of rely on shoulder surfing or people being 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 3 months before seeing people in person. And so it feels like that's just a critical part. You know, 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, you know, 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 offsites are all about.
Yeah, I love it. I want to switch gears a little bit. You know, in the video that was on, we, you know, it's kind of incredible to see some of the logos. You know, I saw NASA is using Grafana, which is really cool. And one of the decisions that you've had to make is sort of how to approach monetization and when to do that and how to do it. And that's oftentimes, you know, 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, you know, trying to build really popular open source software and build a community. And look, the goals of open source and the goals of our, you know, commercial ambitions are in stark contrast to each other, right? Like 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, like, something is going wrong. And, you know, our open source software is not by any means crippleware. It's not, you know, it's not demoware. 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, 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, right? So when we started, there were a ton of open source companies that we looked up to and admired and drew inspiration from, right? 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, you know, 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, you know, we're still an open source company, and most of the work that we do is under an OSI license, but it's feeling— It's 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 in open source, most of those are now public companies. Is that what you think is driving that sort of decision? You become public and 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 1 million, it's a pretty staggering sort of ratio in terms of how much usage there is of Grafana and how many are customers, as you say, paid customers. Is there a KPI in your mind in terms of what that becomes? Does it matter? You know, 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, you know, we want to make the overall pie as big as possible. And we know that our entire business model is 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. We have so many companies and individuals using Grafana for all sorts of crazy things that, you know, they would never have budget to real budget to pay us, right? We have, you know, tens of thousands of people using Grafana for like home lab stuff to monitor how their sourdough is being baked. You know, or what sort of media their Plex servers are pirating that day, or, you know, how their EV is charging. I mean, all sorts of things like that. And so like we're not really trying to monetize that. That part of the community, right? But 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 more money than time, right?
In my mind, I'm thinking of the Grafana-powered bakery, which is like, yeah, that's awesome. Yeah. 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 1,200 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, you know, sort of stage 0 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. Our business plan at stage 0 was literally like step 1, build freely available open source software. Step 2, question mark. Step 3, profit. We didn't know what step 2 was. And that was the first stage of the company. That was the first few years. And then stage 1, if you will, was really around our core open source project, Grafana itself. 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, its name 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 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, you know, like what resonated, what we had to build, you know, try to make it a little bit repeatable. And so that was sort of stage 1 for us. And then stage 2, I think, you know, 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 about 60 people. Yeah, about 60 people. And we probably had about maybe $5 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 like kind of backport them, if you will, into open source. Which is kind of the opposite of how one might think you would intuitively do it. And kind of along the way through stage 1, stage 2, stage 3, 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 not even our biggest product. Our metrics product is bigger than Grafana itself, although Grafana has, you know, all the brand recognition and, uh, you know, the adoption, right? And, uh, you know, stage 1, stage 2, 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 We've built an enterprise sales team pretty fast and pretty dramatically in the last 3 or 4 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 in that direction? Was it an insight you had on the market?
It was customer feedback, I'd say. We'd go into customers or potential customers and see what they were doing with observability and realize the intensity of their infrastructure. Grafana itself is so lightweight, right? So they'd be like, "Yeah, we love Grafana and it runs on a VM and it runs for 1,000 users and it's great and no problem and we don't have any issues scaling it. But meanwhile, for our logs or our metrics, oh my God, we have—" 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, you know, 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 products. And I'm curious on that journey, you know, one of the— 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 3 of you versus when you were 30, 300, now 1,200, um, 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 1,200 folks in your mind?
Yeah, no, it's a really good question, and, uh, it's been really challenging, and I think a lot of people here are probably going through similar things, right? Because you have to sort of reset and redefine, you know, how you interact 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 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, you know, in the right spots at the right time that are hopefully aligned and then just, you know, trusting them to, you know, kind of, you know, 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, you know, 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, you know, to your point, it's like at 30, 40 people, you've probably even hired, you know, even 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 it, 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 overindexed 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 a company, 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. Yes. As opposed to just like copy pasting. Yeah. Oh, I did it this way here. I'll just do the same exact thing. Right. And it's, you know, some folks have that sort of beginner's mind and you look for that when you're hiring your exec 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, you know, what do you feel like being a second-time founder, how does that change? Both in terms of, you know, the ability to build something that's, you know, super valuable and has had the success it has had, but also in terms of some of the lessons learned the first time around, sort of having an impact on, you know, Grafana.
I love this question because I actually Jason M. Lemkin 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, you know, 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. And we almost laughed at the idea of having an enterprise sales team or the need to take customers out to steak dinners or talk to the CIO. We thought literally like 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 at the easy pattern to fall into, and we, we really tried to overcompensate the other way on, on Grafana Labs, right? So we took go-to-market very seriously. We really thought about it from the beginning. Um, you know, we, we wanted to build and, and have a world-class sales team. So that's one learning. Um, and the other— my last startup was, was really undercapitalized, 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, 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, right? Which is why we ended up talking to people like you guys at Lightspeed, right? Because we didn't want— 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, you know, have enough cash on the balance sheet to be able to execute on the, the opportunity that you have. And, uh, 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, 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 in 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's, it is a hard lesson though. And I think one, one thing that's particularly interesting, what you just mentioned is that transition from being sort of very R&D focused to also having a sales and marketing team. In my experience, there's always tension between those two sides of the house. You know, the R&D team is like, "Can't the sales team just sell the things we have?" And the go-to-market team goes to R&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&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 exists. I've seen that exist in pretty toxic ways at a lot of different companies, right? Where essentially the R&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 don't really have that problem at Grafana Labs, and I think one of the main reasons is We really want our R&D team to be pretty focused on customers, talking to customers, involved in deals. You know, like, we don't— like, a pattern for us is we want to hire engineers who are involved in sales cycles, are involved in customers, are involved, you know, 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 also where a lot of my effort as CEO today is put, is trying to make sure that the relationship between R&D and go-to-market is productive. You know, and so, yeah, I mean, because back to the open source balance too, right? I think 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&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 he really encapsulates— Dave really encapsulates sort of this, idea of we're all in customer success, you know, no matter your job function. And, you know, it's really a team sale at Grofunnel Labs. Like, we have a Slack channel where, you know, 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, like, I really like is in almost all of those posts, there's like 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 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. Like, you know, like 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, tech software where, you know, 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, you know, 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 modernization 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, you know, every year sort of really defining what your job as the 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, as 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 5 years ago who believed that we had a business.
So really appreciate you also. Thank you so much. Yeah, it's been a pleasure. Yeah, please. 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 aligning on global compensation. And to me, that just seems absolutely insane. So for us, it's absolutely location-specific. An engineer in the Bay Area does not make the same amount of money as an engineer in, say, Eastern Europe. Thank you. Yeah, hi Raj, thank you. Really, really good session, I appreciate it.
The, the consumption model that you're, you're pursuing with the cloud, what are your thoughts on that?
Jason M.
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, you know, for, for us, consumption model, you know, 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 we— 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 sublinearly, maybe even like asymptotically, right? And so, you know, 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, like, you know, all our deals are gonna 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 gonna, you know, shrink your own customers, right? And so I think to kind of answer your question, like, 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, you know, we have a cultural tenet that we stole from Goldman Sachs where we say we're greedy, but we're long-term greedy, right? 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 know, you're kind of aligned with customer value. And there's a lot of businesses out there that are consumption-based, that are, you know, data-volume-based that I think are are, you know, sort of struggling with that, just like we continue to do. Thank you. Yep.
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.
Hi, thanks for the talk. I'm really interested in the point around linking the R&D and the sales team. Have you found any other ways to encourage or incentivize engineers or people on the R&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, um, let me think of a few examples. So like many companies, we have a, uh, the equivalent of a President's Club, right? Um, and normally a President's Club is, as I'm sure most of you know or have been familiar with, is like a reward trip for your best salespeople. 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. And so 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, you know, other people on our go-to-market teams. And they kind of, you know, 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 SEs 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, you know, and collaborating with an engineer. And so that dynamic's also good. But just, you know, look for all these little things, I think, and they add up, right? Just, I think people put too many boundaries in between sales and R&D, and we just try to break those boundaries down. Also optimize who you're hiring, right? Like, if we try not to hire engineers who would say that, oh, like 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. Yep. In sort of the office space, I think it also speaks to that remote—
Yeah, I think that's fair. Yeah. 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.
More from Jason

Why Your Next Hire Should Report to an AI, Tragedy Apps, and Too Many AI SDRs? | The Agents #004

Our Agents Drove Our Salesforce Bill Up 80%, Marketo Hates Agents, and We Stealth-Churned Off Notion

Managing 20+ AI Agents: Lazy Agents, Our $500K AI Bill, Stealth Churn & the Death of 60% Solutions







