From $1M to $3B ARR: Databricks CRO Ron Gabrisko on Scaling a Revenue Rocket Ship

Depending on what type of business you have meetups or industry roundtables. Like the your best selling mechanism is having a really happy customer sell to a prospect. That's your number one thing. So setting up environments where you can do that I think is super valuable. We had the advantage of having these really large open source communities like Spark Summit where we'd bring thousands of users and customers together. But even early on we did things like product advisory board. We're very customer obsessed. Right. So you're going to get a lot of innovation and other ideas from your customers. You never want to do like a one off, but if you hear something from 20 different customers put in the product. Right. And those customers want to feel special too. They want to be part of the rocket ship. Right? So bring them in. Make them part of your family.

Zaster fans, welcome to another incredible episode of CRO Confidential. I'm your host Sam Blond. We have a really special episode for you this week. We have Ron Gabrisco who's CRO at Databricks and couple things to flag before we jump into the meat of the episode. If you've been living under a rock, Databricks is one of the largest pre IPO technology businesses in the world. Ron joined Databricks as CRO when there was less than a million dollars of ARR. Fast forward to today. We have a revenue leader who has scaled to like sites seen by very few revenue leaders at a company that is one of the largest pre IPO companies in the world. The makings for an incredible episode. Thank you Ron for joining and looking forward to the episode.

Yeah, thanks for having me.

All right, before we jump in, Ron has an incredible background prior to joining Databricks. He was with Axway Software prior to Databricks. Really impressive run and outcome there and then interesting and applicable to some of the content for today's episode. Ron has an MBA and a Master's in engineering from Stanford. So a bit of atypical background for a sales leader. Certainly not my experience from an education standpoint with most of the sales folks that I have worked with. Let's actually start there before we get into the revenue. Let's start with you joining Databricks so you join less than a million dollars of ARR. One thing that is a topic that CEOs founders bring up with me regularly is this idea of we have a more technical sale or we sell in like some specific space and then solving for somebody with that type of domain experience. And so you're somebody who both with the experience at Axway and then also being an engineer just by education are far more technical. How do you think about that playing into you being selected for the role of CRO? And do you have some like guidance that you might provide to other around if it's a more technical sale to a more technical buyer, solving for that in the sales leader?

Yeah, no great questions. First off, our company was founded by seven PhDs from Berkeley, right. So some of the smartest people I've ever met. And I think in general if you have a really technical product, most of the buyers, if they're technical buyers, they want, they don't really love talking with salespeople. So you have to add a lot of value on the technical front. You need to know your stuff. They don't even necessarily trust all salespeople. I think inherently, I think if you look at Silicon Valley, even lots of founder technical CEOs and I really think like having a technical CRO for a technical company is really important. I could say the same for domain and whatever you're selling. But for sure in, in the technical space that I'm in, having an engineering and a technical background and having known very technical sales and technical products is not just a big part of kind of my background, but a big part of our sales team. Right? Like I would say most of our salespeople are more technical than most. We're still going to focus on business outcomes and how do you sell to the C suite and all those things. But knowing the technology and being able to add value I think is really important for a technical company and technical sales team.

What I'm interpreting as a takeaway is my guidance on this to founders is something like I wouldn't over index on domain experience because oftentimes you're making a trade off for something else. And if you're selling into healthcare as an example and you only look to hire somebody who has sold the healthcare in the past, your candidate population is just extremely limited by that nature. There's only so many tech companies that exist in the world and how many of those are selling into healthcare? I think maybe the one nuance and I've heard this now both from you, but also somewhat regularly, even from Jason Limkin who is the head of Saster. A technical sale to a technical buyer might be its own unique category where domain experience or having an engineering background similar to yours is something you actually want to solve for. Does that sound right and is that the right, right interpretation based on what I said?

