Datadog, Inc. (DDOG) Earnings Call Transcript & Summary

All right. Thank you, everyone, for joining. Welcome to Day 2 of the Morgan Stanley TMT Conference. I'm Sanjit Singh, software analyst -- Infrastructure Software Analyst at Morgan Stanley. Super pleased to have the management team of Datadog. We have CEO, Olivier Pomel; and CFO, David Obstler. Thank you both for joining us.

To kick off the conversation, you're coming off a very impressive year, 70% revenue growth. You're up to 19,000 customers. You also did a 16% operating margin, which I'm sure David is very proud of that. Oli, if you think about how the business has performed coming out of 2020, the pandemic, going into 2021, in what views -- in what ways have your views on the business and on the market has changed? And what ways have your views on the market been sort of reinforced by what you've seen the last 2 years?

Yes. So my view in the market haven't changed a lot, actually. I think we knew entering in 2021 that digital transformation was here, cloud migration was here. In many ways, for us, 2021 looked a lot like 2019. If you look at the -- whether it's the growth rate, the cloud adoption, the rest of the economics of the business, it's very similar. So what this tells us is that we're still very early in this transformation. In terms of what we, I think, comes up reinforced from the year, first is that this transformation is broader than we thought. Like, we've seen it touch more parts of the economy during the pandemic, and it's far from done, so we've seen reinforcement there. And more specifically about us at Datadog, what we've seen is we've been able to solve a bigger and bigger problem for our customer to really expand the product footprint. We put more products to market. We've got more adoption of more products across the platform, and so we feel very confident about our ability in the future to keep doing that.

Makes a lot of sense. And David, from your perspective, as we looked at 2021, what evidence did you saw in the business that gave you a sense that you're not only recovering from the pandemic, but that some of the underlying trends are actually kind of more durable just beyond a sort of cyclical recovery after the slowdown in the summer of 2020?

There are really 3 metrics that we're watching in driving the business. The first is our clients' usage of the products. And we saw, as we mentioned on the earnings call, we saw that resumed to normal and then be very strong as the year continued. And that's an indication of our clients' concentration on cloud migrations and digital projects. So that metric was strong throughout the year and ended the year on a very high note. The second is the cross-selling and the adoption of the platform, as we've introduced more products, our clients adopting that. And all the metrics there in terms of clients landing and clients expanding, we're very positive as the platform expanded. And the third would be new logos, new customers who are starting their cloud journey or greenfield opportunities. And I think, as we mentioned, we saw a lot of new clients focusing on projects and using Datadog, and all 3 of those metrics were positive as we went through 2021.

Makes sense. And one of the questions that we've been getting a lot, frankly, the past couple of days, was really on the back of Snowflake's last earnings call. And what they sort of called out is that they are passing along some price performance, improvements on the compute side of the house and passing on some of those economics to their customers. Oli, I was wondering if you can talk us through how Datadog's pricing works and how efficient improvements, more broadly, at the cloud vendors impact your cost, your gross margins and potentially, your revenue.

So our model is actually fairly different because we charge according to the magnitude of our customers' own workloads, not -- we don't charge for the amount of compute or storage we consume internally. So when we actually get more efficiencies, which we do on an ongoing basis, you see it through our gross margins going up, but the price isn't affected by that. Our customers are still going to have a certain number of workloads over a certain size, are still going to expand. Of course, as the cloud provider gives them more types of instances or they can -- they get more opportunities to optimize their cloud consumption, but that's the motion that's been ongoing from customers for the past 10 years, and it's nothing new.

Got it. So let's talk about a little bit about the business more broadly. And I think the key mantra for the company is sort of breaking down the silos. For those who aren't familiar with the Datadog, can you explain what you mean by breaking down the silos? And how much progress when you look at your customer base have organizations made in terms of breaking down those silos between dev and operations, and ultimately, between DevOps, operations and security? Where are we in that curve?

