Operating Well: What I Learned at Stripe

Original URL

https://every.to/p/operating-well-what-i-learned-at-stripe

It's a state, not an outcome.

Franz Harvin Aceituna | Unsplash

Over the last few years, I’ve grown from a fine to a good operator. Some of these lessons I learned by watching some great operators during my time at Stripe, and some I learned the hard way.

Operating well is a state, not an outcome. Peak performance doesn’t mean everything is working all the time—it’s a constant process of tweaking, iterating, tuning. And good operating doesn’t ever feel smooth to the folks on the inside—because that’s a moment to invest in expansion. It’s dynamic, adaptive, stressful, and fun.

Strategy & focus.

Reinforce your goals everywhere. Once you’ve set goals, you need to reinforce them everywhere. Constantly restate the goal and how it maps to your vision and strategy. Ask how every initiative contributes. The first order effect is to make sure your team is working on the most important things. But the second order effect is to ensure your team is applying the goal to the thousand invisible decisions that will happen in the course of their work. Put the one line goal at the top of every doc.

Focus. People think focus is about the thing you’re focused on. But it’s actually about putting aside the big shiny, exciting things you could be working on. The foundation of focus is being clear upfront about what matters—but the hard work is saying no along the way to the things that feel like they might matter. We launched Payment Links in less than 6 months because we cut so many features that felt ‘obvious’—QR codes, editable links, analytics, social media share cards, support for platforms, and so on. We added these things later but none of them would change the immediate trajectory: Payment Links was the fastest growing Stripe launch ever.

Changing strategy feels like progress but it usually isn’t. It’s fun to talk about strategy. It feels like you’re having a huge impact when some new insight changes everything. And changing strategy feels like an easy lever to pull when things aren’t moving fast enough or you’re bored. But, most of the time, it’s a chaotic waste of time for the team and delays real progress. Spend the extra time upfront to get the strategy right. Set the right metrics to understand whether you’re making progress. And then iterate on the tactics constantly.

Visualize the outcome. Find the right levers. Often, changing your frame will let you find a solution that solves a much larger problem or eliminates the problem altogether. At Stripe, there was a point where we were falling behind on recruiting. The conversation kept coming back to how to speed up the process, specifically how we could close individual candidates faster. Then Michael (who has great posts on setting good goals, planning processes, and the role of a product manager) graphed our target number of hires against our current pace. It looked something like this:

It was immediately obvious that while the other things could be improved, we were focused on the wrong lever. We needed more recruiters or we needed to change the goal.

Raise the bar.

Turn up the heat in every interaction and ask uncomfortable questions. Some of the questions I repeatedly ask:

Can we re-frame this in terms of the customer’s problem?
What’s the soonest we could get this done?
What would you need to get this done tomorrow instead of next week?
What would we need to do to get twice as many customers? Ten times as many customers?
How does this relate to our goal? Is this the most important thing we can do for our goal?
What’s most important? What do we really need to get right?
What could we cut, even if it’s painful?

Unblock psychological barriers. When something isn’t getting done, it’s because the person a) doesn’t have the time b) doesn’t have the skill or c) has some sort of psychological block. The third case is surprisingly common. After a few slips with someone I trusted, I’d just ask directly. “I noticed this work isn’t being pushed forward at the rate I expected or at the quality you normally deliver—what’s holding you back?” which would open up a conversation.

Creating psychological safety. Whenever you really push ambitions, there’s going to be some stress in the environment. That’s good. What you don’t want to happen is unsustainable stress, or for people to not share failure or tell you when you’re wrong. So you need to actively fight this as the leader by: a) asking for dissent (“does everyone agree this is the right path? Does anyone disagree”? and letting a silence hang until someone speaks) b) reward debate. If someone dissents, have the live conversation in front of others. If you still want to stay on the same path, openly discuss why you’ve made your decision and thank the person for their view. If you’re not changing your path sometimes, you’re either not listening, not creating safety, or aren’t hiring great people.

Start with a small team, especially when navigating product market fit. Larger teams create communication overhead. But more importantly they force definition = you have to divide up the work and make it clear who is responsible for what. You’re writing out project plans and architecture diagrams before you even should know what you’re building. So start small and keep it loose until you have increased clarity and are bursting at the seams with work.

