Notes — David Singleton on Stripe

Four questions [Adler frame]

Q1 — What is it about? How Stripe’s CTO approaches building and maintaining engineering culture at scale. Three interlocking threads: (1) how Stripe builds product — co-creation with early reference users, operating principles, and a set of named quality practices (friction logging, Walk the Store, UX reviews); (2) how Stripe runs engineering reliably — 45-minute code-to-production pipeline, continuous deployment at 99.999% uptime; (3) how senior leaders stay grounded in craft — the engineer-cation technique and Sunday evening planning rituals.

Q2 — How is it argued? Primarily through concrete examples and named practices: the Stripe Billing co-creation (Figma + Slack as early reference users); the IRS Employer Identification Number story (tenacity + user focus); the API error messages linking to docs (meticulousness compounding to 10.5% revenue uplift). The argument is empirical rather than theoretical — here is what we do, and here is the measured outcome.

Q3 — Is it true? Co-creating with early reference users is exactly what Christian Idiodi on Product Management calls the reference customer technique — validated independently. Friction logging as a practice is well-grounded in usability research (heuristic evaluation methodology, Nielsen’s 10 principles). The 10.5% revenue uplift from accumulated meticulousness is a strong empirical claim, plausible given checkout conversion dynamics. The engineer-cation technique is unusual but internally consistent — it addresses the well-known problem of engineering managers losing technical context as they scale. The inverted W planning process mirrors approaches at other companies (Amazon’s “work backwards” narratives + bottom-up input synthesis).

Q4 — What of it? For product builders: friction logging is immediately actionable — a stream-of-consciousness user experience log with a clear user persona in mind, shared broadly. For engineering leaders: the engineer-cation provides a structured mechanism for maintaining technical credibility at scale. For companies: the Stripe model of operating principles as behaviour-distilled-from-effective-people, not abstract values, is replicable. The compounding quality thesis — small improvements across many touchpoints add up to 10.5% revenue uplift — argues against the common trade-off framing of quality vs. speed: quality compounds and is ultimately faster.

Glossary

Friction log / friction logging — a stream-of-consciousness written record made while experiencing a product as a specific user persona, with particular attention to points of confusion, delay, or effort. Used to identify where meticulousness investment will have the highest impact. Done individually (async) or collaboratively (sync review). Template: state the user persona, state the task, keep a running stream of consciousness, highlight friction and praise excellence.

Engineer-cation — a portmanteau of “engineer” and “vacation.” An engineering manager or senior leader clears their calendar for 3-4 days, joins an individual team, picks up a small task (ideally a feature that can reach production within the block), and does the actual engineering work alongside a buddy from the team. Produces a friction log for internal developer tooling + infrastructure. Treated like a vacation in terms of calendar management.

Walk the Store — a Stripe practice of doing a friction-log-style product walkthrough with the whole company (via the Friday Fireside all-hands). Not just an executive review — a shared language-building exercise that aligns everyone on quality bar and user experience direction.

Operating principles — Stripe’s formulation of corporate values: not abstract aspirations but behaviours distilled from observing the most effective Stripes. Segmented into “how we work,” “who we are,” and “what leaders must execute.” First principle: users first.

Users first — Stripe’s first operating principle. Translated into practice as: form deep personal relationships with users, guide all product decisions from those relationships, and never hide the care and attention taken from users.

Be meticulous in your craft — Stripe’s operating principle around quality. Applied selectively (using friction logging to identify the highest-impact places) rather than universally. The principle is that small, compounding improvements in user experience ladders up to large measured outcomes (10.5% revenue uplift on checkout).

Inverted W planning — Stripe’s annual planning process: teams surface bottom-up priorities → product leaders synthesise a draft company strategy → draft goes back down to teams for adjustment → bubbles back up for final synthesis → distributes back down with full context. Two annual cycles: full annual plan + lighter mid-year review.

Continuous deployment — Stripe’s engineering practice of automatically deploying every merged change to production within ~45 minutes (15 min parallel test run + 15 min post-merge test + 15 min staged production rollout). Changes are ramped from small traffic percentage to full traffic, with automatic monitoring at each stage.

Selective test execution — an internal Stripe innovation: for individual PRs (pre-merge), the test system identifies which tests are material for the specific change and runs only those, reducing feedback loop time. Full test suite runs post-merge before production.

Instant remediation — Stripe’s term for the actions taken when something goes wrong in production. Prioritised above roadmap work. Combined with careful post-incident review to prevent entire classes of future issues.

Co-creation with reference users

Stripe’s product development model is to identify the correct set of early users with the problem, co-create the product with them, and only release to a broader audience when that alpha group is “super, super happy.”

Stripe Billing example:

Identified companies already using Stripe payments but operating subscription models: Figma, Slack, and others.
Recognised these represented a category of companies that would proliferate.
Created shared Slack channels; showed product on a regular basis to get feedback.
Only released to broader audience when alpha group was fully satisfied.