Yes. For those of you who haven't heard the story yet, we're -- I didn't start Datadog to build a better monitoring company. That was never the goal. The starting point was that my co-founder and I used to work together. I used to run the development team, he used to run the operations team in a previous company. We had our teams fight all the time and single point all the time, and so our starting point was really how do we actually get those teams to work together to share the same reality, to have the same objectives, and so forth. And it turns out, our first use case is well, monitoring, but the goal was always, let's get as many data assets from as many parts of the company as possible, and then get as many users from as many different teams as possible to look at those data sets and have them connect so they share the same reality. So we started with dev and ops and it was the right time for that. In 2010, when we started the company, it was the very beginning of the DevOps trend. And today, it's commonly accepted that this is the way you should build your operations and development, but back in 2010, it was fairly new. And as we're developing the companies, we're developing the platform, we keep seeing more -- other areas, more teams that are broken down as separate silos that don't speak. I mean an example of that we've talked about recently is security. If you look at the situation in most companies today, the security teams are typically not in speaking terms with the development teams and the operations team because they have different objectives, they look at different realities, they have different stresses. What matters to the security team, they don't actually fully control. They don't actually control deployment, they don't control the application development. And with -- and on the other side of the equation, developers see security as a limiting factor. Like, they're the people who say no, who prevent you from doing your job, who chastise you when you make mistakes and things like that. So the problem we see there is actually very similar to the problem we've seen between dev and ops when we started the company, and there's many other areas we can get to this way.

Just wondering, like kind of larger enterprise segment like your Morgan Stanleys of the world, in terms of that breakdown the silos between dev and ops, where are they? How much further are they behind versus, let's say, your digital natives from your perspective?

Well, I would say the adoption of the -- or whether the realization that you need to bring different teams together outside of dev and ops. So dev and ops is done, like everybody agrees. It's still not implemented everywhere. Like many companies are still early in their implementation of DevOps, and they still have a long road ahead to make that happen in many organizations, but everybody agrees that this is the right way to do things. I would say when you move on to other areas of the business like security, for example, it's more of an emerging trend. Like there's this thing called DevSecOps right now, this whole movement around shifting left. I'm sure that's a word you hear all day long, but it's still fairly new. I think not everybody agrees what the right way to do it is just yet, but this is something that we expect to see develop over the next few years. When you look at the companies that implement that, the ones that tend to be first there are the cloud native, the companies that were born in the cloud, and then you see the larger enterprises starting to see the same.

Right. So for the enterprise, it's not a question of approach. They agree on approach, it's just about timing of the implementation.

It's -- that, timing, and getting everybody on the same page. Yes.

I think one of the most impressive things that you guys called out in some of the recent earnings calls is just the strength of the core, right? And I think a couple of quarters ago, you said that product area growth for infrastructure marketing has accelerated the past 2 quarters. There's a lot of runway there. Can you give us the reasons why you're confident that there's ample runway in kind of the core infrastructure monitoring part of the business? And how are you going to make infrastructure monitoring continue to keep its sort of pull position lead in terms of its market status?

Yes, it's -- we're still super early in digital transformation, as you know. It's really a transformation dimension of which we haven't seen since the Industrial Revolution, pretty much, so we're still fairly early in that. And then we're also early in the cloud migration that enables it and follows it. So it means is that most of the workloads in cloud environment just don't exist yet, and those are still to come. And this is one of the main drivers of our growth. In addition to that, if you look at the way infrastructures are evolving, they're getting more and more complicated. There's more complexity, there are more moving pieces, they move faster. There's -- a single developer is going to manipulate more and more and more different components. And so with this rate against complexity is really a transfer of value that is happening between the infrastructure itself and the understanding of it. So between the service providers, the cloud providers and the observability and monitoring part of it, which is where we are. Then the last major trend I would mention on this is that there are just not enough software engineers to hire for everyone, and this is not going away. It's getting worse, actually. The world is transforming. More and more is built in software. There are not enough software engineers, and so they need more help. They need more tooling. They need more ways to help them understand what's going on and extend their reach, and so we're going to see more and more of that. And all those factors combined give us great confidence that even our core product, the first product we released, is still very early in its life cycle, and there's tons more growth to be had.

On your last point around the scarcity of talent and developers and engineers, what do you think the implications are in terms of this category has a really large driving, open-source community as well? What's the sort of push/pull between build-it-yourself and then out-of-the-box value? And what are the sort of implications there for Datadog?

Well, I think the pendulum is going to swing more and more on buying versus building just because companies in general, not customers, in particular, will need to redirect their engineering resources to where it can make a difference for them in terms of their products, their offering, serving their own customers, differentiating themselves. So we definitely think that it's going to put more pressure on DIY and build-it-yourself initiatives in the future.

