David Singleton on Stripe

Source: Lenny’s Podcast Speaker: David Singleton Source URL: https://www.lennyspodcast.com/david-singleton/

Key ideas

Co-creation with reference users: Stripe’s product development model — find the right early users, build with them in shared channels, release to the broader audience only when the alpha group is fully satisfied. (Stripe Billing: co-created with Figma, Slack, others.)
Friction logging: a stream-of-consciousness product experience log from a specific user persona’s perspective; the mechanism that makes “be meticulous in your craft” real. Small compounding improvements measured at 10.5% revenue uplift on checkout.
Engineer-cation: 3-4 days of clearing your calendar to actually join a team and write code, producing a friction log of the internal developer experience. Used by David and Stripe engineering managers to maintain technical context at scale.
Operating principles as distilled behaviour: Stripe’s operating principles (users first; be meticulous; move with urgency and focus) are behavioural norms distilled from observing the most effective Stripes — not abstract aspirations.
Reliability and speed simultaneously: 16.4 deploys/day, 99.999% uptime achieved by designing for both at once — 45-minute code-to-production pipeline, staged rollouts, selective test execution, instant remediation prioritised above roadmap.

Hiring at Stripe

Stripe’s approach:

Mission as filter: people come because they want to help businesses scale and see the internet economy grow. This self-selects for people who want deep autonomy, long-term thinking, and collaborative problem-solving.
Patient and personal: for critical roles, willing to wait months or years. Hiring managers form real personal relationships with candidates before and during evaluation.
Consistent structured loops: same evaluation process for every candidate. Nothing is a trick question. Exercises mirror the actual job as closely as possible.
Engineering interviews: pair programming, shared screen, Google/Stack Overflow welcome — judges outcome and approach, not recall.
PM interviews: written exercise (candidate’s own time, with suggested time limit), plus live interviewer sessions. Looks for curiosity, collaborative problem-solving, ability to dig into details.
References: treated as the highest-conviction signal for leadership hiring. 8 hours of interviews vs. thousands of hours of direct experience. Asks critical questions — including what performance feedback the reference would give the candidate.

Product development: co-creation model

Stripe’s model: find the right set of early users who have the problem acutely, co-create the product with them, validate before broader release.

Stripe Billing origin:

Identified existing Stripe payments users (Figma, Slack) with subscription models.
Recognised this category of company would proliferate.
Created shared Slack channels with alpha group.
Showed product regularly, incorporated feedback continuously.
Only expanded when alpha group was fully satisfied.

Adjacent problems as expansion signal: when users push the boundaries of an existing product to solve adjacent problems themselves, that is Stripe’s “invitation to build the next layer.” Stripe Connect emerged from Lyft and Shopify using payments to build multi-sided marketplaces.

This mirrors the Reference Customer technique — alpha users function as reference customers.

Operating principles

Not abstract values — behaviour distilled from observing effective Stripes. Structured in three categories: how we work, who we are, what leaders must execute.

Key principles:

Users first: form deep personal relationships with users; let those relationships guide all decisions.
Be meticulous in your craft: sweat the details in the places that matter most (identified via friction logging). Not universal perfectionism — selective depth.
Move with urgency and focus: infrastructure built for decades still needs to solve user needs right now.

How values become real: “Almost anything that you talk about is a value. You need to have a practice behind that.” Meticulousness without friction logging would remain aspirational.

Friction logging

A structured user experience quality practice:

Define a specific user persona (not “a developer” — “an engineer at Atlassian integrating Stripe Billing for the first time”).
Go through the full product flow from the entry point: dashboard, docs, code, integration.
Keep a stream-of-consciousness log — everything encountered, friction and excellence alike.
Tag the relevant people for each friction point.
Share broadly — recognise excellent work, surface gaps.

Cadence: most product teams have a PM or engineering manager run a friction log monthly. David personally onboards as a new Stripe user once a month.

Why it works: maintains a cohesive quality standard across thousands of engineers working in parallel; turns “meticulous in your craft” from a value into a measurable practice.

Template: publicly available at stripe.dev.

Walk the Store: the whole-company version — David presents product walkthroughs at the Friday Fireside all-hands, imagining a specific user together. Builds shared language and shared quality bar.

Engineer-cation

What: 3-4 consecutive days where an engineering manager/CTO clears their calendar, joins a team, picks up a small end-to-end task, ships it to production, and keeps a friction log of the internal developer experience.

Why: at scale, engineering managers make no individual product decisions. If they lose technical context, they can’t evaluate tradeoffs, mentor engineers authentically, or prioritise accurately. The engineer-cation restores that context.

How:

Identify a buddy on the team to help.
Pick a task small enough to complete within the block (including production deployment).
Keep a detailed friction log of the internal developer experience.
Write a report; re-read periodically; share with the team.
Treat calendar clearance like a vacation (the world continues without you).

When: new engineering managers in first quarter to six months. Then annually.

Signal: David joined Stripe having never written Ruby. His first engineer-cation was learning Ruby with a buddy. The team appreciated the demonstration of willingness to learn.

Reliability engineering

Scale: 16.4 deploys/day to core API; 99.999% uptime; money volume equivalent to all e-commerce when Stripe launched.

45-minute code-to-production pipeline:

PR submitted → parallel automated test run (~15 min, runs alongside human review).
PR merged → full test suite re-runs (~15 min).
Staged rollout to production (~15 min): starts at small % of traffic, ramps to 100% with automatic monitoring.

Key enablers:

Selective test execution: for individual PRs, only material tests are run. Full suite post-merge. Enables fast feedback without sacrificing coverage.
Auto-merge: one checkbox on the PR → system takes over once reviewer approves. Removes a human synchronisation step.
No manual testers: API surface too large; all coverage is automated.
Instant remediation above roadmap: fixes for things that went wrong are prioritised over new features.
Chaos testing: inject errors proactively to verify resilience.
Post-incident reviews: focus on class-level prevention, not just this incident.

Planning: inverted W process

Teams surface bottom-up priorities.
Product leaders synthesise a draft company strategy.
Draft returned to teams: does this change your plans?
Teams refine; bubbles back up for final synthesis.
Final plan distributes down with full context.

Two annual cycles: full annual plan + lighter mid-year review.

Key constraint: every area must be clear about which users they’re serving — Stripe serves from early-stage startups (Atlas) to Fortune 1 companies, with very different needs.