Alexis Le-Quoc

The through-line

Almost everything Le-Quoc says about building Datadog comes back to a single discipline: go and find out, rather than assume you already know. He calls it "learning over knowing" [1], and he is candid that it was not a philosophical choice so much as a condition of survival. The company had no customers, no clue about enterprise software, no money, and was financing its sales on credit cards [2]. What followed was nine years of correcting the picture from outside evidence: from users at small practitioner conferences, from what else customers had installed, from who showed up at a booth, from a sentence it took two and a half years to be able to write.

The second thread is that the fundamentals do not move. Tools change, velocity changes, complexity grows, but the exchange at the heart of a business does not: somebody has a problem, you solve it, they pay you, and then they bring you the next problem [1]. Asked what changes as a company scales, his answer is that the first principles are the same [1].

On starting from someone else's problem

Le-Quoc's formative product lesson came from eight years building software used by teachers, where the conclusion was blunt: "we're not a good proxy for the customer" [1]. That is unusual grounding for people who then went into developer, ops and security tooling, where most founders start from their own itch. Coming instead from a decade of building for others meant the founding anxiety was misplaced empathy: "when we started Datadog, the biggest fear was to build something that would not solve a real problem, a really valuable problem" [1].

The method that followed was deliberately unsalesy. They sought out low-key gatherings, including "a kind of a semi-abandoned office space in the valley on a Saturday morning" [1], and opened not with a pitch but with a question. Because the only question was tell us about your problem, people were "extremely eager to share" [1], and what came back was unmediated by marketing: "no theory, just battle scars, and you know war stories, as it were" [1]. The discovery that those pain points resembled their own was the first real evidence they had. Being rejected by Y Combinator sharpened the same instinct. It stung, but the lesson he took was to focus on what they were actually going to sell and what problem it solved [2].

On the dev and ops divide that produced Datadog

The origin was not monitoring. At Wireless Generation, Le-Quoc ran operations and Pomel ran development, they had hired every person on both teams and deliberately avoided hiring jerks, and the teams fought anyway [1]. Code went over the wall, production broke, and the finger-pointing was structural rather than personal, not least because the people writing the code were not the ones woken at night to fix it [1]. The founding vision was therefore social before it was technical: bring dev and ops onto one platform and get them speaking the same language [1]. What they did not fully grasp was that cloud adoption would run through exactly that convergence, which made their idea more central than they realised. He is willing to call that luck, while noting that the original slides have not veered much from what the company became [1].

On naming what you actually are

Le-Quoc is unsentimental about how badly Datadog described itself early on. The 2013 site promised to turn massive amounts of data into actionable insights, and his verdict is that nobody has ever woken up in the morning wanting that [2]. Two words were missing, and both were avoided on purpose. Monitoring was "a dirty word" [2], a market of legacy incumbents like HP, IBM, CA and BMC selling software for millions a year that never worked and that everyone resented, plus a long tail of small shops and open source, so entering it looked like a slog on both ends [2]. Cloud was left out because in 2013 enterprises still thought it was a toy [2]. The result was mumbo jumbo that left prospects unsure what the product did.

It took two and a half years to arrive at the honest version: a service that wakes you up in the middle of the night when your application is on fire [2]. That clarity changed behaviour as well as messaging. Before it, users could send data and look at it, then move on with their lives. Once the product woke people up, it became part of their daily routine, "not necessarily the best moments" but part of it nonetheless [2]. He is similarly wary of the word platform, which he calls overused, and admits they claimed one in the early days when what they had was very limited [2]. The platform came year after year, built on top of a single workhorse product, metrics, which would measure anything from CPU and memory to clicks, and in some hands solar panels [2].

On reading the ecosystem for signals

Much of Le-Quoc's strategic reasoning is signal-reading rather than forecasting. Enterprise users appearing at re:Invent in 2014 told him they were curious, and curiosity meant they would try, and if they tried, a cloud-native monitoring company was well placed [2]. The absence of banks that year told him the shift was not settled. When Capital One stood on stage in 2015 declaring itself all in on cloud, the significance was not one bank's decision but the permission it gave a heavily regulated industry [2]. Docker sold out his 2014 session with a line around the block, and he is clear this was not about him: "I'm not a physically good speaker" and the content was basic [2]. The demand itself was the datum, and it justified investing money and energy in containerised environments before it was clear Docker was not a fad [2].