Listen, what does a salesperson do? They teach your Customers how to get value out of your product. Right. So if you're not technical enough to understand the product and understand how it works, it's hard to teach your customers how to get value from it. So even if your leader. Again, I'm a people leader. I try to hire the best people and motivate them and inspire them. But you're still gonna have to hire the right types of domain experts and the mix of those talents to be able to add value to your customer. I do think having a more technical background in inside of a technical sale is an advantage for sure. So.

And do you. Last question on this and we'll move on to the theme of the episode which is scaling. Does your. Does the makeup of your sales team today skew people with more technical sales experience or do you also hire sellers with non technical sales backgrounds?

We tend to hire mostly technical backgrounds, but as our customers get larger and larger, you start to get global account managers. They're going to have much more business strategic account management. Similar to most structure of technical sales team. We have account executives and solution architects and SDRs and specialists and every function and the mix of those functions. I would say RSAs tend to be very technical. A lot of them can code, they can do POCs, they can do pilots. They're not just doing demos. And we expect our salespeople to understand the technology, not just be able to bring in the right resources. As you get bigger and bigger in our customers, see our a hundred million plus customers where a lot of it's around how do you organize around C level contacts and organization, navigate the organizations. I think you can be less technical and more kind of vertical domain. So we have a mix of both. But I definitely think as we've scaled an advantage from the early days was having a very or a more technical sales team for sure.

Okay, it makes sense. So let's just segue from there then to those early days. So you join the company is less than a million dollars of ARR. You have a technical background so you're probably spending a lot of time customer facing speaking the language of your buyer. Let's start with how did you acquire the first set of customers for databricks?

Yeah. So think about early days. We're open source databricks. Founders created Spark. Right. Part of the reason I thought databricks could be a massive success was everyone's using Spark, they're using the open source and step one was just go talk to a bunch of the users, find out what would they pay for. Right. What are Some of the challenges and what has the most value and what's their propensity to spend and things of that nature I hired from my network. I hired some of the best to just go and do discovery and meet with customers and understand where we could add value. And that kind of helped educate then our product strategy and our monetization strategy and our pricing strategy and literally a lot of our early customers were just open source free users that we developed relationship with that needed things in the product or needed additional support or things of that nature.

So you have a free version of the product, you join and you can see things like usage statistics, daily activity metrics, those sorts of things. And then you can cherry pick anything on the branding side or outbound side that was driving that free usage.

If you look at Spark as an open source project, it's probably one of the, if not the most popular open source project in the world. It still has tens of millions of downloads, right? I think building an open source product and then getting the community to use it and be behind it was one of the secrets, I think, of databricks like the founder, the founding team, that's literally what they focused on for the most part, right? They weren't as focused on how do I develop my revenue model and my pricing model. They wanted to make sure they got the adoption model and they nailed that with Spark. And then as we have evolved, we've done lots of other open source projects, right? Like Delta and ML Flow and we're an open source company, right? That method of how you develop open source, get people to both contribute to it and adopt it and use it, and then how do you then offer a service that's of value to customers that use that? That's honestly I think that's the open source model of the future. And I think databricks pioneered that.

So it makes a lot of sense. You have the unique advantage of having an open source product that when you come in as the revenue leader, you can take what are in a way like already users of the product and try and monetize them versus trying to generate demand from scratch with people in companies who probably don't know who you are at still sub $1,000,000 of ARR. Does that all sound right?

Yeah, exactly. And I think if you look at the future and you look at the projects that are coming out of most of the computer science and engineering schools, they're open source. So they're following that model, right? Get contributors, develop great products, let people use them, let people contribute them and then Figure out how do you then monetize and build a revenue model on top of that for sure.

Were you all intentional about whether they were open source users or early paying customers of the product in leveraging those customers to generate additional demand? Like how did you try and take advantage of the like customer affinity that existed for your company and product from an early stage?