That's a very interesting dynamic. Let's talk a little bit about log management and APM. Those are products that are newer but have now been in the market for a couple of years. On your 3Q earnings call, you talked about log management and the APM suite together accounting for over $500 million in ARR. How have adoption patterns changed for these 2 products versus a few years ago? Are they becoming simultaneous land products alongside infrastructure monitoring or are they being adopted separately?

So the -- there's a lot of continuity in the way those products have been adopted. I mean of course, they're getting a lot more mature, which means that we see them in a more conversation with our customers, which means also that they are operating already at the largest scales possible. Like we -- whether that's on the APM side and the log side, we see the largest environment, and there's no question that those products can handle that. In terms of the growth curve and the adoption curve of those products, if you think of the -- our growth compared to the transition to the cloud and the S-curve of workloads being moved from legacy IT to public and private cloud, our infrastructure product tracks that S-curve pretty closely. The moment a workload pops up in the cloud, we actually see it on the infrastructure monitoring side. Our logging product actually gets a bit ahead of that growth curve because you can redirect logs very easily, so you can be lumpier in terms of who you -- how the data is getting to us. And the APM tends to have a longer fuse, so it also tracks that S-curve, but it's going to have slightly different parameters, going to have a longer tail because there's more friction in actually instrumenting environments. For APM, you need to go application by application for doing that. So they have slightly different adoption curves there. In terms of how we go to market with them, we typically -- we're going to land with 2 products or more in most of the situations. The first product is typically infrastructure monitoring. The second product is going to be logs or APM, sometimes both. The tension there for us is that we still aim at maximum velocity when we land a new logo, so we don't want to complicate things too much by adding too many products to early. And we think that the number we shared, which is around 75% of our new logos with 2 or more products, I think is a good equilibrium for that.

So let's talk a little bit about the security story, the emerging security story at Datadog. You've generally released 3 security offerings today. You have a fourth one, Application Security that's in beta. In the last earnings call, you mentioned that you have thousands of customers on one or more of the security offerings. At this early stage of the security journey, can you give us a sense of the types of teams and the customers that are taking on these security products? Like any way to sort of categorize them by market segment or any other type of profile in terms of who are these early adopters?

Well, so first of all, they cover companies at all sizes. What they have in common is, first, they are already developed customers. So we, typically, to them, we don't lead with security, we don't land new logo security. We land with our infrastructure products, we grow usage, and then we get security adoption on top of that. That's the motion we have in place today. The -- what our security customers today have in common is that they tend to be tech forward, so they're a bit earlier in terms of adopting the DevSecOps approach. But again, they can span everything from cloud-native companies to large enterprises. I mean we mentioned in the last earnings call, we landed a -- we had a very large expansion with a large financial infrastructure company that is very much a large enterprise, that is also adopting our security products as part of that. So still early, some great proof points. Customers of all sizes and all shapes. Right now, we're leading with Datadog and expanding into security.

As you look through the eyes of the customer, and we think about Cloud SIEM, Cloud Security Posture Management, Cloud Workload Security, the 3 products that you have GA today, what's sort of the rationale of why these customers would consume these capabilities from Datadog versus some of these security incumbents or some of the modern security players that have that security domain expertise? Why would they come to Datadog versus the guys with the security expertise, if you will?

Well, so if you look at the whole feel of security over the past decade or so, there's no shortage of technology. There's no shortage of detection. There's no shortage of data analysis. All those products have been on the market for a very long time. What there is a shortage of is actual deployment, coverage and usage of those products, and that's what we can actually give to our customers. We can deploy security without friction because we already are deployed in all those environments. We listen to the data everywhere, we listen to logs, we listen to network, we listen to the -- we instrument the infrastructure, we instrument the application, we see what the end users are doing on top of that. So we have all that, meaning we can be deployed at a very low cost for our customers in terms of friction, in terms of the performance penalty they will pay for any additional instrumentation. And in terms of the data attacks, they would have to pay to send data to another place. In addition to that, we also allow our customers to leverage their largest audience on the tech stack, which is developers and operations. In any enterprise, you'll find that the operations folks outnumber the security folks by a factor of 10, and then definitely, maybe another 10 or 20x more developers than there are operations folks. And so basically, if you want to solve your security issues or get in front of them and operationalize that, you need to bring to bear your whole organization, not just the very small team of specialists you have in security. And by the way, it's impossible -- it's even harder to hire security folks than it is to hire engineers. There's not enough of them, and we're at a point today where very few companies outside of the largest enterprises, the hyperscalers and the top tech companies can actually attract and hire them.

