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

Thank you, everyone. We are having our fourth presentation today, and we have -- we're thrilled to have Datadog with the CEO, Olivier Pomel, joining us for the Future of App Dev Conference day #2. Olivier, thank you so much for joining us. It's a pleasure to have you at the conference.

Thank you for having me.

Well, I hopefully get to sort of unpack some of the forces shaping the market. Before I get there, let me quickly go through a couple of items. First, on the disclosure side of the house, please note that this webcast is for Morgan Stanley clients and appropriate Morgan Stanley employees only. This webcast is not for members of the press. If you are a member of the press, please disconnect and reach out separately. For important disclosures, please see the Morgan Stanley research disclosure website at www.morganstanley.com/researchdisclosures. If you have any questions, please reach out to your Morgan Stanley sales representative. [Operator Instructions]

And so with that, let's start the conversation on Datadog. And maybe just to sort of contextualize 2020, it's been a crazy year for everyone. As you look -- as we sort of hopefully put an end to 2020, what do you think are the things that Datadog has really executed well? What are some of the challenges? And what are sort of the initiatives that are sort of top of mind for you as CEO of the company going to 2021?

Yes. So it's really been, as you said, quite a year. There's a few things I think went well, I think. I'm very proud of the way the people in the company have adapted. On the go-to-market side, we've been able to retool everything so that we get in front of our customers. We reach them. We are able to close deals. We are able to maintain relationships. So all of that worked pretty well, which is very good. On the engineering side, we maintained productivity as everybody was remote, and we've shown that actually quite a few things this year. So again, very, very happy with the level of productivity of the teams, very happy with the way the employees have really managed while their life was being upended. One thing we did well as a company, also, is we kept on hiring. When everybody was slowing down and being very cautious, we basically stuck to the plan we had. We took advantage of the fact that the market -- the job market was a bit softer to really do a lot of the hiring we wanted to do and wouldn't regret that. I think now it's -- obviously, it turned out to be the right thing to do, but we think it was a good moment for us. In terms of what we could have done better, when I think of the time at which we were just entering the crisis, and I think we had an earnings call for Q1 at that time, I think we didn't really see -- and understand exactly what will happened in Q2 in terms of what would work and what didn't work well. We thought we'd get less new logos, more churn. None of that was true. But we also thought our customers would -- the growth of our customers would be somewhat similar to what it had been in the past, and that was not true. In Q2, we saw actually that our largest customer, the one that have the largest footprint in the cloud environment, really slowed down their usage of cloud environments, maybe mostly to save on their large cloud infrastructure deals at the time and conserve cash. So that's one thing. When we think about what we can do better in the future in terms of planning and modeling the business, that's a new behavior we hadn't seen before that we want to do better in the future. Now if you zoom out a little bit, one big learning of the year also as we see our customers and the industry generally go through the crisis such as this is that it really reinforces the importance of digital transformation and cloud migration. We've seen that companies that worked well in digitally were able to react much better for the pandemic. We saw a set of companies that were hosting in the cloud could scale up, scale down, change their mind, retool in a way that others haven't been able to. So it's really been a validation. We've seen already a number of companies that haven't embarked on their cloud migration restart and -- because it's become really the obvious destination. So that's good. Now in terms of what we need to do for next year, hopefully, next year, we'll see the end of the pandemic, so we can put that behind us. But for us, we're still so early in the market that the goal is really to grow as much as possible, and that means growing the engineering team on the one hand and growing the go-to-market teams on the other hand. So all of our energy pretty much is focused on making sure that we scale those teams. And that as we scale them by adding humans, we'll also scale the productivity in the same way.