Yeah, we had a massive community, right? Like we did our first. We used to call it Spark Summit. It's now Data and AI Summit. If you look at the strategy of the company, it was like make databricks the best place to manage Spark. And then it was make databricks the best place to manage data. And then it's make databricks the best place to manage data and AI. And so we've stayed to that. But our community was thousands and thousands of members. Like I would go like just to tell you a story, first month I was here I was like, hey, we have to be in financial services. So I went and set up like 10 CIO meetings on Wall Street. I took all the founders out there and I would tell em like hey, I'm bringing the creators of Spark, would love to meet with you. And it was crazy. Like I get the meeting with the CIO like next week, like that never happens. And then we'd show up and a hundred people would show up and they would want to sign autographs with the founders because these guys are iconic, like open source computer people in terms of that project again. So like that kind of free user, open source user community was already growing. So how do you then tap into that and understand, okay, what's the business model that allows you to then add a ton of value on that to your customers? And step one is go meet with all the as many of those customers or their users at the time, meet with those users and understand what are the biggest things of value. And as we've evolved now the founders have an amazing vision about what does the entire data and AI space need for a fully managed integrated solution. Right. And our innovation scale is just second to none at this point.

So here's what comes to mind, maybe as a takeaway for the audience. It's something like take advantage of the unique advantages that you have as a business. And so you had founders that in your target demographic were famous because of the products that they had developed. And when CIOs had the opportunity to meet the developers of this product that they had a lot of affinity towards, it was an opportunity that they wanted to jump on. And even you have Technical founders that probably aren't go to market oriented. You leveraged them to generate a bunch of revenue and get meetings with CIOs of some of the largest enterprise software companies in the world. That's going to be unique to databricks. Not everybody has that specific environment. But everybody does have something that is unique about their business. You could have been in YC like Brex. We really took advantage of being in YC and constantly hosted events and constantly put our founders in front of the other YC founders. Figure out what that that thing is for your business and then really play to your strengths there.

The other thing we did two early days was a 16Z Ben Horowitz basically that's how I got introduced to the company. And a 16Z. They have a lot of those kind of go to market motions where they'll set up basically a forum for you to present to large enterprises. I know not everybody has maybe a VC backer but those programs are incredibly valuable. Sometimes people like outsource them to a salesperson or delegate them. I used to do all those myself. Right. If I can get the access to Apple or Capone or somebody like that, their CIO and their whole staff and I get 20 minutes to present, I want to do that because that's going to open doors. So take full advantage. I think the VCs have amazing connections for their portfolio companies and we found a lot of our big enterprise customers through that channel. Early days.

Yeah. I think really smart. And I was having lunch today with a VC and this was one of the topics and it was like he was surprised at how little his portfolio companies leverage him for introductions. And he used this example of one that is doing a good job of it and he introduced them to their four largest customers.

Yep.

And I think the way that most founders, early sales folks just startups broadly try and leverage investors is something like you send your monthly investor update and you say something like do you know any CIOs at Fortune 500 companies that you can introduce me to? If so please make the intro whatever's the right target ICP for the company that they're selling into. The way that you should do this is you should just make it so easy for your investor. You send them a appointed email and it's hey, I know if it's another startup I see that you invested in rippling. Would you mind introducing me to Parker? You can forward him this email. He this is a quick blurb about what we do. Would love to get introduced either to him or maybe like his cfo. Let's say you're selling a finance.

Yeah. Make it easy, make it specific. Most people want to help. Your VC wants to help you for sure. And most of the people that are the VC is connected to, they want to help too. They want to meet entrepreneurs, they want to see cool tech. So make it specific, make the ask easy. I take my lots of 20 minute meetings to meet new founders and CEOs and CROs. Cause I, I'm an entrepreneur. I love that stuff. I think it's super interesting.

So very cool. Let's continue down the path. You said something like in the early days you were flying to New York, meeting with some of the biggest banks in the world. Which leads me to when you started building out the team. I think you're in Phoenix, I think databricks is in San Francisco. Were you building a field sales organization? Did you have an inside sales team? What was the calculus for how you determined where folks would sit?

