YC Root AccessHow Olivier Pomel Built Datadog By Refusing Every Shortcut
CHAPTERS
- 0:05 – 0:57
Datadog’s origin story: rejection (YC) and the “platform needs a product” critique
Garry Tan opens by framing Datadog’s founding mission—helping engineers understand what’s happening in the cloud—and asks about Olivier’s first YC experience. Olivier recounts applying in 2010, getting an interview, and being rejected, including PG’s feedback about platform success depending on the first product.
- •Applied to YC in 2010, interviewed, and got rejected
- •PG’s critique: a platform is only as successful as its first product
- •Olivier frames Datadog’s later success as proving the platform thesis
- •Early rejection as a common founder experience
- 0:57 – 1:43
Turning early doubt into culture: the “chip on your shoulder” and obsession with value
Olivier explains how early rejection and fear of failure shaped Datadog’s enduring culture. The team focused on building something genuinely valuable and a business that could survive even if fundraising didn’t work out.
- •Rejection can motivate founders and sharpen focus
- •Fear of failure drove rigor and discipline early on
- •Culture built around delivering real customer value
- •Emphasis on building a self-sustaining business
- 1:43 – 3:11
From France to New York: dot-com boom lessons and staying through the crash
Olivier describes moving from France to New York for an IBM Research internship and never leaving. He reflects on the dot-com boom’s irrational behaviors and the subsequent crash that reshaped the tech landscape.
- •Moved to NYC for an IBM internship; stayed for ~26 years
- •Worked at a startup during the dot-com boom
- •Noticed ‘red flags’ and unsustainable spending during the boom
- •Lived through the crash and the bleak post-bubble years
- 3:11 – 4:25
Meeting Alexis: campus hacking, reconnecting at IBM, and repeated collaboration
Olivier tells the story of first encountering Alexis in France when Alexis was caught hacking the campus network—and Olivier enforced the punishment. They later reconnected at IBM and proceeded to work together across multiple companies before founding Datadog.
- •Early encounter: Olivier ran campus network; Alexis was caught hacking it
- •Reconnected at the IBM internship in New York
- •Worked together at 4–5 companies over time
- •Relationship formed through long-term, repeated collaboration
- 4:25 – 6:04
The 15-year co-founder “marriage”: trust, time, and alignment on existential decisions
Olivier explains what makes a long-lasting co-founder relationship work: years of collaboration before starting the company, strong friendship, and deliberate time set aside to talk without an agenda. He emphasizes the importance of being truly aligned on high-stakes decisions like acquisition offers.
- •Worked together for 10+ years before founding Datadog
- •Maintain regular no-agenda time to talk and stay aligned
- •Acquisition decisions can fracture founders if misaligned
- •Honesty about goals prevents resentment and later blow-ups
- 6:04 – 7:32
Refusing acquisition offers and staying in the game: evaluating upside and personal motivation
The conversation turns to turning down buyout offers—first unimaginable sums, then progressively larger ones. Olivier explains the framework: remaining upside, whether the mission feels “done,” and whether the work still feels exciting and worth the commitment.
- •Turned down major acquisition offers multiple times
- •IPO context: priced ~7.5B, quickly traded higher; later much larger market cap
- •Decision lens: future upside (5–10x), belief in the roadmap, excitement to continue
- •Selling raises the existential question: “what would you do next?”
- 7:32 – 10:44
Building in the early cloud: investor skepticism, unique POV, and Dev+Ops unification
Olivier describes how hard it was to explain the market in 2010: they weren’t from legacy systems management vendors or hyperscalers, and most investors passed. Their outsider vantage point led them to focus on the real pain—Dev and Ops fighting—and building a single platform to unify them as cloud adoption surged.
- •Faced broad investor rejection beyond YC
- •Outsider founders: not from vendor incumbents or hyperscalers
- •Core problem: Dev and Ops conflict; unify workflows under one platform
- •Cloud adoption was underestimated—AWS seen as a “toy” in 2010
- •Timing and cloud’s breadth became central to Datadog’s success
- 10:44 – 13:27
How Olivier still runs Datadog: ‘look down’ systems, sampling reality, and avoiding managed-up narratives
Olivier explains his leadership approach at scale: management must understand what happens “on the ground,” not just polished stories. He samples support tickets, sales calls, product briefs, and releases, and occasionally asks questions to force visibility and accountability down the chain.
- •Scaling risk: teams ‘manage up’ and craft overly positive narratives
- •Countermeasure: force attention downward to customer/product reality
- •CEO habit: read support requests, sales conversations, and all product briefs/releases
- •Occasional direct questions create a ‘jolt’ that improves organizational awareness
- •Uses this as personal ‘training data’ to validate or challenge high-level stories
- 13:27 – 14:58
Approval vs autonomy: where executives must weigh in and how Datadog tests safely
Olivier outlines how Datadog avoids CEO bottlenecks: executive feedback is possible but not required for most work. Only high-impact, hard-to-reverse decisions (like pricing/packaging) require pre-approvals; many changes can be tested with subsets of customers before broad rollout.
- •Design principle: feedback is available, but progress shouldn’t wait for it
- •Mandatory approvals reserved for big, hard-to-reverse changes (pricing/packaging)
- •Many decisions are reversible; teams can move fast and iterate
- •B2B advantage: test changes with limited customers before full rollout
- 14:58 – 17:53
Deciding what to build next: customer-driven expansion, ‘strategic’ bets, and bottom-up innovation
Olivier explains Datadog’s product expansion engine: watch how customers use the platform, notice workarounds/extensions, then build what customers are already trying to assemble. He adds two other sources—top-down bets in areas with weaker direct signals and bottom-up ideas from teams solving internal or emerging problems.
- •Primary signal: customers’ behavior, extensions, and homegrown add-ons
- •Examples: infrastructure monitoring → APM/tracing; security automation opportunities
- •Three inputs: customer feedback (reliable but incremental), top-down ‘strategic’ bets (riskier), bottom-up innovation (team-led)
- •Maintain room for internal productization of platforms and experiments
- 17:53 – 18:31
Scaling the platform: 25 paid products, 8,000 employees, and a unified go-to-market motion
Datadog’s breadth has grown to dozens of monetized products and thousands of employees. Olivier emphasizes that despite the catalog size, the company avoids fragmented sales motions and aims for a simpler, platform-like adoption model similar to (but ideally better than) cloud providers.
- •Datadog sells ~25 paid products
- •Organization scale: ~8,000 employees
- •Platform adoption model reduces the need for many separate sales processes
- •Product breadth without fully splitting into many independent ‘mini-companies’
- 18:31 – 20:09
Surviving public-market shock: pandemic lockup timing, volatility education, and long-term execution
Olivier recounts the unusual timing of Datadog’s lockup expiring on the same day pandemic lockdowns began, amid a market crash. He explains how the company manages volatility by educating employees and emphasizing long-term fundamentals over short-term stock moves.
- •IPO in 2019; lockup expired the day lockdowns began
- •Experienced sharp drawdowns alongside broader fear and uncertainty
- •Markets can seesaw; the company normalizes volatility internally
- •All-hands framing: short term ‘voting machine,’ long term ‘weighing machine’
- •Focus stays on building the right products and serving customers well
- 20:09 – 23:29
Winning the AI wave: serving AI builders, AI users, and ‘AI for Datadog’ automation
Olivier explains why AI is both disruptive and opportunity-creating: it changes product needs and business models, but also drives more software, infrastructure, and complexity. Datadog built for AI-native customers while also embedding AI into Datadog to automate operations, contributing to business re-acceleration.
- •Observability leadership still leaves large headroom (13% share in a growing market)
- •AI disrupts product requirements and (for some) seat-based pricing models
- •Two initiatives: ‘Datadog for AI’ (AI companies + AI adoption) and ‘AI for Datadog’ (automation)
- •Serves many leading AI companies; segment is growing fast
- •AI increases complexity: GPUs, models, security, and massive code generation shift value to validation/ops
- 23:29 – 26:25
The self-healing system dream and internal AI adoption: coding agents, changing team structures, open questions
The conversation moves from AI-driven customer needs to the long-held goal of automation: systems that fix issues without waking humans at 2AM. Olivier shares how AI is already boosting engineering productivity at Datadog, while acknowledging unresolved questions about long-term workflows and the evolving mix of roles.
- •Long-standing industry goal: automated remediation; now ‘within reach’
- •Internal impact strongest in engineering; less multiplicative elsewhere (e.g., sales)
- •Company-wide adoption of coding tools/agents; step-change after new model releases
- •Open questions: what works long-term, and how team structures/roles will converge
- •AI accelerates Datadog’s broader mission of unifying roles on one platform
- 26:25 – 29:08
Advice to 2010 Olivier: hardships as strength, decide faster on people, and hire conservatively
Olivier reflects on what he’d tell himself at the start: the journey will be tough but survivable, and painful episodes often strengthen the company. He stresses faster decision-making—especially on hiring and firing—while also describing Datadog’s deliberate approach to scaling engineering to avoid dysfunction.
- •Hardships (rejection, security incident) improved culture and resilience
- •Key personal advice: decide faster—particularly on people decisions
- •Hiring/firing often happens too slowly relative to founder instincts
- •Datadog intentionally limited engineering team growth to avoid breaking productivity
- •Avoided 10x headcount ramps that can create long-lasting dysfunction