On a similar level in terms of thinking about product and why customers will adopt products and platforms more generally, as we think over the next, call it, 3 to 5 years in the security space, what do you think is going to matter more, bringing that security domain expertise? Or is the ability to process data, the kind of big data exercise, data correlation, is that going to turn into the key buying criteria in this age of security? Or is there some completely other factor that's going to determine the strategic high ground here?

To me, it's completely the combination of coverage and usage. You need coverage, you need to cover everything, that's why you don't leave gaps. And you need usage and people to look at it and understand it. And the combination of coverage and usage will yield improvement in smarts, like the systems that actually get all these data, and have a human look to actually see what is that being consumed, is going to have improving the smarts of the systems. And the combination of usage, coverage and smart is going to drive better outcomes, and that's our strategy for winning there. I think it's unquestionably towards the high ground. Of course, there's a lot to do to execute there, but we're very confident in the approach.

Great. So we've been talking for the last couple of minutes on sort of the product innovation. I wanted to make sure I touched on the topic of just operational efficiency. When we look at sales efficiency and sales productivity metrics that we track in software, Datadog is among the very, very top. David, can you hone in on the reasons why sales productivity is operating at a level so much better than your peers in observability and software more broadly?

It all goes to the low-friction selling that's enabled by the platform. In this case, no professional services. Clients are exposed broadly to the platform, and as they see functionality, they can put their data in and use it. So a lot of the efficiency comes from clients being able to -- not self-serve, but really, self-implement and use. In addition, as Oli mentioned, as we have more products going into existing customer relationships, that tends to accelerate that adoption in frictionless selling. Now, we're growing our sales teams and our marketing very quickly. So this is sort of in spite of that, it shows the efficiency of the model and our ability to get high returns and good -- great returns on the cost of selling despite the fact we're investing very rapidly, and think there's a lot of white space we need to invest behind.

As a follow-up to that, David, I think if we look at sales and marketing, it grew from 1,100 in 2020 to about 1,500 in 2021. Can you talk about how you grow and ramp your sales capacity at this rate? What are the pros and cons associated with rapidly scaling a sales organization at this level? Is it possible to make this go even faster in terms of...

Yes. The constraint is not the market, the constraint is our ability to, in a way that doesn't create chaos, bring sales teams in around the world, look at territories, make it so that our salespeople are enabled with the right opportunity, trained, et cetera. So our constraint is really our ability to hire, implement and deploy. And we do this bottoms up. We look in territories. We look at how big markets are, et cetera. We are trying to, as we said in many earnings calls, we're trying to do this as quickly as possible, and -- but we don't want to break the system as we're doing it.

Makes a lot of sense. I wanted to hit on one more topic with Oli, and then I'll see if anyone in the audience has a question for team. The next thing I want to address with you, Oli, is pricing. You and I have talked about pricing over the last couple of years since you've been public. From a strategy perspective, Datadog has broadly issued or sort of foregone a bundling strategy. Can you explain why you avoid bundling as a practice in terms of pricing? And how do you give customers the budget visibility, the value that they need such that data doesn't get -- Datadog doesn't get viewed as the data tax, for example, that's happened to some of the other data players and software in -- over the last number of years?

Yes. So we avoid bundling in general, and the reason for that is we think having clear SKUs for relatively small, discrete parts of our functionality actually gives us a lot of very clean signal from our customers in terms of what's valuable and what's not. Everybody loves your products until you start charging for them, and then you hear all the bad news about what they don't do, what they should do better, et cetera, et cetera, et cetera. So as an organization, if you want to steadily spin, if you want to scale, have many more new products, innovate a lot and at the same time, stay honest and focused on the -- where the value is for customers. That's a great way to achieve that. And by the way, it's -- it's a virtual cycle that when you present a large deal to a customer, you're being pushed to deliver more value, which gives you great insight into what you can do next. The opposite of it would be, if you try to be solely a price disruptor, the cycle becomes what can you -- what else can you take out so I can pay you less, and it ends up being a rest of the bottom in commoditization, which is not great. The other benefit of unbundling is that it really allows us to put customers in control and let them align what they pay with the value they get. So they can choose, for every single piece of data send us, how much processing they want to apply to it, how much functionality they want to apply to it, how long they want to retain it, where, with what accessibility or what core ability, characteristics, which really, over time, we give them more and more and more options, which allows them to really be fully in control.

