By any measure, Datadog is an incredible entrepreneurial success story. The company went from a tiny startup in 2010 that had trouble raising money, to a public company that, at the time of writing, has a market capitalization of $12.5B. It was a pioneer in the category of DevOps and observability, and it’s now a clear leader. With revenues hovering around $350M, it has 1,300 employees across 31 locations around the world.
Perhaps improbably, the founders built the company out of New York, which many people over the years have thought of as a hub for adtech, media and commerce startups only. Along the way, they faced a lot of skepticism: “Whenever we pitched West Coast investors it was sort of seen as a form of mental deficiency to be based in New York and doing infrastructure“, says Olivier. I wrote a few months ago about the significance of the Datadog IPO for the ecosystem and beyond. Ironically, out of the three top public tech companies in New York today, two are infrastructure software companies (Datadog and MongoDB).
Not one for gratuitous self-aggrandizing, Olivier has given surprisingly few interviews over the years, and it was a real treat to sit down with him for a fireside chat in front of a packed house of 350 attendees at our most recent Data Driven NYC.
We had an in-depth conversations and covered a lot of topics.
The first half of our conversation was focused on Datadog itself, starting with a high level overview of the observability and DevOps space to make the discussion approachable by people who don’t know the space.
The second half of the conversation was focused on all sorts of lessons learned along the way of building a major company- sales, marketing, fundraising, etc.
Below is the video. We have also provided a full written transcript to make the content easy to scan through (many thanks to Karissa Domondon for her help with this).
FULL TRANSCRIPT (lightly edited for clarity and brevity)
Matt Turck: I’d love to start with some kind of a level set, to make this approachable for all kinds of audiences. People are deeply technical here, but there’s also people that are just interested in the world of data. So maybe the ‘space 101’ and ‘Datadog 101’ and then we’ll dig a bit deeper. Explain this to me like I’m five – starting with a space like DevOps, observability – what does it actually mean?
Olivier Pomel: What it really is, just to take it to a very high level to start: Whenever you watch a movie online or whenever you buy something from a store, in the back end there’s ten thousand or tens of thousands of servers and applications and various things that basically participate into completing that – either serving the video or making sure your credit cards go through with the vendor and clears everything with your bank. What we do is actually instrument all of that, we instrument the machines, the applications, we capture all of the events – everything that’s taking place in there, all of the exhausts from those machines and applications that tell you what they’re doing, how they’re doing it, what the customers are doing. We bring all that together and help the people who need to make sense of it understand what’s happening: is it happening for real, is it happening at the right speed, is it still happening, are we making money, who is churning over time. So we basically help the teams – whether they are in engineering, operations, product or business – to understand what these applications are doing in real time for their business.
Matt: And DevOps, what does that mean, for people who haven’t heard the term?
Olivier: DevOps is a new way of doing things basically that collapses what used to be different worlds. Development: developers are the ones who write the applications and the code, and Operations: that used to be people who build servers and rack them and pull the network cables, that sort of thing. They used to be very separate. The developers build the application and they throw it over the fence to operations people who are responsible for it in production and historically those two teams hated each other.
That’s why my co-founder and I started the company. In a previous life, at a previous company [note: Wireless Generation, a SaaS company in New York], I was running the development team, and he was running the operation team. We knew each other very well, we had worked together, we were very good friends. We started the teams from scratch so we hired everyone, and we had a “no jerk” policy for hiring, so we were off to a good start. Despite all that, we ended up in a situation where operations hated development, development hated operations, we were finger pointing all day.
So the starting point for Datadog was that there must be a better way for people to talk to each other. We wanted to build a system that brought the two sides of the house together, all of the data was available to both and they speak the same language and see the same reality. It turns out, it was not just us, it was the whole industry that was going this way.
This DevOps movement was a core part of the cloud migration that was just starting to take place when we started Datadog, in the early 2010s. A lot of the value prop for the cloud was that, instead of having a development team that builds an application and then you spend 6 months filing tickets and placing order forms in order to actually bring that application into production, and you can’t change your mind for three years on the way it’s going to run… with the cloud you can actually decide on the spot and do whatever you want, engineers and developers can do it themselves without needing to ask for permission, or file a form. And then you can change your mind from one day to the next. That really brought the developers and operations teams together, and that was a bit part of the DevOps movement.
Matt: What was “Datadog” [the name] by the way – that was one of the servers?
Olivier: I actually don’t have a dog, my co-founder doesn’t have a dog – never had a dog. But in our previous company, we used to name the production “servers dogs”. “Data dogs” were production databases and “Data Dog 17” was the horrible, horrible, Oracle database that everyone lived in fear of. Every year it had to double in size and we had to sacrifice goats so the database wouldn’t go down. So it was really the name of fear and pain and so when we started the company we used Data dog 17 as a code name, and we thought we’d find something nicer later. It turns out everyone remembered Datadog so we cut the 17 so it wouldn’t sound like a MySpace handle and we had to buy the domain name, but it turned out it was a good name in the end.
Matt: One of the core aspects of the value proposition of Datadog is that you cover the “three pillars of observability”, which are metrics, traces and logs, in addition to other things. Do you want to define what those are?
Olivier: Metrics is basically anything that’s emitted by an application or a piece of infrastructure that you’re going to track over time. For example, temperature over time is a metric.
Traces are stitching together all of the interactions you’re going to have during a customer interaction. So I type in my browser, the browser talks to the server, it talks to a database. Basically you stitch all that together – that’s a trace.
Logs are any events that are being generated by any of the participants in any of those systems. Anything from “a customer did that” to “the database had an error”, and you logged it somewhere.
They used to be very different categories. For metrics, companies used to buy in a monitoring tool, and then for traces they used to buy an APM tool and them for logs a log management tool. All these different things were disconnected and didn’t talk to each other. One of the main reasons we started the company was to bridge the gap between the different teams and break down the silos. It didn’t make sense for us to have those things being separate. It turns out the problems actually don’t stop at the boundary, you don’t say “wow that’s a lot of problems so we’ll stop there”. When you have a real world problem you actually need to go across everything so it made sense to integrate everything.
Matt: How does [the Datadog platform and backend] work? Is Datadog fundamentally a large database, for lack of a better word? You ingest massive amounts of data from a bunch of different sources?
Olivier: We deploy all sorts of collectors, and all of our collectors are open source. So customers are going to deploy agents and libraries and API’s and we’re going to crawl their accounts on cloud and things like that. So we’re going to collect data in all sorts of ways, and we send all that to our centralized service. And our centralized service you can think of that as a very large database that is going to manipulate different data types, and those data types, under the hood, are going to be stored in different data stores. We have data stores that are appropriate for for super high volume log events or for time series. (Matt: metrics are numbers, logs is unstructured data?) Yes, exactly… and traces have to stitch everything together – there’s a large amount of metadata that ties everything back together.
On our end we have this database that has all these different data stores and the database has a very specific data model that ties everything through the use of tags. So we don’t have to model anything ahead of time. We record what’s happening and basically abstract the data model out of that.
Matt: And that’s proprietary right? [Olivier: yes] And I read somewhere that you guys don’t actually use a lot of third party stuff, whether that’s other products or open-source tools, is that correct?
Olivier: Usually when we build a new system, we’re adding a data type, we usually start with something off the shelf, something open source. At the small scale it’s going to work. And then as we grow, as we get more and more data into it, we see the many ways it doesn’t work for us at scale. As we get a much better understanding of our use case and the shape and velocity of the data, then we start building on. And that’s been the MO throughout the life of the company. For some of what we do, I mean we had the fifth or sixth iteration of the underlying data source already.
Matt: To give people a sense, what kind of volume of data are we talking about?
Olivier: We’re talking about 10 trillion records a day, something like that [Note: 10 trillion records a day!!!!] And everything needs to be persisted, everything needs to be kept.
Matt: To that point, what is real time? Presumably a chunk goes to cold storage?
Oliver: All of it is real time, all of it has to be in process and visible and understood in real time. The real time constraints are fairly high, because we’re in the business of telling our customers that their business is still running, so if it takes us one hour to notice it’s going to be a problem. So we have hard real time constraints. Then the way we run it under the hood is that we’re going to keep all of the data that’s from basically the last 24 hours in memory so it can be accessed very quickly and over time we age this data to various forms of colder and cheaper storage.
Matt: Interesting. You’ve had this very interesting horizontal expansion strategy. You started with the things we talked about – metrics, traces and logs. I guess logs were through an acquisition, and then you expanded into other things, like synthetics and other things recently. Do you want to talk about how you think about these horizontal expansions, what you cover currently and what you plan on covering?
Olivier: For the longest time, we only had one product, which was doing infrastructure monitoring, which was doing metrics. We didn’t have the traces, we didn’t have the logs. For the first few years of the company, we grew that product and we made sure it had the right fit to sell it. We knew from the very beginning that we wanted to bridge the gap between different teams and different silos so when we wanted to add the rest, it was actually the biggest honor to be a step function on the trajectory of the company when we actually managed to do that and we noticed that we could also sell it and customers are also going to update it in addition. The way we see it, there’s a number of categories that are still separate and we want to keep unifying them.
You mentioned synthetics. Synthetics, for those of you who don’t follow the industry, is basically simulating user behaviors, stimulating users clicking on your application for example or simulating API calls to continuously validate that everything works even if the users are not on it yet. There is an existing category for that. It’s not necessarily super interesting on its own. It tends to be a bit commoditized and it’s a little bit high churn, but it makes sense as part of a broader platform which we offer. When you have a broader platform, the churn goes away and the fact it is commoditized can actually differentiate by having everything else on the platform. There’s a few like that, and there’s more we’re adding.
Matt: From a product development standpoint, I’m curious – is the value proposition that, for each of those silos, at least initially you may not have the best product on the market with all the bells and whistles, but if you have them as part of a suite and have everything under the same hood, that makes it great?
Olivier: This actually is a very important point, which is how we define success for those products. We’re not actually in it to have the largest amount of features and to be the best at selling an RFP where somebody’s built a matrix with, oh 77 requirements and you say yes to each of those requirements. The problem with that is you end up with products that are super super complicated and they get sold, and then one person uses them and everyone else is scared. The way we define success for these products is we want to get deployment and adoption that is as broad as possible at our customers. Going back to what we’re trying to solve here, we want to bridge the gap between the teams and get everything on the same page. Which means we need people to actually use us. If the person who bought it uses it and nobody else, we’ve lost. So for all those products we build them so that they’re going to be adopted by everyone on the team and then we keep adding functionality to keep differentiating after that.
Matt: Let’s talk about machine learning a little bit. You play with immense amounts of data and obviously being able to find patterns and all those things is super important, but from what I’ve read and in previous conversations it feels like you guys have had a very thoughtful and measured approach to machine learning. Maybe we’ll start with Watchdog and what it does?
Olivier: Yes so we have a product called Watchdog and what it does is it automatically watches our customers infrastructure/applications without the customer having to point them at specific things. It’s going to surface anomalies and some behaviors they should know of. Our stance on machine learning in general is that it is very hard for what we do to lead with no AI because you’re bound to disappoint because the generic case is very very hard to solve. We talked about the advances of machine learning for NLP and things like that – just about everybody over the age of one can speak and understand NLP but for the kind of problems we solve it’s going to take a team of PhD, hours, and a lot of arguing to try and figure out what actually happened in an issue. So it’s actually really hard to solve the general use case and there’s a bit of a dichotomy in what customers will tell you about it you know, so when you ask when we first visited customers to figure out what they wanted for more product, when you asked them to pick between a false positive or a false negative they’ll say “Oh give me false positive of this side if it’s right, but I want to know”. It’s not true. Give them two false positives and they’ll turn you off – “Oh that thing doens’t work, like it just woke me up to tell me something that’s not true so just get rid of it”. So the way that we’ve been building it is that we have all the data, we solve all the transactional use cases for our customers, we solve these issues. Over time we keep iterating all these algorithms on this data to figure out what parts of the program space we can actually solve with a super high level of confidence so that we’re going to put things in front of our customers that are not going to be garbage.
Matt: What are some of those problems?
Olivier: There’s a number of things our customers can’t do on their own. For example they don’t know what’s happening beyond their account on a cloud provider. One thing we do for them is we tell them when we detect an issue that is going to span across different customers on the cloud provider. We tell them “hey you’re having an issue right now on xxx [19:07] and it’s not just you. It’s very useful because otherwise I have no way to know and you see your screen will go red and they have to figure out why that is.
Other things we do is we ‘re going to watch very large amounts of signals that they can’t humanly watch, so we’re going to look at millions of metrics and we’re going to tell them the ones that we know for sure are important and not behaving right right now, even if they didn’t know that already, if they didn’t know “I should watch this”, “I should put an alert on that”, “I should go and figure out if this changes”. These are examples of what we do for them.
Matt: I’d love to switch gears and maybe talk about the journey and lessons along the way in terms of building a company from a tiny startup into an industry juggernaut. So maybe let’s start with some of the history. In 2010-2011 how long were you guys in R&D mode? Did you start working with customers right away, or were you heads down developing first?
Olivier: So we were in a “not funded, oh my god how are we going to survive mode” for about a year and initially it was actually very hard to get the company funded because there was not a lot going on in infrastructure in New York [Matt: to say the least]. Whenever we pitched West Coast investors it was sort of seen as a form of mental deficiency to be based in New York and doing infrastructure. We’d say the good thing with that is that we were not tempted to believe that we had everything figured out from day one. It pushed us to spend as much time with customers as possible to try and make sure we solved the real problem and not just the dream problem.
Matt: Were some of these initial customers large companies, small companies? How did you select them?
Olivier: It was a bit of all. The large companies, initially they’re great at talking about problems but they’re not great at adopting your stuff. The small companies are going to have different kinds of problems usually but they are great at trying stuff out. One thing that’s great overall in the US market if I was to compare it to the European market: there are a lot of mid market companies that are very tech-savvy, that have real problems, that understand those problems and are going to buy their way out of it. So these are great ways for companies like us to get started and get some market traction to start with.
Matt: What did the team look like in those early years? Was it mostly engineers? [Olivier: Yes, all engineers.] Do you remember how many people you had, 2011/2012?
Olivier: For the longest time we were less than 10, would say 7. One person on the engineering team was a product person, but still an engineer by trade – I would say that the biggest difference there is that person really liked to spend time with customers as opposed to spending time on the keyboard which I think is a very important trait. Many founders ask me, “so when should I hire my first sales person?” and I don’t think you need a salesperson straight away because the job you do initially is not selling, the job you do initially is spending time with the customer. Then you have to be honest with yourself and figure out, even as a founder, do you enjoy spending time with a customer? Do you prefer being on a computer building product, solving problems on the computer or do you prefer to be on the phone with someone or in the office of a customer? Because you need someone full-time who is going to spend their days with the customer and that person initially could be good at sales but mostly it’s going to be a product person. That’s the key to actually understanding what you’re building, who you’re building it for, how valuable it is, and perhaps you can sell it at some point.
Matt: To this point, when did you actually hire the first salesperson?
Olivier: We were less than 30 when we hired the first salesperson.
Matt: What was the trigger? You felt like you had something that felt like a repeatable process?
Olivier: Yes we were starting to get quite a bit of inbound and we wanted to have people following up on inbound and without having the whole team in a high-touch approach to everything. By that time we had packaged the product, we knew what we were selling, who we were selling to, how people could deploy with it, what the first six months of usage looked like from these customers so we don’t have to make all that up. I think when you hire a sales team, you need to have all that in place otherwise the sales team is not going to figure things out for you, you still need to do that yourself.
Matt: Where did the inbound come from?
Olivier: Yes that’s a great question. We actually very early on we decided we wanted to make sure customers could find us when they tried to learn about DevOps and cloud migration, which are the big trends we plug into. The good news is that everyone was new to DevOps and to cloud, and everyone had to learn it, and you were going to learn it in two ways: by going to conferences and by reading content online on specific topics. So very early on, we started building, writing content on these matters, and we started going to conferences. We didn’t need initially to have big sponsorships and large booths. Very early on, we went to community conferences. There’s one in the DevOps world that was called DevOpsDays, and it’s still around. It’s very cheap to sponsor these events. The first one we paid like $2000, or something like that and we had a little booth there. The founding team was going there, I was there, my co-founder and engineers were there. There were laptops and we were doing demos – it’s a great way to get in front of the customer, to get some real feedback to see how they react when you show everything. It’s a way to start generating a bit of that flywheel of getting customers to bring some inbound.
Matt: Who wrote the content? I’m familiar with companies where it’s the role of engineer to write one blog post every quarter. Did you guys have a formal process like that?
Olivier: Ye,s we went through a few trials and errors for that. Engineers writing is not super scalable. Most people are super excited about the idea of doing it, but then most people actually don’t want to do it. So people spend days going “I need to write this article”, and nothing comes out. So you end up killing people’s productivity and they feel bad. That’s not great. Some people love writing and do it super well but you don’t know ahead of time who that’s going to be. We’ve tried having marketers do it, it doesn’t work great because you know it’s content for engineers so an engineer can tell if it’s been written by a marketer. There’s a bit of an uncanny valley. So in the end we ended up hiring full-time engineers who are also interested in journalism, and those people exist, and have them focus on research and writing. We have a time that’s built that way and it reports into engineering, it doesn’t report into marketing. That’s the team that produces the content.
Matt: Interesting. Let’s talk a little about the sales motion, the go to market. Do you guys have a free version, a free trial?
Olivier: We have a free tier that’s limited in volume. Basically you can get our infrastructure for free if you have less than five servers. We actually don’t have a freemium offering because there’s no motion to upsell from that. We’re an infrastructure monitoring product us so you need to deploy us everywhere otherwise it doesn’t make sense. If you have more than five servers, you need to pay. If you don’t know, we’re not going to make you have more than give servers by calling you up. It’s free and free forever in that way. We have a freemium-free, free trial, which is how all customers get onboarded and howe we get bottom-up adoption of out customers.
Matt: Is it a bottom-up or top-down sell, do you get actual developers and operations people and then up-sell or do go to the CIO?
Olivier: It’s bottom-up even in large enterprises. In large enterprises, we start with the CIO often, and then the CIO kicks it down to the teams and then we go bottom-up. And then we come back to the CIO in the end with an order form and a bill to negotiate.
Matt: So how did you build your salesforce to reflect that? Is it a combination of account executives and SDRs/BDRs, business development representatives?
Olivier: It’s fairly typical. When we started the companies that were in the cloud were not the larger enterprises, so there was not a ton of business to be had with super large companies. When we started we sold to SMB in the market. For those we had an inside sales force that started mostly inbound and then transitioned to majority outbound for what they were doing. That inside sales team is typical, it’s SDRs and account reps. It’s the account reps that are doing the closing. We don’t have an inside team that is generating leads for an enterprise team, that’s not how we do it. The inside team is closing their own deals. Recently, I would say four years ago, as the cloud migration started to take foot in large enterprises, we started an enterprise sales force that’s selling to companies at 5,000 employees. That’s a bit of a different model but the underlying adoption is still the same, it’s still bottom-up. Small company/large company – the product is adopted the same way. The users in the end are very similar. When you’re a developer at a very large enterprise you don’t think of yourself differently as a developer at a start-up or smaller company. There’s more and more communities between those.
Matt: Do you guys have any kind of vertical-specific strategy, or you’re fairly horizontal so the risk presumably is to boil the ocean go to every single possible customer. How did you go about it?
Olivier: We don’t need to boil the ocean because we focus on the companies that are moving from legacy IT to public and private cloud. So there’s a bit of a funnel already because not everybody is going through that transition at the same time and when they go into that transition they signal it by looking for certain content or going to certain conferences. So we can focus on that part. But what we do is very horizontal so every company in every industry needs it. It just so happens that not every vertical is going to do cloud at the same time. It started with companies that mostly had a large online footprint, so media, e-commerce, gaming, etc. Now we’re at the point where every single industry is there – oil and gas is on the cloud, train companies are on the cloud, for actual train operations and not just there booking website – there’s very broad horizontal adoption today.
Matt: Any lessons learned around pricing? That’s a typical question that a lot of, especially early stage, companies struggle with and especially in your case, how do end up not being too successful and charging too much to customers if they buy the whole suite, and just keep sending massive amounts of data to Datadog.
Olivier: There are a couple of aspects to it. Pricing, first of all it’s really hard to know what you need to price before you do it. The story there is when we launched a product, we priced the product initially we were going to price it at $12 per instance per month. And the night before we said “let’s put $15”. If we put $15 it worked fine and you know later we actually raised tha tprice to $18 and it didn’t change any of the metrics. So there’s really I think room for discovery in pricing. In terms of pricing philosophy though, we had to be fair and what we wanted to acheve with the price and the number one objective for us was to be deployed as widely as possible precisely so we could bring all those different streams of data and different teams together. I wanted to make sure we were in a situation where customers were not deploying us in one place and then forgetting the rest because it can’t afford it. We looked at the overall share, what it would get, how much they would pay for their infrastructure, we decided which fraction of that we thought they could afford for us , then we divided that by the salary and infrastructure you know so we could actually get a price that scales. Now the most important thing about pricing as we’ve been scaling it – and customers send us more and more data – is to make sure that customers have the control and they can align what they pay with the value of what they get. So one common example is log management systems because machines are very good at generating large amounts of data and not all of it is valuable. Yet until very recently the only way we could buy log management was by volume so basically you sent everything and everything you send you get charged for it. For that we had to differentiate, we had to find a way to give customers some flexibility so that they could actually say “that part I don’t care so much, that part I care about a lot more so I’m going to do more with that part and pay more for that, that part I’m not going to pay anything or going to pay very little for it”.
Matt: I’ve got so many more questions but in the interest of time, just a couple of last topics because I want to give time for people to ask questions. Obviously going public, I’m curious, whatever you can talk about from an inside perspective. What does it feel like, how is it different being an early public market CEO? Any of those things, or the experience?
Olivier: The experience I would say, it’s interesting because you spend all this time to work for an event. It just sounds like an event, like you do an IPO and then you’re done with it. But it turns out most of the work you do there is really to prepare for the 18 months that follow the IPO. Most of the investors you meet with, yeah maybe they’ll buy in the IPO, some of them even the longer term investors are actually going to flip it right after the IPO or shortly after. But there’ll be your long term investors and you start building relationships with them at that time, you start setting expectations, they remember everything you tell them at that time and then they measure you against that in the quarters to follow the IPO. So even though ostensibly, you’re preparing for a specific one day event and everybody’s calling victory on that day, what you’re really preparing or working for is the longer term and the couple of years that follow the IPO.
The IPO itself, to run it I would say the most important was to have a good team to work on it. So having a good CFO, I found, is very important. Having a great finance team, I mean we got so much work done by the finance team to prepare for that. We had someone run investor relations that did a fantastic job. So all of that was a key ingredient in making it successful.
On the day itself, one thing that surprised me the most is that it was very moving because we had the whole company, we actually had the first 200 people of the company on stage at Nasdaq for the IPO. It was very moving to see people there because many of those people were at the company for 5, 6, 7, 8, 9 years or more, were there from the beginning. We had a coupe of employees who joined us as interns and very early on in the company and were at the IPO so it was very moving to see that. On the personal note it was also terrifying because right after you start trading you have an interview with CNBC. And I think “it’s fine, just go to a studio and ask me some questions”. No, I was on a stool in the middle of the Nasdaq, with my whole team around me. There was a camera pointing at me, they were in a studio somewhere else on the other side of the country, I had an earpiece I could barely hear what they were saying on the earpiece, and somehow they were talking about Iran and things like that and I was terrified because I was thinking, my god I will never hear what they ask me and I’ll look stupid in front of everyone.
Matt: Well, I watched that interview, you did great. To close for me, maybe some thoughts on the personal journey as a CEO, as a human – when you think of what a founder needs to accomplish to go from the very beginning to where you currently are and then very much so in the next few years (because in many ways it’s just the start right?)… How did you scale yourself? Initially you needed to be really good at coding, now you need to be really good at talking to public market investors, how do you not just completely lose your sanity through the journey?
Olivier: Well first of all it’s all gradual , so what matters is always the next step and this changes over time. But you’re right, I mean you have to go from being really good at coding to really good at not coding. So I would say that part of it is developing a little bit of self awareness to make sure that you can scale while you’re working in the way that you want it to work. So I’m a bit of a control freak, but to scale a company you have to trust a lot of people and put them in control and give them enough room otherwise you’re never going to get all these owners that build a company on your behalf basically, and grow with it. So one way I chose to do it is I can’t micromanage everybody but I can still get a lot of the data streams sent to me so I can pattern match and understand what’s going on. So I like to have very rich feeds of information, for example I see a large volume of the tickets our customers are filing. I want to stay in touch with what’s happening with the product and I’m going to see all the deals we close and I”m also going to read all the comments we get from employees in employee surveys. And there’s lots of them, I mean as we have, as you get thousands of employees you get all these comments all the time. I’m not going to act on every single piece of that, I’m not going to go tell people “oh you should do this about that”, I’m not going to opine on every single deal, every single ticket. But what it does is it keeps me enough in the loop so I can pattern match, I can understand which questions to ask from the people and basically how to be gently informed of what they do instead of micromanaging them.
Matt: Where there terrible moments of self-doubt?
Olivier: Yes quite a few, yes. Especially in the beginning. So when you start a company you have this romantic idea, you’re your own boss now, you’re going to kick butts, and all these great ideas. And that lasts about three months, at least for us it was about three months later. We had no money, we had no customers, we had no product. It was also winter in New York so it was pretty sad. I think these are the moments where you have to go back to the basics and figure out, “okay so what are we doing, why are we doing it, who are we doing it for”, and make sure that you get that right so you can actually carry it across to the other side of it. When you have a product, when you have some money and you have some customers. Then you actually have a thread to pool, basically. But these are difficult. Initially I sucked at fundraising and I remember, you fly to take all these meetings, I remember being in hotel rooms on the other side of the country, having had four “no’s” in a day and you’re like “so I need to call my co-founder and tell him it’s not working well”.
Matt: Why do you think you sucked? Is it because you didn’t present the vision well, or the vision wasn’t exciting enough, or people just didn’t get it?
Olivier: Well I don’t think I understood really what the other side was looking for and how to present it that way. I had no idea basically on how that part of the world worked and that’s something I had to develop over time. For the first two years of a startup as a CEO, you’re the Chief Fundraising Officer, your first job is to make sure the company’s not going to go out of business and very often that means you need to make sure you raise the money. So that’s something I had to learn over time.
Matt: I should stop asking questions, I could just keep going all night. Let’s open up:
QUESTIONS FROM THE AUDIENCE:
How do you handle copycats or disruptors that may be copying what you already do so well in the last 10 years.
Olivier: Well it depends on the copycats. I think it only took a couple of years to find a company in China that had the same assets we did. They had even taken the images from our website and the JavaScript code, so everything was in there. There’s not much you can do about that. I don’t think that company is still around by the way. Whenever you do something that finds market traction you’re going to have a lot of other companies trying to copy it. In general I think that’s fine. If their plan is to do whatever you’re doing or a fraction of whatever you’re doing four years later that’s not where your competition is going to come from. Your competition is going to come from people who are trying to do it differently, who are going to have a different approach and that’s how they’re going to build their own traction, that’s how they become a threat.
You mentioned earlier that there was some real time constraints with regards to data. How will this change in light of the faster speeds from the 5g networks as well as the rise of edge computing from IOT devices, etc.
Olivier: For us I don’t think this changes the time constraints a lot because we’re already at a level of a few seconds roundtrip time to ingest and make sense of the data. So we’re already in the part of the world that needs to act quickly on that data. I think the changes you might have for a round trip for serving a video for example, that’s not the part that we’re playing in today.
You guys recently announced a security product and entering the sim market. That’s been a pretty fertile place to leverage big data and for insights to better serve customers, is that why you entered that market, do you think you can differentiate yourself or is it much more about scalability and the data you already have for new types of insights.
Olivier: That’s a great question because actually we see there a lot of the same problem. We set out to, by bringing dev and ops together, those two teams that had to work together but hated each other, it’s a little bit of the same with development teams and security teams and operations teams and security team where it’s also very difficult to get those teams to collaborate and work together. It’s very hard to operationalize security and I think that’s where we can make a big difference. To your point we already instrument all of our customers environment, we know what the applications are doing, we know what their servers are doing, we know what their networks are doing, we know what their customers are doing, we know what their engineers are doing. It’s actually really hard starting from the security side of the house to get all of that instrumented and all of that operationalised and I think we can make a big difference there
How did you stay confident when all those copycat companies were being created and your company’s ability create value in the industries when there are companies that are coming in trying to do the same thing?
Olivier: In general I think it’s not a good idea to obsess over the competition. It’s a much better idea to obsess over the customer. Every time you are tempted to, because it is tempting you seel of all those press releases, you see people raising money and you see all that stuff, whenever I personally was tempted to read more about them and look at what they’re doing, instead I’d go and spend time with customers or potential customers, this way you know you avoid overfitting what you’re doing to what you think the competition is doing. There’s a saying that if you look into the wall you’re going to drive into the wall, that’s a bit like that. If you can focus on your customers, if you focus on how you’re doing things, what you know is working, what you know is not working, I think you’ll be fine.
Did you pivot since the beginning when you started Datadog, and how many times have you pivoted?
Olivier: We didn’t pivot. When we didn’t manage to fundraise initially, we sort of garbled the pitch quite a bit. We tried to turn it in different ways. We thought maybe we’d do something a bit different and we were full of doubt at the time. But as it turns out, the product we shipped initially and the product we have today, almost look exactly like the notebook drawings that we had done in 2010. So it turns out we built exactly what we said to do. I would say we were lucky despite it being difficult initially when we took our product out of beta we have fairly immediate market traction so there was less room for doubt there.
Can you tell us about your Mark Zuckerberg moment when you turned down $8 billion from Cisco?
Olivier: I don’t know what we turned down from whom, but what is true is that as you grow along the way at multiple times you’re going to get offers to sell it. And it’s never a completely straightforward decision to make because you’re thinking, “wow this is a lot of money but at the same time I see all this potential and everything else in front of us and there’s much more we can build”. So it’s never an easy decision to make. I think it becomes much more clear you know after the weeks that follow that decision why it was a good decision to do what you did. But there’s a truth there which is that to grow to a large company one of the hardest to do is not to sell along the way.
My question is around the acquisition, so first question did you buy the company for their products or for the team, and second question is around the challenge of acquiring a company
Olivier: We announced three companies that we acquired over time. In each of these companies it was at least the team and in some the technologies and in some the customer experience. We did that to accelerate our development for new categories and new markets. The most important factor for us in those ways to make sure that the people we were bringing to the team would actually gel with the rest of our team, would stay and would be people we could build around. As we grow we might do different kinds of acquisitions because we have more scale, we might enter categories that are more different to what we’re doing today, but early on we really focused on integrating the teams and making sure that we basically have a new leg to build on, new leadership we can use to drive new parts of the product.