That's a great overview. And so the theme of this conference is future of app development. And one of the things, I think, Datadog does better than almost any company that I covered certainly is sort of product innovation. Your product velocity is impressive. I think if we look at the start of 2017, you were at like 1 or 2 products. And now you have 10 paid SKUs in 3 years, and so that product velocity is particularly impressive. In a lot of ways, these companies are trying to be like Datadog. They're trying to deliver new services and value for the customers. And so the question there is like what -- I'm using Datadog as an example. What are sort of the processes, initiatives, and frankly, tooling that you've put in place to drive that really impressive velocity? Because in some ways, a lot of customers are trying to be like what you guys are doing. And so that's the first part. And then second, what was -- as you look at your own product engineering teams, what are sort of the challenges they're facing? Particularly in the current environment, we're all distributed. Like how do they ensure that they are increasing their velocity and delivering high-quality products?

Yes. So I mean, look, if you start with the problem side of things, which was some of the things we're doing to solve them, the -- we have the same kind of problems as our customers as they move -- as they turn into a software company. We're a software company. We have to maintain velocity as we scale and which is really hard. Like gravity is really trying hard to pull you down. We have to make sure that we get our teams to work together properly, especially across team boundaries. So when we started the company, we started to get dev and ops to work together, and then we added the security team. As any other company, when we started the security team, it was difficult to get security to work hand in hand with the development and operations. So we're facing the same kind of issues that our customers are facing. And then as we grow in the cloud, just like everybody else, like we need to -- we run a system that's very data-intensive and computing-intensive. We need to make sure that, as we keep adding functionality and as we keep innovating, we also maintain the -- our costs in check and have the right margin profile. So we have to work towards all that. The things we did in order to make that work is -- so first, from the very early days that we built our company on a shared platform, it was -- before it was a product, it was a platform. And so we, very early on, started articulating the boundaries between various parts of the system, making sure that the engineers know at which level they should stop when they talk to another team. So over time, this has been refined to a lot of different micro services, APIs that are being used for different teams to interact with each other and then a lot of tooling underneath that to make sure those new teams can ship and test and do everything being on top of that. Obviously, we're big users of Datadog. We're dogfooding. The world has never been more appropriate than that. And by the way, I know that by calling the company Datadog, we signed up for a lifetime of dog puns in the press, so we have to live up to that. The -- so we use a ton of Datadog. We use the cloud. We use the best of the planet. We think the cloud has been transformative for many companies, including us, in that it allows us to change our minds very quickly. It allows us to scale up, scale down, do all the things that -- all the promises of the cloud, basically we live through them every single day. That's one thing. One thing I would say that's very important to understand is having the platform and the productivity to make sure that we -- the tooling to make sure that [indiscernible] is one part the equation. The other part of the equation is to build software that is not waste. And throughout my career, one of the biggest problem has been not just to build software, but build the right one, build stuff that customers will use that they need. And for that, we're very disciplined in having a company that is very product-oriented, that is very customer-oriented. We like to say that we focus on the problem first before the solution, and that's something that permeates basically every single aspect of new product development. We want to make sure we're close to the customer and then solve their problems.

That makes a ton of sense. As we think about how cloud adoption and cloud consumption has impacted the market, I think Datadog was one of the very early companies to understand that you're going to have to unify the data and you're going to have to sort of unify the teams. And in some ways, that gave rise to like the observability market that we know today and frankly that a lot of the industry is moving towards. As we go into the sort of next phase of cloud consumption, the idea is that it probably accelerates. What are sort of the next level of locations, right? Like observability is sort of the consensus for you and consensus operating model. What are you thinking as sort of the next frontier that Datadog is looking to solve for?

Yes. So the first thing I'd say is we're still super early just in observability and cloud migration, right? So it's not like we've arrived and the world is in the future, and everybody is there. It's pretty clear now that it's the observability market, as we see today, is the right destination, right? It's having everything that is somewhat integrated, and that covers all the various aspects of understanding what mitigation is doing, I think, is the right thing. What you -- in terms of what the future looks like and what the next frontier is going to be, like if you look at cloud-native companies, the whole business is in software. Applications run everything they do. Meaning by understanding what's happening inside the application, they don't just understand if the website is poor, if the end user performance is good. They also understand what their business is doing, how many transactions they're serving, how much it's generating for them, which customers are the happiest, the least happy, what they can -- what else they can do for them. And so moving forward, we think we'll see a lot more of what enterprises do revolve around understanding what the applications do. I think they'll instrument their business to their applications, and that's going to be the shortest path to actually understand what's going on in the enterprise at any point in time. Of course, they will manage their security posture through the application, basically everything that revolves around bridging the gap between the humans, be it engineers or in business. And the bits and the electrons that are circulating inside data centers, I think, is going to be part of this bigger, broader, next-generation observability market.

