摩擦日志、工程师度假和 45 分钟上线：Stripe CTO 如何让工程师像产品经理一样干活

Asked why Stripe alumni keep appearing as standout guests, Singleton starts with the company's purpose. Stripe's core thesis is that the internet economy will keep growing, and it set out to make it easier for businesses to start and operate in it. The founders, John and Patrick, had found that accepting payments was as painful as they had expected building data-center hardware to be, and that pain inspired the company.

Singleton says Stripe decides what to build by watching its users closely. When it sees a need that sits next to something it already does, that is the invitation to build the next layer of what he calls economic infrastructure for the internet. The mission, "increasing the GDP of the internet", draws people who like digging into hard problems quietly, think long term and want to work collaboratively.

Stripe is happy to be slow when hiring for critical roles. Managers may meet tens or hundreds of people for a leadership job, and they keep building a relationship with someone who isn't yet available. Hiring is a personal activity run alongside an excellent recruiting team, not a machine that hands managers candidates. Singleton also stresses the learning opportunities: many Stripes now do jobs quite different from the ones they joined for.

As an example of curiosity at work, Singleton points to Jeff Weinstein, the PM for Stripe Atlas. Jeff's team kept asking whether the long wait for an IRS Employer Identification Number had to be that way. They eventually worked with the IRS so that Stripe could issue the numbers almost instantly at sign-up.

Two things are common to hiring for every role, Singleton says. The first is a structured loop that is consistent across candidates, so interviewers learn what a normal range of answers looks like and what a question actually reveals. The process is personal in how candidates are courted but consistent in how talent is evaluated.

The second is that nothing is a trick question; Stripe tries to recreate doing the real work together. Engineers do several coding exercises while sharing their screen, in what amounts to pair programming. They can search Google or Stack Overflow and ask the interviewer questions, because Stripe only cares about the outcome. PM candidates complete a written exercise on a real problem in their own time and then work through other exercises with an interviewer over Zoom.

Stripe waited a long time to hire its first PM, but Singleton says the early engineering team was extremely product minded and effectively acted as PMs. The first product was developer focused, and he argues the best PMs for developer products are technical, often former or current engineers who bring user insight and strategy. Every early team member had to work that way.

Stripe's approach is to pick the right early users and co-create with them. For Stripe Billing, the team worked with existing users such as Figma and Slack that were pushing subscription business models. They set up shared Slack channels, showed the product regularly and went to a broader audience only once that alpha group was very happy.

Product building is also unusually cross-functional at Stripe. Because many products abstract over differences between countries' financial systems, partnerships, legal, risk and compliance teams join the early phases. Singleton says PMs are the linchpin of this: they run the cadence that pulls partners together, synthesise what the company learns from users, and bring the longer-term strategy that makes today's choices ladder up.

Stripe's operating principles are less abstract than typical corporate values. Early on, the team stepped back to write down what had made them successful, and the principles are distilled from the most effective Stripes. They are used constantly in feedback and in celebrating each other's work. The first principle is "users first", and other examples include moving with urgency and focus and being meticulous in your craft.

Singleton's example of craft is that, when he tried Stripe before joining, an API error message linked straight to the docs that explained the fix. Few companies did that then, but a developer who hits an error is at a high-stakes moment. He adds that the code handling such edge cases in the services behind the Stripe API outweighs the code for the main flow, and users often tell him it delights them.

Stripe decides where to sweat details through friction logging, in which you adopt a clear user persona, such as an engineer at a large SaaS company, and go through the product. Singleton walks through dashboard, docs and code while taking careful notes. The places where that persona struggles are where Stripe invests heavily.

The payoff is measurable. Stripe tuned its payment element and hosted Checkout, removing latency and clicks, and found that users who moved from a vanilla custom checkout saw average revenue rise 10.5%. The same thinking led to Link, its one-click checkout. Singleton also explains that the polished website, with its spinning globe and animated wave, is meant to show the care behind infrastructure users cannot easily inspect.

Almost every Stripe product team has someone, often the PM or engineering manager, who regularly runs the end-to-end flow and writes a friction log. Singleton has onboarded as a user once a month for years, then tagged the people who need to act. With thousands of engineers working in parallel, the regular look at the whole product keeps experiences from diverging. The template is simple: state the goal, name the user you are modelling, keep a stream-of-consciousness log, and praise what works.

To keep such polish from clashing with roadmaps, Singleton says Stripe's planning is wired around users first and craft. Incident remediations, which come from reviewing what went wrong, are prioritised ahead of other roadmap work. PMs are expected to reserve some capacity for polish and operations, though there is no fixed percentage; each team decides how much to set aside.

UX reviews are done together as well as alone. The team, cross-functional partners such as support, and executives imagine themselves as a particular user and walk through the product while anyone can add to a shared issue log. Afterwards they discuss each issue. Singleton compares it to a chef tasting soup with the kitchen staff. Occasionally Stripe does "Walk the Store" with the entire company in its Friday Fireside meeting.

A value needs a practice behind it, Singleton says, and he advises teams to pick metrics that represent the experience they want and review them predictably. For anyone presenting to a CTO, his advice is to put on the user's hat and anchor every question back to what the team is trying to do for users. He also tries to anchor his own feedback in the user experience, since an offhand remark from a senior leader can be taken out of context.

Asked for advice on building better product, Singleton goes back to the loop of listening to users, getting something into their hands quickly and feeding their reaction back. If that loop does not exist, build it; if it is slow, speed it up. He notes how often it is missing across the industry, and that Stripe invests in developer tooling so that changes can reach production continuously.

