Lessons Learned in Scaling Early-Stage to Hyper-Growth Companies: From VMware, AWS and Databricks

So my name is Ed and I've been asked to spend a little bit of time with you this afternoon talking about scaling hyper growth technology companies. And in particular I need to emphasize that my experience is specifically with scaling B2B hypergrowth technology companies. A little bit about myself. I've had the rare privilege now of working for three hypergrowth technology companies. I started back in the early 2000s with a company called VMware. And this is back in the days when people didn't quite accept this idea that a virtual machine could be as good as a physical machine, let alone better. That they wouldn't just end up virtualizing their server infrastructure, but one day they would virtualize their data centers. They would virtualize absolutely everything. And it would lead to the next big revolution in technology, which was obviously the emergence of the public cloud. And so back in 2011, I got the rare opportunity to go and work for a company called Amazon Web Services as they were starting to set up their business here in apj. And I spent the next eight years running around Asia Pacific and Japan and then spending some time in the US thinking about how we could bring the promise of the public cloud to customers all over the world. We saw a tremendous amount of growth. And then suddenly three years ago, I was running the AWS business across all of Asia Pacific and Japan. We had revenues in the many billions of dollars. I had thousands of people working on my team and, and I realized that none of that was making me happy in any way. That actually I'm much more interested in building businesses than I am in running businesses. I'm not really interested at all in running businesses. And so I stepped out of Amazon Web Services and I said, look, if I accept this idea that I'm at my happiest when I'm in a serviced office, how do I get back into a serviced office and go and spend time with a company that really needs my skillset? Because my skill set is a very, very specific thing. This is what I know how to do. I know how to scale at a very, very high speed. Large go to market organizations, particularly in Asia Pacific. And so I thought, okay, well what's the recipe? What does a pre growth, high potential technology company look like? Is there a formula that I'm looking that'll predict that kind of success? And it turns out there is, right? Turns out you can have a pretty good idea about the size of an opportunity and the potential rate of growth of a technology company if you look at just a few things. The first thing you want to look at obviously is the tam, is the TAM for databricks, which is effectively the entire TAM around data. Think ETL and machine learning and BI and data warehousing and streaming and governance. Is that a big total addressable market? And obviously the answer is yes. And so the next question you ask yourself is, is this market needing disruption? Is it a particularly inefficient market? Is it a particularly messy market? And again, in the case of data, the answer is absolutely. I mean, customers, data architectures today are an incredible mess. They're unbelievably complex. They scale silos of architecture, they have massive amounts of legacy. And so that absolutely ticked that box. The next thing though, you need to ask yourself is, is there a technology that I can work with that's not just disruptive, but is it on the right side of history? The one thing I've learned in the time that I've been selling technology and building out go to market organizations across APJ is there is no point pushing the ball uphill. There really isn't. You have to make, as Jeff Bezos used to say at Amazon, you have to embrace the tailwinds of technology. You have to be doing something where the ball is rolling downhill. And when you are absolutely on the right side of history, all of the companies I've worked at, VMware, Amazon Web Services, and now I hope databricks, they would have been successful with or without me. There was an inevitability. Customers were going to virtualize their data centers, people were going to consume technology as a utility. And it's that inevitability that you want to start to position yourself in. And then the final thing, do you have a growth mindset? Do your founders have a growth mindset? Do the executive teams inside your organizations think that one day you will be a really, really significant company? You know, again I think about the databricks experience. We've raised over $3 billion in funding. Our CEO talks about the idea that he's going to take the company public one raise at a time. And we take that money and we use it to build out a global organization. We have now a team of over 4000 Databricks folks right around the world. And as far as we're concerned, it's really just the beginning. And so when I started to look at those things, I joined databricks and I thought, let's have another go at building out a go to market organization across apj. We were a small group of folks three years ago when I started and I assure you we're a lot bigger now. And so if you think about these three journeys and you think, okay, well in that career that I've had working in these organizations and helping scale these organizations, were there any particular things that I learned that might be useful to you if you're looking to do something similar now or hopefully in the future? And when I look back at the career and I look at various points on my career, I suppose it started when myself and three other people started up the VMware business in Australia and we started to talk to customers about building, about building virtualized data centers. And the key thing that I learned as part of that experience was that the commercial models that you choose to build and offer to your customers not only define the the way that you will think about go to market, but similarly you need to marry your go to market efforts to specific commercial structures that you as SaaS companies decide to offer your customers. So let's think about some examples there. At VMware, really early on we said we're going to price based on the physical CPUs that our customers choose to run VMware on. That made us a hugely transactional business. I'm going to run it on five servers. I'm going to buy licenses for the CPUs inside of those servers. If I need to buy some more servers, I'm going to call Ed, I'm going to go and buy some more CPUs. It also constrained our growth hugely because we couldn't grow any faster than the rate at which our customers were choosing to buy physical servers and install VMware on them. And so we changed all of that. We said, what if we move to some notion of licensing contracts, of enterprise wide licensing? And that changed the entire discourse that we were able to have with our customers. Suddenly we were selling business value, suddenly we were selling potential. Suddenly we were selling aspirational concepts. And we're able to think about tco. We were able to think organization wide. And at databricks we've been going through the same thing inside of our organization. We used to be an organization that spoke to our customers about committed contracts. How much databricks will you need over a period of time? How do we get you to commit to that contract? And we will then sell you that contract and you can consume it over the next 12 months, consume it over the next 36 months. In order to do that, you need a go to market organization to support that. And effectively what we're talking about is traditional enterprise sales. You want to have an enterprise sales organization that will go in and that will inject as much friction as they possibly can into the process to do two things. To grow the deal size and to defend the margins and defend the pricing that you eventually get in front of your customers. And then at the beginning of COVID we decided to change the whole company. We said we're not going to value that anymore. We want to be more customer obsessed with. And so we pivoted the entire company to a consumption model. That's really important, right? Thinking about the commercial construct you will have with your customers is critical. But at the same time, then we had to pivot the entire go to market organization. Because where enterprise sales is about injecting friction like value engineering or proof of concepts or business cases into the sales process, when you move to a consumption model, it's actually about removing friction. It's about doing exactly the opposite. How do I enable my customers? How do I build capacity through partner ecosystems? How do I make the buying experience focus on starting rather than on committing? How do I do things completely differently? And we had to think really, really hard about that. And so I think the lesson there is make sure that you think a lot about commercial structures, but then you build a go to market organization that actually is invested in and facilitating that commercial structure for your customer. From there, I was actually sent up into this part of the world and I spent quite a few years up in this part of the world in Singapore, building out Southeast Asia as an organization for VMware. You're thinking now about how do I move into new countries, how do I go and take on a market of 8, 10, 12 countries? And what we realized was that country maturity models are really important. It's not enough to take the advice of typically Silicon Valley based VC companies and say, well, build a productivity model around hiring salespeople, assign productivity to salespeople and scale your organization in that way. Because it turns out the earth is not flat in that way. I think the best way to think about building country maturity models is to go back to Geoffrey Moore, is to go back and think about the work that was done in that seminal book, Crossing the Chasm. I hope you've all read it. If you haven't, you really want to do that. It's necessary in every new market that you work in to go in and soften the beach, to create the conditions where not just product market fit, but where demand is actually starting to be facilitated. And to do that, you want to expire, expend as little energy as possible, as little investment, as possible and you want to learn as much as possible. And so we came up with this model where we said we're going to start with something called a minimum deployable unit as our country expansion model. What is the smallest amount of resource that is cross functional, that is specific to that market, that will allow us to see success in that market, that we can invest and put into that market, to start softening the beach to create those first few partnerships, to set up some kind of resale mechanism if we require it, to think about acquiring those first lighthouse customers and to really start to get things moving so that we can then start to cross the chasm and we can then start to make big bets on that market. It's warmed up, it's prepared, it's ready to go and you cannot miss that step. Once you've done that though, you earn the right to move to the next stage and to invest in something called a market making unit. A market making unit is suddenly no longer just one salesperson, one solution architect, maybe a partner manager or a business development representative. A market making unit is you now saying, we fixed the demand side, we have all of the demand signals coming from a particular market. Let's now work on the supply side. Let's make sure that in that market, say Singapore, we have all of the supply side capabilities that our customers are going to need in order to be successful. We know that they're going to demand our products. So now we're going to turn up with the right leadership, we're going to turn up with support, we're going to turn up with professional services, we're going to turn up with training, whatever it is that you decide you're going to need for your business. But going through that market maturity model and thinking about how you can start with a minimum deployable unit and then thinking about how you can move to a market making unit will save you a lot of time and hopefully save you a lot of money. And so from there, From there I went down and took a role building the business for Amazon Web Services in Australia. It was a brand new business. I think we did $10 million in our first year running a few websites in 2011 for Amazon Web Services and we were fairly crude in the way that we thought about our customers. I'm sure many of you think about customers as enterprise customers and then maybe you think about mid market and then maybe you think about commercial customers and it wasn't a really thoughtful thing. And the reason that that was dangerous, the reason that that was the wrong way to behave is because you have to sell to customers in the way that they want to be sold to and you have to let them buy in a way that they want to buy. Now don't get me wrong, I'm not suggesting that you should infinitely segment your customer base because you shouldn't segment your customer base at all if all of your customers are uniform. But if there are some valid discrepancies in the way that your customers wanted to be sold to, you should acknowledge that and you should segment your customers really, really thoughtfully. So in our case at Amazon Web Services we said, okay, well we have enterprise customers and we have mid market customers and we have commercial customers. Turns out we were totally wrong. It turns out that what we had was enterprises and then we had this other group of customers called startups and digital natives who were kind of these successful startups and they wanted a completely different sales motion, they wanted a highly technical motion, they wanted to do bottom up selling, they wanted to create these democratic, these democratic movements in their organizations. Maybe they wanted to be sold to on Slack and on various chat forums as opposed to directly and face to face. And the last thing they would need is a proposal. Whereas the enterprise customers, they wanted all of those things. We also worked out that we had a whole group of customers called ISVs that there were software companies who wanted to build their technology on our cloud and ISVs they needed to be sold to differently as well because what did they care about? They cared about go to market. How can we help them, not just host their applications but actually help them go to market on our platform. And so we, we resegmented our whole business and it changed the way that we worked with customers. It really transformed our business significantly. And now today AWS thinks about the market purely in those terms because that's what the customer obsessed thing to do is. And at databricks we've done similar things at databricks. Now we work specifically with digital natives and startups in one way. We have specific teams for that, we have mechanisms that we've invested into support support them. And then we work with our enterprise customers in a totally different way and never the two will meet. From there I got a rare opportunity to think about how we could build a global accounts organization for Amazon Web Services. And by a global accounts organization I mean an organization that was just dedicated to selling to one type of customer which were the top 75 largest multinationals in the world. Think Unilever and Shell and Chevron, Rio Tinto and so on. How do you go and build an organization that will become expert at doing this. And you know, once we decided we were going to create this segment and we were going to make a big investment here, the thing that I realized was that understanding the journey that those customers would go on with Amazon Web Services was really critical because if we didn't understand the customer journey, then we wouldn't have the slightest idea about how to go and start them on that journey and how to then go and facilitate them through the various steps. And so we spent a huge amount of time thinking about that. In fact, it was totally mystifying to me. I would work with a customer like Philips in the Netherlands and I would spend time helping them into the cloud and moving them through these various phases and I would try and work out what are the patterns that we're seeing with these customers. And I couldn't find any consistency, any consistency at all until I worked out that the customer journey, it doesn't have to be this linear thing. Customers don't need to start at the beginning and then finish at the end of this customer journey. There can be different paths, there can be different points of entry, and if you're smart, you'll think deeply about that and you'll work out what those are. So it turned out that for these large multinationals, there were actually two different points of entry, two completely different paths that they would go on. One would be this path of innovation. How can I go and spend time with the business? How can I help them understand that we could facilitate some kind of dividend to their top line revenue if they were able to innovate faster, if they were able to build products faster or affect some kind of efficiency dividend by digitizing a business process. And these discussions were almost always innovation driven. They were almost always with the line of business, but that was only a small piece of the puzzle for us. The other piece for a particular multinational was how do we help you go and retire the huge amounts of technical debt that you have in your organization through migration and modernization? That was the stuff that no one was actually really interested in, but it was the vast amount of effort and, and it was where the vast amount of money was. And for that you didn't spend time with the business and you didn't talk about innovation. You spent time with the IT teams and the global CIOs and you went and spoke to them about how they could save money and drive resilience and remove risk by retiring the technical debt inside of their organization. And as soon as we worked this out as soon as we worked out that there were two customer journeys and mapped out exactly what they were, we could then start to say, well, how can we affect that? And the second message I'd have for you on this, the second area that I learned as part of that was if you're going to be customer obsessed in the way that you work in the market, you need to let customer informed tactics actually drive the strategy. You need to be constantly experimenting everywhere in your global go to market organization and you need to be running experiments with the customer, getting feedback from the customers and saying, well, does that work? And if it does work, if it drives the outcome that they're after, which is the outcome that you're after, then you need to be saying, how do we scale that? So let me give you some examples of that. We said that we needed to help the businesses of these large multinationals in innovate faster. That was part of our customer journey. Well, we spent a lot of time with that customer Philips that I mentioned and we started to talk to them about how we could maybe take some of the mechanisms that existed within Amazon around innovation. How do we build new products? How do we go through ideation processes? Amazon is very famous for this process called the prfaq, where you effectively write the press release and an FAQ of something you're gonna build even before you start to build it, so that you can start to think about the effect it's gonna have on your customers. We took Philips through that process. They loved it, they started building new products, they started building those products more importantly on Amazon Web Services. And so we said, hey, let's scale that. If they're getting a great outcome, let's scale it everywhere. And so we built our teams right around the world whose only job it was, was to help these large multinationals ideate, innovate, build products, build prototypes on top of Amazon Web Services so that we could remain relevant to their business. But at the same time, we needed to think about that second part of the customer journey. We needed to think about how we could help IT teams remediate their technical debt. And so we created this methodology called 50 and 50. We spent time with the CIO of Honeywell and we said, hey, rather than spend a huge amount of time planning a migration and starting to work through this migration and maybe in two years we'll have migrated assets and we'll know what we're doing. Why don't we just start today and why don't we say in the next 50 days from a standing start with no skills on your side of the fence, we will migrate 50 applications. And in doing that, we will build all the skills that you need, all the capabilities that you need inside of your teams to migrate the next 5,000. It worked. We got 50 applications migrated in 50 days. We built out all the skills. And so we said, okay, let's let those tactics now inform our strategy. And we built an entire program around that, rolled it out globally, and we helped hundreds of large multinationals migrate thousands and thousands of applications to the public cloud. Once I was done with that, I came back to Asia Pacific and I took a job running, running quite a large organization, running Amazon Web services across Asia Pacific and Japan. At that point, we were talking about thousands of folks in the team, we were talking about billions of dollars in revenue. And you're starting to think then about how do I make investments, how do I make sure that I'm getting as much bang for my buck as I possibly can as I hire another 500 people, as I really start to scale this organization? And what we learned was you need to be incredibly thoughtful about understanding the difference between linear and nonlinear investment. Do not make this a game of linear expansion. Do not say, hey, I'm going to have a productivity metric that I assign to salespeople in my organization. I'm going to just keep hiring salespeople as I want to scale revenue and one day end up like so many of the technology companies that you've seen over the last couple of months who just start laying people off. That is a terrible decision to make. Think about how you can make as many investments off your balance sheet by partnering, by investing in specialists who can act as the batters for the catchers that you've invested into the marketplace. Who are your salespeople? Think about the mix. Think about how you can make these non linear investment so that hopefully when you see huge success in your business, you don't just wake up one day and think, gee, I have 10,000 salespeople and everything that goes with 10,000 salespeople in your organization, who do I need to start laying off? Super important that you get that balance right. I think the final thing I'd say about scaling field organizations is you have to have strong beliefs. And then when you have those strong beliefs, you need to find a way of communicating them across an organization in such a way that as it scales and as it gets bigger and bigger and bigger, the decisions that are founded in those strong beliefs can actually be made without you being in the room. And the best way that I've found to do that is to write tenets is to write down what those beliefs are and make sure that everybody has access to them so that they can use those to ground the decisions they made. And actually I went and found out, hey, what were the tenants that I used, or at least what were some of the tenants that I used for scaling the field organization at Amazon Web Services four or five years ago? It doesn't really matter what you think of these tenets. It doesn't matter if you agree with them. The thing that matters is that you have these beliefs, that they are written down and that you spend time crafting them and that you've then distributed them broadly across your organization so that everyone can buy into it. So I guess finally we need to think about how we bring this all together. How do we actually scale a global or a really large field organization across Asia or around the world? We've said we're going to understand what's going to drive my growth. We said, hey, we've got a large tam, it needs disruption. We're going to disrupt that market because we're on the right side of history, because we've got the right technology. We know that this is something that we should back, that we should invest in this. We're going to build a large organization around it. And if you do, I guess the summary of my advice to you is first of all, build a commercial model that is best for your customers. But if you do that, make sure you have a go to market approach that is specific to that commercial model. Otherwise it's just not going to work. Don't bring enterprise sales techniques to consumption businesses because the two are actually diametrically opposed to one another. Think about country maturity models as you start to move out of your own country. Go and read Crossing the Chasm and think, okay, how do I go and work with those initial innovators in a market? How do I inform my experience and soften the beach? But then how do I cross the chasm and move it to a conversation around building up the supply side capabilities that I need to ensure a fantastic customer experience in the markets that I serve? Segment your business only if you have to. But you have to. If you have customers who wanna be sold to in different ways, that's a really, really important thing. Otherwise that is gonna start to constrain your growth. Think deeply about the customer journey and then develop tactics that can inform the strategy that you will bring to bear. Helping customers start that journey and facilitating their process and progress along that journey. Invest in not just linear resources. Otherwise prepare to do large scale layoffs if you're successful at any point in time. But invest in nonlinear resources as well so that the go to market organization that you have to a large extent does not sit on the balance sheet of your company. It'll be the best thing you've ever done. And then finally use tenants to drive velocity. Make sure that the beliefs that you have are strong, are well understood, and that those tenets are your guiding path as you build out what I hope will be a really, really significant go to market organization. So thank you very much for your time today. Just a couple of things. If folks wanted to find out more about databricks, I think for this crowd in particular, I would suggest having a look at the Digital Native Council that we host for our startup and Digital Native customers who want to think, how do I use data to actually build my company? How do I use data to build my SaaS platforms in the way that Atlassian, for example, in APJ have done over the last few years? We'd love to have you participate in this forum. Looks like I have 13 seconds if anybody wanted to ask any questions. And if you do, I've been instructed that you need to use the mics. Thank you so much.