Olivier, this is Keith Weiss. One of the topics and one of the themes that we've been talking a lot about during this virtual conference is kind of breaking down those walls and sort of getting to a more consolidated position amongst a lot of the -- sort of the various toolkits in the DevOps tool chain. And David has done a remarkably good job of building out a platform of solutions that all use the same kind of underlying set of data to do what has historically been very different silos of functionality within organizations, particularly large organizations. So you have the technology side of the equation. What does it take to get these companies to actually sort of buy into that vision and break down their silos? Because like the apps guys are in a different room, and the infrastructure guys and the security guys are in a whole another building, right? How do you help to exact that change within these organizations, so they could actually follow through on the promise of DevOps and DevSecOps?

Yes. So that's a good question because that's really what we've built on company around, which is it's -- of course, it's not all to just promise and say, "Hey, if you deploy this, all your teams are going to work together. You just need to buy it from me, and then it's just going to work." The reality of it is to make it work, it has to be adopted bottom-up, and it has to be very low friction, and it has to show immediate value to a lot of different people and different roles. And that's how we build the product as we build the platform. Meaning it's not your boss saying, "Hey, professional services team is going to roll in, and they're going to stand up this thing. And then everybody is going to sit through a training, and then you're all going to start using it." The way we spread is people install us. They start using us, they start experimenting with an immediate problem they have, which might be understanding it's basically part of their application or infrastructure and security, and then they build more and more and more. They contribute more data to it. That data goes up because in the way -- it arrives at the team level, product manager sees it, the business manager sees it, the CEO sees it. That's how the whole thing works. So the name of the game is low friction, show a lot of value very quickly to a lot people in different parts of the company. That's why we pride ourselves of having on having a product that is very simple, and we invest heavily in keeping that product very simple to deploy. So that mere mortals can use it and see value in it. The metaphor I've given a number of times is we're not SAP. We're Excel. SAP is fine, but if you're going to -- if you use it, it's your full-time job to use it. You're heavily trained to it. Any use case or any new piece of data you need is going to require professional services engagement. And if you're not a full-time user of it, you're going to be super scared or you're not going to want to touch it. In our case, we're Excel, in that just about everybody knows how to pick it up. You can get started very easy. If there's a problem, you can be immediately solve with it. But then over time, you end up building considerable workflows around it, and it ends up being the basis of how people collaborate and work together. So that's the thinking behind what we do.

Got it. And that makes a ton of sense. Just take -- to sort of get your perspective, where do you think the industry is? And especially, if you think about larger enterprises, how far along the journey into really starting to look at these various elements as a whole, how far into that journey do you think these larger enterprises have gone so far?

I think it's still early. But I think what makes it easier for these enterprises to -- for them to navigate this transition is that they're also starting small in the cloud. So there's a part of any enterprise's application or infrastructure that started the cloud and then the number of teams that go along with that. Those teams, from day 1, know that they need to break down the barriers between what used to be separate walls. One of the main value props of going to the cloud is you're going to -- it's sort of having a wall between development and operations. You can ship quickly, iterate quickly, change your mind. And so everybody knows that those 2 need to be conflated, and they need to work together and the data, same thing. And so there's a desire to do that. I think what we provide is a way for these companies to -- or these enterprises to get started very easily, to get to this initial critical mass and success, so they can replicate that to the rest of the org, and it all comes into this next-generation cloud environment. So that's the way it works for us.