Managers at Stripe are asked to be the editors in chief of their teams' plans, which requires understanding on the ground where teams get stuck. Singleton does what he calls an engineer occasion, a play on vacation. He clears three or four days, joins a team and picks up a small feature that can go from start to production, experiencing the team's tools, build infrastructure, reviews and documentation firsthand.

He keeps a friction log during the stint and writes it up, both as memory for later prioritisation and to share with the team. He advises new engineering managers to do one in their first quarter or six months. His first was hard because he had never written Ruby, but a buddy on the team taught him and the team appreciated that he did it. He asks the reviewers of his pull requests to treat him like anyone else.

One lasting lesson from these stints is that automation and good documentation often beat asking a colleague in another time zone. Stripe's developer productivity team runs the same product process for internal users, with a monthly survey sampled so each person answers only about every six months. It combines those answers with measurements of where people get stuck to set its roadmap.

Lenny cites a tweet saying Stripe deploys its core API 16.4 times a day on average with 99.999% uptime. Singleton says the stakes are high because users' revenue and payroll depend on Stripe, and it now moves as much money as all of e-commerce did when it started. Still, Stripe rejects the idea of reliability through never changing anything, because user needs evolve rapidly and feedback requires shipping.

The system rests on automated tests, since manual testers could not cover the range of API endpoints and configurations. Every change runs through the battery of tests, then through increasingly realistic staging environments, and finally reaches production at a small fraction of traffic before ramping up. A change typically lands in production automatically about 45 minutes after it is submitted: roughly 15 minutes of tests in parallel with review, 15 more after merge, and about 30 minutes for deployment.

Because things will still go wrong, Stripe invests in redundancy, isolating failures between users and strong incident tooling. Then it reviews incidents to prevent whole classes of issues, and prioritises that work ahead of the roadmap. Singleton says nothing is finished, and recent additions include chaos testing and selective test execution. He notes the distributed change-and-test environment is the biggest distributed system Stripe runs.

The biggest productivity wins, he says, were the auto-deploy mechanism, which ended the need for an engineer to babysit each production deploy, and an auto-merge tick box on pull requests that removes a human step once the reviewer approves. He says such small, deliberate changes ladder up to a big impact, as with checkout optimisation.

Singleton notes Stripe has used machine learning at the heart of its products since the start, in Radar for fraud and in catching bad actors. Transformer technology went into those systems more than a year before the interview and had a profound impact. He also says Stripe is privileged to serve many AI startups, which need monetisation from day one because GPU compute is costly, and he cites OpenAI as using Stripe for ChatGPT Plus subscriptions and revenue operations.

Stripe began working with OpenAI in a private GPT-4 beta early in the year. One result is a docs assistant that has the model read Stripe's documentation, store it as embeddings and answer developers' questions, released in an early form. Another is a natural-language interface for Sigma, which lets users query Stripe data in SQL, so non-developers can ask a question and have the engine write the query.

Internally, because Stripe's data is sensitive, it stood up an integration to GPT-4 with its own UI rather than telling people to use ChatGPT. It added shareable prompt presets, and Singleton says writing prompts is accessible beyond engineers, with marketing and support also using them. He uses a preset to write blog posts in the right tone.

For coding, Stripe ran a rigorous trial of Copilot and then made it widely available to engineers, who reported higher productivity and more time on bigger design problems. Singleton says it is too early to quantify the impact, but it seems especially useful for generating the boilerplate in tests. He loves writing code himself and says he enjoys doing it with Copilot because it frees him for the parts that matter.

As his teams grew, Singleton learned that he would not be involved in most of the decisions that matter, since every engineer and PM makes many each day. The most important thing is hiring people who can be trusted with autonomy, and he leans on references because they draw on thousands of hours of experience against the roughly eight hours of an interview loop. He then advises being generous with trust at the start and holding people accountable, delegating a bit more than is comfortable.

He stresses managing your own time rather than letting the inbox and calendar decide. For about ten years he has run a Sunday ritual of reading what happened last week and writing a list of what would make the coming week a good one. He also says how leaders show up consistently sets the culture around them, and that managing your own energy matters, including doing some tasks that give you joy.

Planning at Stripe, he admits, does not score the highest internal promoter score, partly because rapid growth keeps forcing the process to change. Stripe tends to think from first principles and learn from other companies, such as talking early on with Amazon's Charlie Bell. It plans in depth once a year with a lighter mid-year pass, and it is clear about which users each team serves, from tiny startups on Atlas to the largest enterprises.

The process runs as an inverted W: teams surface their thoughts, product leaders synthesise a draft company strategy, teams adjust their plans in response, and the result goes back up for a final synthesis before it is distributed with context. Singleton says this works well at Stripe's current scale.

Looking ahead to Stripe Sessions, Singleton says several announcements were crafted with users for some time. Billing features built with companies like Atlassian and Cloudflare let businesses model deals with different terms across years, and are going to general availability. He also describes how Stripe Connect grew out of working with Lyft and Shopify, and how Stripe made dashboard features available as embeddable, customisable UI components for platforms.

In the lightning round, he recommends Andy Grove's High Output Management, Tony Fadell's Build and Claire Hughes Johnson's Scaling People. He praises YouTube, including Andrej Karpathy's channel, for learning about AI. His favorite interview question asks which leader the candidate most admires, how that shows in their own style, and what development feedback they would give that leader if they were the manager.

The product he recently loved is Midjourney, whose Discord interface seemed wrong at first but lets users learn prompting from others. He uses it with his nine-year-old daughter to make illustrations for her stories. The small change with the biggest impact is a crying-octopus button in every Stripe developer tool, which lets engineers log a "paper cut" for the developer productivity team to read and prioritise.