Yeah, my question is, are consumption based models really that different when you have a minimum commit or an anchor price as compared to traditional subscription?

I think a consumption based model implies that you don't have a minimum commit, that you're trying to make the experience as frictionless as possible. So if you look at the databricks context, you can go to the AWS marketplace today and you can just start using databricks in a purely consumption model. Because we want to try and remove as much of the friction as we possibly can from that experience.

Yeah, but people always complain about the end of the month bill they get for AWS and other things. How do we make sure we avoid those kind of conversations?

That's a whole different discussion. I mean, consumption economics is the way to go, right? Consumption models are the best thing for your customers, full stop. The problem that you've got though, is there's a big difference between only pay for what you use and only pay for what you need. And you do have to end up as an organization investing quite a lot of money in helping customers move from one to the other. And that's another half an hour that we could spend talking about that. Yes, sir.

Hi, here we are. I have a question. It's about consumption models as well, but it's to do with selling something that's consumable digitally, but also as part of what you're selling, you have a physical product. And you may have come across this with customers and things, but I thought I'd throw this one out there. So if you apply the consumption type model into physical product sensors, if you like, out there in the field using a cloud digital service that you can use, a consumption model on the physical side has a different story to tell because you might have to get a lot of units, physical units out into a field which come at cost and the consumption of that is different to a digital consumption. So have you seen that handled anywhere?

I have, yeah. I mean, again, go and look at the Amazon business, right? So AWS has physical devices. They have something called Snowball. Snowball.

Snowball, yeah.

Snowball, I think it is. Which is a device that they'll actually send you. It turns up and you can then put your data onto it and send it back to them and they upload it to the cloud. That's a physical device. But the customer doesn't care that it's a physical device. What the customer cares about is that it's a service. It's a service that's facing, facilitating me in a massively secure way, getting my data up into the cloud. So that's what you have to build the commercial model around. Not around the fact that, hey, I'm investing in a physical device and somehow somebody needs to pay for that physical device. So think about the problem you're solving, think about the service you're providing the customer and build the model all around that. Sa.