Olivier, we got a question online that I think is a pretty good one, sort of related to the core observability markets. And the question is, "Are there any notable changes in the relevance or role of certain data types, i.e. logs versus metrics versus traces versus events, as we move and adopt more of these modern application architectures?"

I think they're -- well, they're all interesting signals, right, and they all can be used in different ways. I mean there are reasons why you want to use one versus the other. I mean, in some cases, it's more efficient from a data volume and cost perspective to use one versus the other. In some cases, you can get -- it's easier to get one versus the other or to capture one versus the other. So there's a number of reasons why you might want to use one of these other data types. Our perspective is that it doesn't really matter whether the world wants to see metrics or traces and logs or events or network packets, it doesn't really matter. And we actually expect to see quite a bit of fungibility between those. It already happens to us to see customers start implementing a certain use case with logs because it's just easy to add back at the -- on the back end of the application but then move some of that to -- into metric and some of that into traces because they can get richer data and more efficient use of their data volumes by doing that. So we fully expect some fungibility. It's one of the other reasons why it doesn't make sense to have these different data sets and a lot of different categories that you buy separately.

Sorry, I interrupted you.

Yes. No. I was going to say as companies move into more modern architectures, one thing is very clear is that the level of complexity they face is shooting up. Not only do they have more engineers and more software because that's what they do. As they're turning into software companies, their sort of footprint and impact is growing. But also they're using architectures that are more fragmented, that have more components that come into play more diversity or software stacks they use, more dynamic components. If you look at the newer cloud architectures with cloud instances or containers or microservices or serverless functions, there are so many little things that keep coming up and done and recombining also different ways in real time that the level of complexity that everybody is facing is shooting up. And the only way to deal with that complexity basically is to invest in observability and having companies, such as ourselves, focusing on making sense of all of that for customers.

Understood. I wanted to spend a couple of minutes talking about your security vision. The security product initiatives got started over the last 12 months. Could you sort of spell out what the Datadog security vision is? On one sense, I'm sure it's about breaking down the silos with the security team as well. But we've seen other players in the space, the log analytics vendors have used the -- their core log analytics capabilities to deliver a cloud analytic -- cloud security analytics piece or a cloud base in. Is your vision different than that? Like can you sort of just walk us through how your security proposition may be different than what we've seen in the past?

Yes. It's a bit more specific than that. So one thing we -- so first of all, we came to security because we saw some of our customers build their own security automation and security instrumentation on top of that log. And so we saw -- while it makes sense to them, there's probably something there, like we actually are getting some of those users. The -- when we thought about entering the market, we had 2 specific objectives. One is, as you mentioned, to break down the silos. And there, again, it aligns very well with the reason why we started the company. We started it to break the silo -- break down the walls between dev and ops. The situation with security today is very similar to the situation between dev and ops when we started the company. There are many places where the security teams are not on speaking terms with the rest of the engineering teams. And as a result, it's very, very, very difficult to operationalize security. And so we think that our strength in this initial transition is actually very applicable to that. The other angle for us was to focus on cloud security because when you look at the -- what most of the vendors do today, most of it is aimed at corporate IT or on-prem security. And all of that is a sign. Like everybody is using like 10 different products for that. It's a market that is fairly mature. But when you look at cloud environments, it's mostly open. There's no clear way of doing things. There's a lot of do-it-yourself, Openpay. There's a lot of companies trying to move together pieces of open source. There's a lot of companies not doing anything because they just don't know what to do. And so the situation there is actually very similar also to what we saw in the market when we started with infrastructure monitoring. So we see the same kind of white space in there. So that's what we're addressing. We're addressing the -- breaking down the silos and doing it in cloud environments first. And/or what we're bringing to the table there is also that we have a very low-friction platform. It's even lower friction now because, well, customers already instrument their applications. They instrument their infrastructure. They get their logs. They get their end-user activity logs to us today, and so we have all the signals already in the system. Those signals are very clean because they're used already to wake up engineers at night when something goes wrong. Meaning if the data is wrong, it gets fixed pretty quickly. And so we're in a great position to help our customers really operationalize their security and do it well in the cloud between bringing the security teams along with the dev and ops teams.