There you have it. It's been very important in our period of high velocity of introduction because we get to see how a product is going. We get to see, is it being adopted, is it priced the right way? And gives us really good information flow to make any changes to maximize the success.

Making each product stand on its own and prove out its own value. Very interesting. So let me go to the audience to see if there's any questions for the Datadog management team. Just raise your hand, and we'll try and get a mic. Up in the front here.

Two quick ones. One, can you just talk through your partnerships with some of the big public cloud vendors, Microsoft, Amazon, Google, how significant those are as a driver? And two, just any changes you're seeing in terms of enterprise buying behavior given the recent geopolitical events.

So the first question was on the cloud providers and partnerships. So these are important. These are not new. I mean, we've been working with the cloud providers since the very beginning, and they pretty much invented the whole infrastructure we're selling into. They're all important in their own ways and a little bit different. Some of them are more -- have more of a technical integration aspect, some others don't. And I would say the customer base for the cloud providers are also a little bit different. So for example, we have a lot more technical integration on the partnership with Microsoft than we have on some of the others, but that also corresponds to the fact that the customer base for Microsoft have to spend more time inside of the Microsoft UI itself than on the other cloud providers. So we adapt the partnerships to be what's required for the specific customer bases there. In general, what we see with those partnerships is that they tend to generalize and write down things that we're already doing at the local level with some of these cloud providers. And so for example, with AWS, we signed a large strategic partnership last quarter and we already had a lot of the joint go-to-market motions going on in specific markets with specific teams. What this does is it helps us generalize that across many more teams.

We were just talking about the ability to scale sales and marketing. But for you guys, with your pace of product innovation, it's almost a question of how do you effectively scale R&D with 13 products that are generally available today. I think you grew R&D expenses by 79% last year, headcount by 50%. Usually, we talk about the ability to scale the sales organization and revenue, closer to $1 billion. Oli, how are you thinking about scaling R&D as the product portfolio gets bigger, as customers try and make decisions across the portfolio about what they want to consume? And then also, where you want to invest in terms of net new functionality versus continuing to innovate in the core?

So short of it is we're scaling it as fast as we can. We do believe in long-term differentiation and leverage through continued investment in engineering, and we already see some of that today. Like we've seen revenue growth that outpaces the growth of our sales and marketing, in which definitely shows that leverage. The -- the way we're set, we're organized internally is actually a little bit different from what you'll see from a typical hyperscaler. The companies like Amazon are extremely successful at building hundreds of new products completely separately, with teams that almost never talk to each other, are completely independent and can move in their own direction. It's fine for them because their customer ends up being the glue in the end and stitching together all those different data stores and APIs and various little things. We're sort of the opposite of that because we have -- we're in the business of bringing everything together. We connect to all those things and we switch them together, and we paint the end-to-end picture for our customers. So internally, we are -- our teams organized a little bit differently. Our North Star as we grow those teams is really, are we solving the right customer problems? And do we see evidence of that based on the value we're delivering and what customers are paying us for our products, which goes back to the question you asked earlier around unbundling.

Yes. Okay. Go to the audience one more time to see if there's any other questions. Otherwise, we'll wrap up with one last one. . All right. Last question is on the one that -- it's a popular one, which is, are you going to have to build a specialist security sales team to address the [ SOC ] team? But I also kind of want to flip it on its head a little bit. Why would that necessarily have to be true? If the forcing function of teams over time is that these organizations are going to have to come together, does it make sense to build a kind of separate sales organization to target these sensitive users if you're playing the long game about convergence across these multiple different teams?

So the short answer exactly is we don't know yet. We see -- today, we see great signs that with a completely unified sales force and bottom-up platform adoption, we can actually get our newer products and newer verticals adopted. I mean that's the case in security. I mean we have other products that go into developer workflows that some of them have gone into business analytics and things like that where we also have some of the same trends. That being said, if you zoom out a little bit and you look at the rest of the market, a lot of the buyers in those additional teams we want to bring to the table sometimes speak a bit of a different language. So there might be a need for some level of specialization there or at least some rules that have specific experiences, speak a specific language. I don't come from security. I don't speak CESIL, for example, but I know many people do. So it's one of the things that we might have to add.

Understood. We'll continue to see how it all plays out. And with that, thank you, Oli, thank you, David, for a great conversation. Thank you.

Thank you.