Yeah, we did both actually. So like our headquarters were in San Francisco, so I would go up there every other week for the whole week and the other weeks I'd be on the road to New York and London and wherever. We built out an enterprise field team. When I got here it was mostly just startup folks. So we had call it a hub in San Francisco. Mostly inside sellers. We were trying to sell to all the smartest Silicon Valley tech companies, which is actually pretty hard. A lot of those folks like to build their own stuff, right? They're early adopters of tech, but they're also like harder to get big dollars out of early in a company. So part of my assessment when I came here is like enterprises are the companies, they have big dollars but they need the most help with data and AI. So I built out the enterprise field team. I think probably in the first quarter I probably hired 40 sales folks because I saw the kind of demand that I thought and we, we had some big revenue aspirations, but we built both. I would say, I think you want to decide, is your product a big ticket item where you need all custom stuff, or is it, you know, something you want to start in Silicon Valley? We decided to do both because we saw the opportunity in both. I do think your inside sales team should be together. I like the bullpen concept. I think they need to learn from each other, they need to feel the energy from each other. But yeah, so we built out both to start and both have been incredibly successful for us.

Makes sense. Okay, let's talk a little bit about pricing. Another topic that comes up pretty regularly in conversations with founders and as companies are scaling. So you all started with an open source product that's free and then there's a few different models. You can have contracted pricing that's oftentimes like license based or seat based. You can have consumption based. So how much of the it's like usage you also have outcome based. So something that's oriented around a specific outcome for the business. Talk us through a little bit of the evolution, how that worked at Databricks and then we'll maybe like a continuation of that would be something like knowing everything that you know now. Would you have done anything differently there?

Yeah, no. Good question. First off, like we used to have lots of fun long debates about pricing with the whole founding team because it's super important you get it right. We were consumption based. I mean we're cloud only, right? We provide a cloud service, the open source product, you can use it on prem, you can use it wherever you want. Our cloud service, it's only in the cloud. We're consumption based. And when we looked at different business models, first of all like that's how most of the cloud call it aws, Google, Microsoft, so it made sense to our customers. It has to make sense to your customers. They also have to know how to value it. So in a lot of our sales cycle I taught, hey, how do you, what's the value of this, the customer, what's the business outcome? Because they have to be able to understand, okay, does my pricing model kind of match how I get value? And so for us like the more data you have and the more queries and the more analysis and analytics you can do, the more value you're going to get out of it. So having a consumption based model makes a ton of sense. And also our baseline continues to grow. So as people get more and more data and more and more queries, our revenue grows as well. Right? Which I think is a way superior model than a licensing or a seat based because eventually you might run out of users. For us, data and consumption continues to grow, but it depends on your business model. But that's what made sense for us and we stayed true to that. Today we would publish our list pricing on the website still out there, very transparent. Again we're engineering driven company so pricing's pretty transparent. And yeah, I think one thing, your second part of your question was like what's one thing looking back that maybe we might have done differently? We started with really simple pricing, right? Like maybe two SKUs and then we did an add on and now we have fairly complex pricing cause we have lots of products. And so thinking through what are the biggest value points, propensity to spend in terms of how you make your packages. Because the trade off is do you make your pricing super simple and make it easier for customers to buy or do you make it super complex and try to capture every dollar? I think we did actually a pretty good job starting simple and now we're getting a little bit more complex just with the product complexity. But that trade off I think is something you really want to look at because what you don't want to do is have to keep redoing it every year or every couple years because it'll slow you down. I think being super thoughtful on your pricing, packaging, especially your packaging strategy, is really important.

That's great. One thing that stood out among a lot of things that you mentioned that I think are good takeaways, you said there was a bit of, I think AWS and maybe other like cloud data providers in this space had already standardized on this consumption model. And so for you, you were selling into a buyer who is probably used to paying for a product and service like yours in a certain way. And so trying to innovate on pricing can add additional friction or be disruptive to the selling or buying process, depending on which seat you sit in. Like innovating and pricing is probably not the right thing to do. Is maybe like one takeaway from something that you said.