Understood. I've got a couple more questions online which I'll sort of bundle in with my next question. The question is, "You talked about your win rates versus competitors such as Splunk, Dynatrace, New Relic, AppDynamics and Sumo Logic." That's the question, but maybe we can fold it into kind of the topic around convergence. It is one of the themes that Keith and I are trying to better understand is just how fast convergence is happening. Is there a particular segment of the market where you see more of the multiproduct adoption versus others? And then as we sort of look forward, do you think there's going to be a more structural move in terms of customers consolidating these capabilities with fewer vendors?

So starting with what we see, we actually see very similar behaviors. In the 3 main segments we track, there's SMB, mid-market. Mid-market -- SMB is less than 1,000 employees. Mid-market is 1,000 to 5,000, and enterprise is more than 5,000. And the rate of cross-product adoption across all 3 are very similar. We land with 70%, 75% of new logos with 2 or more products across what used to be the old categories: infrastructure monitoring, ABM, logs and et cetera, et cetera. And then our customers keep adopting more and more and more. And the situation is very much the same across all of those different segments, which tells you it's not about buying behavior. It's about a core need that the humans on the other side have. That is that they need to see everything together. It makes sense. That's how it should be, right? Of course, there's a limit to how much you can adopt at once because there's a limit to what people can deal with in terms of newness and work they have to kind of implement everything, but we see the adoption trends being very similar across all of those. So when you fast-forward a little bit, what the market might look like in the future, to me, it's very clear that there's going to be this room for a ral platform to take place there, to take hold, really, that governs everything that the engineers, the product people and the business people who care about what the application is doing in real time to cater to their needs. One comparison I would make is to the CRM market where there are a few platforms. There's a dominant one, which is salesforce.com. It actually covers a lot of the ecosystem but not everything. So you have this interesting ecosystem where there's a dominant player that runs a platform, that encompasses a lot of the behaviors that go-to-market team or tech support, customer support teams or marketing teams would have all day long. And then this is -- the rest of it, it's an 80/20 rule. Like the rest of it is delivered by a number of companies that log into their platform. I think to me, it's very possible that we're headed towards something like that, where a lot of the -- an engineer's day is spent into one specific platform with a number of other products that plug into that for -- either to contribute data or to use it [indiscernible].

Let me -- another kind of like future question, if you will, or kind of -- as you think about it on a going-forward basis. I'm going to show my age here and the fact that I've been doing this too long. But when I think about sort of the technologies that we've been talking about and the vendors we've been talking about in terms of how do you keep your applications up and running. When I started at this job, we were talking about CA and BMC and then keeping mainframe applications up. And then those guys fell short with the technology change and the new class of applications. Wily and Gomez came up to sort of do the job of keeping your applications from falling over, but then they didn't keep up with sort of the move to the web. And AppDynamics and New Relic, and then those guys missed out on containers and didn't understand there's a technology change going on. And now we have Datadog is really the dominant vendor in the space. But I mean I've been doing this for a while, but I've already seen we're on like generation 4 of this type of vendors, how do you keep Datadog from being sort of as generation 4 going to generation 5 that's not going to be Datadog? How do you ensure that you guys stay on top of the technology changes on a go-forward basis so you maintain that dominance over time?