Consistency is hard to argue against – consistency reinforces brand and creates better ease of use – but the costs are massive. Consistency just feels good to our system centric product/engineering/design brains. But it creates a huge coordination cost and prohibits local experimentation – everything has to be run against a single standard that multiplies in communication complexity as the organization gets larger. I’d try to ask “if we aim for consistency here, what are the costs, and is it worth it?” I think a more successful way to launch new products is to ignore consistency, and add it back in later once the project is successful. It will be painful, but less painful than risking success.

At a high level, there seem to be two ways to operate large systems.

Micro-manage everything. The micro-managed company tends to have everything flow through consistent choke points: you’ll have single functional heads (design, marketing, and so on) responsible for reviewing everything company wide – Apple and Airbnb function this way. This is the best way to ensure high quality, but it is hard to scale and is very wasteful (you’ll have layers of review that constantly reverse earlier decisions – and you’ll have to wait weeks for those reviews to happen!)
Build trust systems. The other way is to create systems that create trust and distributed ownership – generally organized under some sort of “business lead” that multiple functions report to. It’s easier to scale. You’ll move much more quickly. A higher level of ownership will create better job satisfaction. But you won’t have a consistent level of quality by function, and you’ll need to hire larger numbers of good people.

Replace yourself. This is common advice but it’s rarely followed. I’d watch an incredible person doing the job of three people, suffering through it. They’d argue for more headcount and not get it. And then they’d be replaced by ten people. Why? Sometimes a new leader has more credibility (“well, you hired me to do this job well, and to do that I need ten people”). But often the person doing the job couldn’t let their ego get out of the way – they thought they had to keep doing it the way they were doing to prove something. They need to actually change the nature of the role.

Elevate each cross-functional partner you work with. If you have a better data scientist, you’ll have a better marketer. If you have a better marketer, you’ll have a better finance person. Expectations elevate expectations. And reputations reverberate – both internally and externally. To elevate other partners, you have to both absolutely respect their craft and be willing to jump in and act like an owner for their outcome. Never take credit. Never point fingers. But get on that late night Zoom, reframe the problem, and go line by line to make it work. And then tell them to hit send to that senior leader. If done well, you get individually better output, but you leave behind a great deal of trust and the next project will be better.

Give good feedback (and ask for it, explicitly). A lot has been said elsewhere so I’ll go with: do it frequently and immediately, from a place of care, as a set of things you have observed, explaining the impact.

Useful meetings

Progress reviews. I’d run these ~weekly when I was functionally responsible for something. You can vary these between daily (for a crisis) and every two weeks, but the longer the time framework the more slack you allow in the system. The agenda would look something like:

Metric check-in. Single goal at the top of the meeting doc.
Run through workstreams. Kept in a spreadsheet with clearly defined state, single DRI, next steps, any blockers.
Deep dive on a few of these topics. For example, if we were getting consistent customer feedback we’d use this cross-functional forum to diagnosis and assign next steps.

Effort reviews. A wider step back that bridges progress. Agenda:

Metrics review.
Top initiatives.
OKRs—include status (e.g. on track, at risk, not started), blockers.
Top open questions.

Strategy reviews. Less frequent, only when needed. Resetting or tweaking target customer profile, product direction, metrics.

Shaping reviews. Review the problem, target customer, scope, outline of a solution, expected timeline, dependencies, key metrics (with plausible targets). Useful to do early to align on product direction and ensure alignment with overall strategy.

Product reviews. Pre-ship, close to done. Could be combined with a launch review depending on scope. This is a holistic look at the product before it’s shipped.

Debug meetings. Topic specific when a big thorny issue comes up, or there’s conflict between two teams. Someone writes a one-pager. If there’s disagreement, both sides write one.

Thanks to Lauren, Dan, Jess, Jeff, and Emma for reading drafts of this post, and double thanks to everyone I learned from at Stripe.

Sam Gerstenzang is a Partner at Boulton & Watt. He previously ran Payment UIs for Stripe, among other things. He can be found on Twitter and Substack.

Comments

Thanks for reading Every!

Already a subscriber? Login