No PriorsNo Priors Ep. 21 | With Datadog Co-founder/CEO Olivier Pomel
CHAPTERS
- 0:05 – 1:44
Olivier Pomel’s path: demo scene, VLC, and early startup years in the US
Olivier shares his early fascination with computers through the European demo scene and his time contributing to VLC. He traces his move to the US in 1999, work at IBM Research, and experiences through the dot-com era that shaped his startup instincts.
- •Early influence of real-time graphics and the European demo scene
- •Contribution to VLC and lessons from open-source communities
- •Move to the US via IBM Research; expecting a short stay that became permanent
- •Startup exposure around the dot-com bust and subsequent years in SaaS
- 1:44 – 3:08
Datadog’s origin story: fixing the dev vs. ops conflict with a shared platform
Datadog started less as a “monitoring company” and more as a response to persistent friction between development and operations teams. Olivier explains the founding insight: create a common place where both sides can see systems the same way and collaborate effectively.
- •Co-founders ran dev and ops teams yet still saw entrenched conflict
- •Initial motivation: alignment and shared context, not “cloud monitoring”
- •A platform-centric vision to reduce finger-pointing and improve coordination
- •Collaboration as the product thesis underlying observability
- 3:08 – 6:17
Building Datadog in New York: fundraising skepticism, customer proximity, and retention advantages
The conversation turns to Datadog’s decision to build in NYC despite investor skepticism about infrastructure startups outside the Bay Area. Olivier argues NYC helped them stay grounded in real customer needs and build an efficient, durable company due to stronger retention.
- •NYC as a deliberate choice for life reasons and access to strong engineers
- •Fundraising was harder due to location and non-traditional background
- •Constraint drove efficiency and near-profitability discipline early on
- •Benefits: less “echo chamber,” better customer signal, higher employee retention
- 6:17 – 7:26
Why it’s called Datadog: “Datadog 17,” painful databases, and the puppy brand
Olivier explains the surprising name: Datadog was originally an internal server naming convention, with “DataDogs” as production databases. The team kept the codename, dropped “17,” and embraced the friendly puppy logo as a standout branding choice.
- •Production servers were named after dogs; databases were “DataDogs”
- •“Datadog 17” was a feared, mission-critical Oracle database
- •The codename stuck because everyone remembered it
- •Dropping “17” and choosing the puppy became a defining brand win
- 7:26 – 8:39
Datadog 101: end-to-end observability across infra, apps, users, and teams
Olivier gives a crisp overview of what Datadog does: aggregating signals across infrastructure, applications, deployments, user experience, and logs/traces/metrics. He also outlines the buyer/user map—ops and DevOps often buy, while developers are the primary daily users, with security and product roles also participating.
- •Unifies signals: infra, app behavior, changes over time, and user activity
- •Core telemetry primitives: metrics, traces, logs (plus broader context)
- •Primary buyers: ops/DevOps; primary users: developers/engineers
- •Expands usage to PMs, security engineers, and adjacent functions
- 8:39 – 12:01
Generative AI’s demand shock: more software, more infra, and more need to understand systems
Olivier separates AI’s impact into demand-side and solution-side effects. On the demand side, he expects far more applications built by more people, which shifts value from writing code to understanding, securing, operating, and fixing it—areas where observability becomes even more critical.
- •AI increases engineering output but can reduce individual understanding of what’s shipped
- •Value shifts toward operating, securing, and debugging complex systems
- •AI services drive explosive new workloads (training + inference infrastructure)
- •AI accelerates cloud migration and digitization prerequisites for adoption
- 12:01 – 14:32
The emerging AI stack: frontier APIs vs. open source models, and rapid component churn
The hosts probe which AI infrastructure components will “stick,” and Olivier emphasizes the unusual speed and uncertainty of this market compared to prior platform shifts (VMs → containers → Kubernetes → serverless). He highlights open-source model progress and predicts hybrid strategies where companies prototype with frontier APIs while planning partial in-house hosting over time.
- •Harder to predict winners vs. past infra transitions due to rapid iteration
- •Open-source innovation is advancing faster than expected for targeted use cases
- •Common pattern: prototype with OpenAI-like APIs, later internalize with OSS models
- •Expect the stack picture to look very different in 12–24 months
- 14:32 – 17:24
Observability for LLM apps: monitoring models, vector DBs, GPUs—and the rise of “LLMOps”
Olivier argues AI systems still need traditional observability (metrics/traces/logs), but with new components: model providers, retrieval systems, and specialized compute like GPUs. He also explains why prior “MLOps” was fragmented (small data science teams, bespoke needs) and why LLMs may finally create broadly applicable operational tooling for everyday developers.
- •AI adds new components to observe: LLM APIs, vector stores, hosted models, GPUs
- •Traditional observability primitives still apply, but coverage must expand
- •Shift from MLOps (bespoke, data-scientist driven) to LLMOps (developer-driven)
- •New focus: correctness, drift/change over time, and app changes affecting outputs
- 17:24 – 19:17
Unified platform strategy and resourcing: platform vs. products, and how categories evolve
Sarah asks how Datadog balances platform investment with new initiatives like AI. Olivier explains their rule of thumb: roughly half the company builds the core platform, enabling fast product iteration across many use cases. He also notes the tension between how customers buy (legacy categories/SKUs) and how Datadog builds (forward-looking integration), predicting category consolidation over time.
- •~50% of the team works on the shared platform; ~50% on problem-focused products
- •Internal teams organize around future problems; external SKUs mirror current buying habits
- •Expect observability subcategories (infra/APM/logs) to converge into a unified super-category
- •Unified platform creates leverage but requires continuous foundational investment
- 19:17 – 23:15
M&A as product acceleration: re-platforming acquisitions and a “ship in 3 months” integration rule
Olivier details Datadog’s acquisition approach: buy to accelerate specific product areas by a few years, then re-platform onto Datadog’s unified core for end-to-end integration. Success hinges on founder intent (builders vs. tired sellers) and an aggressive integration cadence designed to demonstrate value quickly and maintain internal trust.
- •Acquisitions map to product areas Datadog wants to build anyway
- •Immediate re-platforming onto Datadog’s core is a deliberate (costly) differentiator
- •Prefer entrepreneurs who want to keep building post-acquisition
- •Integration discipline: ship something together within 3 months to prove value and build trust
- 23:15 – 26:09
How Datadog decides what to build next: following customers and leveraging surface area
Elad asks how Datadog sequences expansion across many categories. Olivier describes a long initial focus on infrastructure monitoring (catching up to demand) and then a customer-led expansion model: watch what customers hack together on top of Datadog, then turn the most common needs into first-class products—powered by Datadog’s pervasive deployment footprint.
- •Spent ~6–7 years perfecting the first product before broad expansion
- •Cloud re-platforming created a rare chance to enter a sticky market
- •Product roadmap often follows customer DIY solutions (e.g., “poor man’s APM”)
- •Secret weapon: deployed broadly across servers and used daily by many engineers
- 26:09 – 28:40
Entering security: focusing on outcomes, ubiquity, and developer/ops-driven operationalization
Security is framed as a bigger leap than adding more observability products because buyers and users differ. Olivier argues the market has plenty of tools but poor outcomes; Datadog’s bet is that security improves when it’s operationalized broadly by developers and ops, delivered everywhere like an “always-on IV,” rather than only sold as sharp point solutions to CISOs.
- •Security differs due to distinct buyers/users vs. observability expansions
- •Plenty of security products exist, but outcomes haven’t improved proportionally
- •Datadog’s thesis: deliver security ubiquitously across infra/app layers
- •Initial emphasis on adoption and operationalization over top-down CISO sales motion
- 28:40 – 36:33
AI inside DevOps workflows: precision requirements, combining LLMs with system state, and paths to automation
The group explores where AI helps most in Datadog’s domain. Olivier cautions against AI over-marketing because operations demands extreme precision and low false positives, but he’s optimistic about new capabilities when LLMs are grounded with real system context (e.g., stack traces plus program state) and combined with numerical models and knowledge sources.
- •Operational tooling needs very high precision; false positives quickly erode trust
- •Classic statistical/ML methods remain essential for streaming numerical detection
- •LLMs unlock value from previously “off-limits” unstructured context (wikis, threads, metadata)
- •Grounding example: stack trace alone misleads; adding program state enables accurate diagnoses
- 36:33 – 44:18
Near-term AI productivity gains and leadership lessons: efficiency discipline, faster iteration, and broad customer segmentation
In closing, Olivier discusses where AI helps immediately (drafting/authoring, faster API learning for developers) and where it may reshape workflows (e.g., commoditizing email marketing). He also shares Datadog’s operating discipline—built for efficiency from day one, tuning for customer value in tighter markets, iterating faster in AI—and why serving both small teams and large enterprises works in today’s cloud/open-source era despite commercial complexity.
- •Near-term wins: writing/drafting assistance and developer productivity for new APIs
- •Some functions may be structurally rewritten as AI makes old tactics inefficient at scale
- •Datadog operating model: profitability-minded, sustainable systems from the start
- •Serving SMB to Fortune 100 is enabled by shared cloud/open-source tooling; challenge is balancing messaging and commercial motions