Yes. Well, I would start by saying when you think of the old -- the older vendors, the IBM, Tivolis and the CAs and BMCs, they had a curse and a blessing. The blessing was that when you start with infrastructure monitoring, it's extremely sticky. It's extremely hard to rip and replace, meaning that retention rates are going to be very high. I mean we can look up the retention rates for those companies over time. Ours are in the 90s in terms of gross retention. Even for SMBs, even for small businesses, we have retention in the 90s. And of course, for enterprises, we have retention in the high 90s. So it's still -- this is super, super sticky. It was a curse also because it meant these companies are going to need to innovate in order to keep their customers, and they all lost their muscle to innovate and build. That's why they were called flat-footed when the world changed. When you look at what happened since we started Datadog, change is pretty much the name of the game, right? When you look at the cloud transition, the architectures for deploying on the cloud had evolved extremely quickly. When we started the company, containers were not around, really. When we started the company, everybody was deploying in cloud instances which were seen at the time as better VMs, smaller VMs. Since then, we've seen containers pick up, and containers today are the main way -- the chosen way for customers to deploy and move to the cloud. We've seen orchestrators on top of containers, and we've seen Kubernetes arrive, which is the killer app for -- making containers successful. We've seen microservices and serverless, and we're not done yet. I think a lot of that is going to keep evolving. So change is the name of the game. That's baked into what we do for our customers, and that's really who we build the company. We expect that things are going to keep changing over time, and our job is to absorb that complexities so our customers won't have to. That's the way we define the company.

Let me -- maybe to wrap up the conversation is sort of just get a speed round, if you will, on where we are in some of these major forces shaping the market. And so first, in terms of public cloud adoption, migration, where do we -- where are we in -- whether it's the baseball analogy in terms of what you're seeing in customers, how -- that's sort of the first one, public cloud adoption and migration.

Right. So I won't go to baseball because I have no idea how many innings are in a game.

3.

I would say for cloud migration, it's early in terms of volume, but it's very clear in terms of the fact it's the right choice and the fact that most enterprises know that it's something that they need to do. And many of them have embarked into it already. So still a lot more that's going to come in. It's going to take some time, right? I mean you don't move everything in the course of a few years, too risky to do it that way. But it's very -- the destination is very clear for that, I would say.

And then the next couple of forces, just relative to public cloud adoption, where are we in terms of DevOps, DevSecOps, microservices/Kubernetes? And then serverless, how early is that? How mature is that happening in terms of your customer base?

So DevOps, I would rank exactly as the cloud migration. I think it's also very obvious, but it's still a little bit early in that there's still a lot more teams to transform. But everybody agrees it's the right way to do it and the right destination. DevSecOps, I would say, is quite a bit earlier. It's a fairly new concept. Again, there's a lot of willingness to go there, but there are still quite a few details that need to be figured out in terms of what it actually means, how you will personalize it. So we're still earlier on the adoption curve. Containers and Kubernetes, I would say containers have really found their footing, thanks to Kubernetes. I would say it's the way -- not I guess a given way that everybody can agree on is the right way to deploy on containers. We see that as being the new way to deploy in the cloud. And so it's trending a little bit from migration, but not by much. It's becoming the -- actually becoming more of a driver of acceleration of cloud migration because it makes everything more clear. It also gives a path to customers that lets them -- that gives them some control in case they want to manage both some private clouds and public clouds which they didn't have before. Now serverless I think is quite a bit earlier. When you think of -- so containers, I said Kubernetes is the given way. Everybody knows how to do it, and that's going to be the agreed-upon path. For serverless, there's no agreed-upon path. Right now, it's still the Wild West. So there's a lot of interest into it. There's a lot of desire for it. We see a ton of it everywhere, but it tends to be all over the place in terms of who it's being used and what is being used for. And so I think we still need to gain a little bit more maturity for customers to understand, "Oh, I see. For these things, I'm going to use serverless, and this is how I'm going to use them. And this is the best practice, and this is why I avoid having [indiscernible] on my hands 2 years from now." So I think there's still quite a bit of maturity that needs to happen there. But again, that's where we were with containers 2 years ago. 2 years ago, Kubernetes was not the clear winner, and containers were a little bit all over the place. Today, the situation is very different.

Okay. I think if we sort of look at the clock, we're sort of 5 minutes over, so we're all out of time. Olivier, as always, I always learn a lot talking to you in trying to better understand the vision that the Datadog is going after. So once again, thank you for joining us for the Future of App Dev Conference. Keith, thank you for joining as well. And then I think in terms of the programming note, in about 10 minutes, I think we have Cloudlfare up next. So thank you, everyone, for joining us.

Thank you very much. Bye.