This is structurally identical to Reference Customer technique (Idiodi): the alpha group functions as reference customers. The difference: Idiodi’s method is explicit about the threshold (6-8 for B2B), Stripe’s is governed more by qualitative satisfaction level.

Stripe Connect origin:

Companies like Lyft and Shopify were using Stripe for pay-ins but had multi-sided marketplace needs.
Working closely with them revealed an entirely new product category.
Pattern: paying close attention to adjacent problems users are solving themselves is Stripe’s “invitation to go and build the next layer.”

Friction logging (full process)

Purpose: identify where to invest meticulousness — not all details matter equally, so the process surfaces the highest-impact spots.

How to run a friction log:

Define a specific user persona to model (e.g., “an engineer at Atlassian actively integrating Stripe Billing for the first time”).
Actually use the product end-to-end, starting from the relevant entry point.
Keep a stream-of-consciousness log of everything encountered — friction, confusion, delight, excellence.
Pay particular attention to places where the modeled user would get stuck or frustrated.
Tag in the right people across the company who need to act on findings.
Share the doc broadly — praise the excellent things, flag the friction.

Cadence:

Many product teams: PM or engineering manager runs a friction log on the product end-to-end on a regular (typically monthly) cadence.
David personally: onboards as a new Stripe user once a month.
Senior leaders: recursive — each major area has a leader doing this for their whole scope.

Why it works: keeps cohesive quality high despite thousands of engineers working in parallel; provides regular ground truth against which plans can be calibrated; creates culture of shared quality bar.

Public template: available at stripe.dev.

Engineer-cation

Problem it solves: engineering managers and CTOs at scale are “above” the day-to-day work and lose technical context. They can no longer accurately evaluate tradeoffs, prioritise work, or help teams that are stuck. They also can’t validate that the developer experience is good.

The technique:

Clear 3-4 consecutive calendar days (treat it like a vacation — the world continues without you).
Identify a team to join and a buddy to work with.
Pick up a small task — ideally a feature that can be taken from start to production within the block.
Do the actual engineering work, including code review, build tooling, deployment, documentation.
Keep a detailed friction log of the internal developer experience.
Write a report. Re-read it periodically over the next year. Share it with the team.

Outcomes:

Friction log surfaces infrastructure and tooling improvements.
The CTO’s context informs the next year of prioritisation conversations authentically.
The team sees leadership’s genuine engagement and care.
Demonstrates it’s acceptable for senior people to say “I don’t know” (David arrived not knowing Ruby and learned it during the first engineer-cation).

Recommended cadence: new engineering managers in their first quarter to six months; then annually thereafter.

Reliability at Stripe scale

Stripe’s throughput: 16.4 deploys/day, 99.999% uptime, money volume equivalent to all e-commerce when Stripe launched.

Approach: hold continuous deployment and high reliability true simultaneously, rather than trading one for the other.

Pipeline:

Engineer submits change → automated test suite runs in parallel with human review (~15 min).
Change merged → full test suite runs again (~15 min).
~30 min for automatic staged production rollout (small % of traffic, ramping to 100%).
Automatic monitoring at each stage.
Total time code-to-production: ~45 minutes.

Enablers:

Selective test execution: for individual changes, tests are run only for tests material to that change (not the full suite). Full suite post-merge.
Auto-merge: engineer checks a box on the PR — once reviewer approves, system takes over. Removes one human distraction step.
Chaos testing: inject errors to verify resilience before production incidents.
Comprehensive automated test coverage (no manual testers).
Instant remediation prioritised above roadmap work.

Learning organisation: post-incident reviews focus not just on what caused this incident but what class of incidents can be prevented. Cultural expectation: things will go wrong; what matters is how systematically you prevent recurrence.

Management and leadership

Operating at scale: the manager is not involved in most decisions. The only way to operate at scale is to hire people you trust with significant autonomy, then actually give them that autonomy.

Trust by default: even new hires need to be trusted generously from day one. Sometimes this means hiring someone into a smaller role initially to build trust, then expanding scope.

Delegate a little more than comfortable: the only way to grow and operate at scale. Discomfort signals growth.

Sunday evening planning:

Sunday afternoon: read through what happened last week.
Sunday evening: write a list of “if these things got done this week, it was a good week.” This governs where attention goes through the week.
Stay dynamic — surprises happen — but the list ensures time isn’t consumed by random inbound.

Energy management: some tasks are energising even if not the most important. Do them. The energy carries over.

Showing up consistently: at scale, how a leader shows up IS the culture. Inconsistency under pressure is contagious. Model the operating principles even on hard days.

References in hiring: 8 hours of interviews vs. thousands of hours of the reference’s direct experience. References give the best conviction on senior hires. Ask smart questions — not “is this person good?” but “what would their performance review say?” and “what would you change about how they work?”