The other habit is asking what else your users already run. Seeing that nearly every Datadog user also had New Relic told him two things at once: APM mattered, and the two products were complementary, since customers evidently needed both to get answers [2]. He guards the method against overreach with a counterexample, that users also being on Slack is no reason to build a chat product, because that is not the problem space they are in [2].

On bottom-up adoption

He describes two ways large companies buy technology: the top-down route where you wine and dine and play golf with the CIO for a hundred-million-dollar decision, or the bottom-up route of convincing users one at a time inside the enterprise [2]. Open source opened that second path and cloud followed it, since AWS took hold through someone in the trenches putting a department credit card down and running shadow IT until finance noticed the charges, at which point developers had already discovered they no longer waited six or twelve months for a piece of metal [2]. Datadog took the same road deliberately, and still does: try it for free, no call, and critically not a stripped-down demo account but the real thing [2].

On building the right way for the long term

The stated ambition is a business built for the long term, which means a profitable one, because unprofitable companies do not last, and one that keeps investing in itself, because in tech a company that slows innovation stops being relevant [1]. That translates into an explicit refusal of shortcuts, quick wins and instant gratification on social media, which is why the founders are rarely visible on the networks, and a preference for what will still be high value in two, three or five years [1]. Le-Quoc's own long-standing formulation of the customer side of this is that "the best way to proceed in good times and in bad is to be honest and trusted long-term partners to our customers and community" [1].

Location reinforced it. Raising money in New York for an infrastructure company was hard when they started, and the founders' account is that this kept them out of the Bay Area echo chamber and pushed them toward the customer and toward a sustainable business rather than toward capital [1]. His view now is that the constraint has lifted and a company can be scaled pretty much anywhere [1]. He is equally frank that the path never delivered a moment of certainty: there were highs and lows and never a clear signal that they had nailed it and only had to execute, which is a reason to stay humble about outcomes [2].

On culture as behaviour rather than posters

Datadog does not put values on the walls, and the reasoning offered is that companies which do usually fail to live up to them [1]. The alternative is showing what good looks like by doing it, which for founders meant handling HR, accounting, filling the fridge and plunging the toilet, with no sense that any job was beneath anyone at a headcount of two, three or five [1]. Because the values were never formalised, behaving by them was the only way to transmit them, which in turn requires believing them deeply [1]. The same instinct shows in what he looks for in people, with an emphasis on bringing in talent that is driven and excited by the day to day, alongside a deliberate investment in the relationship with the open source community [3].

On complexity, AI and unlearning your own habits

Le-Quoc frames observability as the discipline of keeping pace with software complexity [1]. He describes an application physically as a bunch of blinking lights and hot computers in a data centre, from which a human can learn nothing without software to say whether the app is up, where it is slow, and whether the disk is about to fill [2]. That framing carries into how he thinks about AI, where the interest is in end-to-end models reducing manual intervention so teams can spend their time building rather than firefighting [1]. The founders are equally clear about the personal difficulty: after two decades of working without AI, the honest approach is to keep trying tools repeatedly, because something that did not work three months ago may work perfectly now, and internalised habits from previous decades quietly become wrong [1].

Takeaways

• Founders of developer tooling usually start from their own problem; Le-Quoc started from years of building for teachers, and drew the lesson that "we're not a good proxy for the customer" [1].
• Open customer conversations with a question rather than a pitch, and go where practitioners talk in "battle scars" rather than theory [1].
• It took two and a half years to replace jargon about actionable insights with the honest description of a service that wakes you up in the middle of the night when your application is on fire, and that clarity is what made users return daily [2].
• Avoiding the words monitoring and cloud in 2013, because one market looked like a slog and the other looked like a toy to enterprises, cost the company clarity about its own identity [2].
• Read demand signals rather than forecasts: enterprise attendance at re:Invent, a sold-out Docker session, and Capital One on stage were the evidence that justified betting on containers and cloud [2].
• Ask what else your users already run, which is how APM and complementarity with New Relic became obvious, but do not extend the logic to problems outside your space [2].
• Bottom-up adoption requires a genuinely free real product, not a stripped-down demo, and no immediate sales call [2].
• Values that are lived rather than posted on walls are transmitted by founders doing every job, from accounting to plunging the toilet [1].