Yeah, I would innovate on the packaging. Right. Like how do you package things? Again, our base parameter on consumption made sense for our market. But how you package those SKUs to make them easy to buy. Like this type of buyer likes to buy this make it easy for them to buy at this price point. This type of buyer likes these features, package them together, make it easy to buy at this price point. I think you should think through your packaging strategy and innovate there. I think that's smart, especially early, early stage.

So makes sense. Let's talk about customers. You now have a massive base of customers and I think there are a lot of things that come to mind in terms of how you can leverage customers to improve the business. There's things like incorporating their product feedback. There's things like creating a community within your customer base and really developing some brand tailwinds from that community. There's things like leveraging your really happy customers for referrals to generate additional revenue from new customers of those things. What comes to mind in terms of things that you've done a really effective Job at Databricks and like how early would you think about trying to incorporate some of the things I just mentioned?

Yeah, no, first of all, creating community among your customers, super important, right? Depending on what type of business you have meetups or industry roundtables, like the your best selling mechanism is having a really happy customer sell to a prospect. That's your number one thing. So setting up environments where you can do that I think is super valuable. We had the advantage of having these really large open source communities like Spark Summit where we bring thousands of users and customers together. But even early on we did things like product advisory board. We're very customer obsessed. Right. So you're going to get a lot of innovation and other ideas from your customers. You never want to do like a one off but if you hear something from 20 different customers, put in the product. Right? And those customers want to feel special too. They want to be part of the rocket ship, right? So bring them in, make them part of your family, make them part of the product advisory board. We do a lot of industry roundtables which I think are super valuable. So especially for the enterprises like for pharma, like they're all doing similar things with data and AI for our space. So they want to learn from each other, learn the best practices. It also creates this FOMO inside the industry to get people to move faster. Those were the things we would do around using customers as part of that community to build your brand and that's been really effective. I think our customer events are exceptional. We have a data, a world tour, data and AI world tour now where we go to each city and bring thousands of customers together. And like I said, customers learning from customers is like your best selling mechanism for sure.

So awesome. You have lots of events, you probably include existing customers, maybe have some prospective customers that attend those events also so that they can meet one another like minded folks and hopefully the keynotes and.

We do panels and we do. That's pretty normal stuff, but yeah, exactly.

Awesome. All right, let's end on. You've now been in the revenue leadership role for nine years. If you can go back to day one and tell Ron on day one, starting at Databricks, some advice given everything that you've learned thus far and maybe more in the abstract for early revenue leaders that are joining a startup at a million dollars of ARR, hoping to follow in their footsteps to be the next pre IPO company. What, what's that advice look like?

Yeah, first off, my biggest piece of advice for any revenue leader or leader in General is like I said before, hire the best, inspire em, motivate em, mentor em. Pretty pretty basic stuff. But in general, I think grit, early stage in the company, like getting from that 0 to 10 million is gonna be different than 10 to a different than a hundred billion. You need to adapt at each stage if you want to move on to the next stage. That means different leadership, different processes, all those kind of things. But early days, it's a lot of grit and prospecting and pipeline build. And I always say pipeline's effort, right? So get the right people on your team that are highly motivated, working together to make it successful together. Work on culture, early start, set those things right. And if I had to give myself advice, would've been invest even more early when you. I think we could have grew even faster. We were always looking at productivity and all those things. But again, you're trying to look 12, 24 months out based on ramp times. When you see you got product, market fit, step on the gas. But yeah, establish your culture. I think hard work beats talent. Tons of grit, early days, and yeah, good luck.

I love it. Feedback that resonates with me. And I'm sure a bunch of folks listening in also. This was awesome. Thank you for taking the time, Ron. Appreciate it. And thanks for all of y' all for listening in. Take care.

Thanks, Sam.