Thread by @patio11

Inbox: "How does Stripe maintain a high level of polish?"

Some thoughts, in my personal capacity as someone who writes code occasionally and knows a bit of the story but isn't involved in it daily:

Table stakes are table stakes: hire a sufficient number of smart people who are quality oriented and reinforce that you are a quality-seeking culture. This includes celebrating it where it is, routinely formally evaluating large swathes of what you're doing for it, and fixing.

Tactically, among the best things you can do is decreasing the effort required to do the right thing.

We make the various technical tradeoffs required to allow substantially any engineer to contribute a PR against any just about any part of the systems. Encourages ownership.

Concrete example of this: we had untranslated text appear recently in a page that should have been localized. Many organizations will land on "If you notice that, open a ticket with the localization team. Their SLA for a response is two weeks."

We have "open up a ticket with appropriate team and somebody will take care of it" as an option, too, but the closer you can push your systems to making just fixing the thing faster and more reliable than filling out the ticket, the more often you'll incent people to do that.

I also took an hour or so to use an internal tool to assert an invariant that pages in X language should only have up to Y level of English, and to page a responsible engineer if that invariant ever fails in the future. (This is not a test, for boring localization tech reasons.)

Note that this comes back to the company culture thing, because senior ICs in marketing talking about what they did that week who say "Oh and I spent some time on localization engineering" need to know that their leadership and the company will say "Of course you did, cool cool."

I mentioned recently that another thing we do is having an internal alias to report product quality oriented bugs. A team triages either fixing them or getting them to the right part of the organization to fix, and routinely keeps the company updated on the rate of flow in+out.

Before we make major changes to e.g. API integrations we do internal and external testing on it. There's often a call for "Who has a real, honest-to-goodness Stripe account lying around? Can you upgrade to the beta?"

Folks break out time to do that and exhaustively document it.

I saw a spreadsheet recently for this; imagine 20+ engineers implementing API consumers "for real" and being very, very nitpicky. We can't have the depth of coverage customers can, but beats the heck out of guessing.

(This is one of the relatively few times where "Hmm I don't think I've touched the payments code in that project since 2014, barely understand how it works, and have no tests" is a real asset to an engineering team.)

None of this is rocket science, and (in spirit of rigor) none of it is sufficient. We are actively dissatisfied with where quality is at the moment, not in the usual "Oh our standards are high" passive raising-the-bar dissatisfaction but in "Working on this actively" sense.

If working with very smart and dedicated people who profoundly care about this, up to and including senior leadership, sounds interesting to you, Stripe is hiring. stripe.com/jobs

A big shoutout to customers, too. We often go to ones we're close with and effectively co-create new releases with them: tight feedback loops, thorough mutual understanding of how X should operate in their business, and the mutual understanding that named people are working today

There's some substantial gnarly technical detail on "How do you expose three people in the world to new behavior of a core service while making sure not to change behavior for the other businesses processing transactions in real time?" and that might be a story for another day.