An interview with Claire Hughes Johnson

Claire Hughes Johnson (@chughesjohnson) is the Chief Operating Officer of Stripe and a board member at Hallmark Cards. Previously, she was a Vice President and Director of Online Sales and Operations at Google, where she led operations for that company’s self-driving-car initiative. Johnson holds a bachelor’s degree in English literature from Brown University and master’s degree in strategy and marketing from Yale School of Management.

When Claire Hughes Johnson joined Stripe as COO in 2014, the company had 165 employees. Now that number has grown to over 1,000. Along the way, the payment-processing startup has entered into partnerships with giants like Amazon and launched next-generation products like Atlas, which guides internet companies through incorporation.

In our interview, we talk about how to manage your reports, how the org chart should be structured, and how to build functional processes that will help your company scale. We also address strategic planning and how founders should be allocating their time as the company grows.

Elad Gil: Urs Holzle, who was an early SVP at Google, literally wrote, “A Guide To Urs” about the interaction approaches that work best for him. So if you needed to interact with him or you wanted things from him, you knew what to do. And apparently that really helped streamline how people worked with him. Do you think every founder or exec should write such a guide, or is that only for specific instances?

Claire Hughes Johnson: I think it’s a best practice. When I came into Stripe, I had a similar document. I wrote a document back when I was at Google called, “Working with Claire.” And when I first got to Stripe, I adapted it slightly, but it was pretty relevant. I shared it with everyone who was working with me closely, but I made it an open document. It spread quite quickly through the organization. It made sense, because I was new, I was in a leadership role, people wanted to understand me. And then people started asking, “Well, why don’t we have more of these?”

It’s been a little bit of a viral, organic adoption, and now a lot of people at Stripe have written their own guides to themselves. I’ve even had folks who are not managers but are on my team write me these guides to them. And it’s been super insightful. So I’m a huge fan.

“I think that founders should write a guide to working with them.”

– Claire Hughes Johnson

I think that founders should write a guide to working with them. It would be one of the pieces I’m describing, to clarify the founder’s role: “What do I want to be involved in? When do I want to hear from you? What are my preferred communication modes? What makes me impatient? Don’t surprise me with X.” That’s super powerful. Because the problem is, people learn it in the moment, and by then it’s too late.

Elad: Another thing that I’ve seen a lot of companies do as they scale is implement more day-to-day processes. Because there’s a huge difference between running a 100-person company and a 1,000-person company, particularly if you have a large product and engineering org. Are there two or three things like that that you view as the most crucial processes as a company starts to grow, and that help free up executive time?

Claire: Yes. I would say that it’s a combination of what I would call “operating structures,” which are things like documenting your operating principles and processes. Operating structures are not tied to any one particular process, but instead explain, “This is what we expect of ourselves, in terms of how we work.” And when you document things like that, new leaders, new managers, new people in the organization can say, “Ah, this is what’s important. Let me adapt my behavior as we scale to follow along in this structure.”

And then you have things like launch processes or what-have-you. One thing I’ve observed is that you can’t make too many things at a company mandatory. You really have to be judicious about the things that you’re going to require, because there just can’t be that many. There’s probably something related to performance and feedback. There’s probably something related to whatever your planning process is. And then there’s a few day-today tactical things, like a launch review. But you can’t have that many and you can only have one at each level.

As you scale, you realize, “Huh, I really need more of these.” And the danger is getting too process-y instead of outlining the objectives so people understand, “Okay, we’re doing this for this reason.” It’s almost like you want to provide more context versus trying to exert more control. Because maybe in a very autocratic, hierarchical, bureaucratic structure you can exert control and you can micromanage. But most successful, high-growth, fast-moving companies are instead an environment of smart people who are all trying to optimize and do the right thing. They need some structural boundaries, but you can’t over-constrain them. And that’s why you want to have some high-level metrics that everyone’s steering toward, operating principles, a documentation of plans, and then a set of processes that you follow.

So for us, yes, if your launch is not on the product launch calendar, that means it’s not going to happen. You better get it on the calendar. And in order to get it on the calendar, you have to follow some steps. But you can only have a few of those.

“As your company grows, how you communicate information has to evolve, too.”

– Claire Hughes Johnson

As your company grows, how you communicate information has to evolve, too. Don’t forget as you build these structures and establish a few processes that you need to have new communication approaches. Because not everyone is in the room anymore. What does everyone have to read? Where is all the documentation? Where is the source of truth? How do you use your allhands meetings? How do you use emails from the leadership team? You have to think about all of that.

Elad: Yeah, that actually happened really early on at Color. We started asking that everybody send out meeting notes as part of every meeting, so there was transparency in terms of who attended, what was discussed, etc. And one early person pushed back. It was an example where literally a week into it he was saying, “Oh my god, you were right. We should have been doing this all along.” There was a lot of resistance and a perception that it was micromanagement or it was us trying to track everybody in a nefarious way. But it was really just trying to open up communication.

Claire: Right, and just saying, “This is about context and communication, not about control” is so important. You literally have to state the obvious and make sure people know that.

Elad: How do you think the org structure maps to decision-making?

Claire: That’s a great question. For starters, I think that there’s no such thing as an optimal org structure. If you’re searching for one, yeah, good luck. There are certain sets of things that can be very functionally related to certain org leaders, so you can use org structure as a decision-making proxy to a point. But you really have to be careful that people don’t make false assumptions about who is responsible for a given decision.

At Stripe, for example, we make a lot of decisions jointly as a group. You’re just not going to find one person you can go to, which I think can be frustrating internally. But in fact, if you believe in the wisdom of crowds or the fact that a smart group of people is going to make a better decision than one person alone, it’s a good thing. But that means you have to set expectations within the organization that they’re going to have to take the time to make sure that smart group of people is informed.

My answer would be that you can map decision-making to org structure to a point. Then it goes back to being explicit about how certain types of decisions are going to be made. “Hey, if we’re making a major pricing change, everyone on the leadership team needs to agree.” Be transparent to the org about whose role and responsibility it is to make those calls.

Otherwise, it just starts defaulting to the founder, which is not healthy for scale. I do know some executive teams who write up “roles and responsibilities” docs that they share internally. One part of those documents could be clarifying the things for which each person is the primary decision-maker. And if they’re not the primary decision-maker, where do you go? That helps organizations know how to adapt as things scale.

Elad: What decisions do you think should not be made by a group? There are a variety of different models; some orgs are very consensus driven, and some are almost dictatorial depending on who’s in charge. Are there specific things that you think should always just be owned by an individual? Or do you think it really depends on the context? What should the CEO not delegate, in other words?

Claire: I would say that there’s a difference between a CEO or founder facilitating a group discussion to get opinions from people and making a group decision. And they might need to say, “Okay, ultimately, I’m the one who’s going to make this decision.”

Sometimes that gets confused, though, because the group thinks they’re the decision-maker and that the goal is consensus. When really the goal is, “Let’s hash it out together. We may not all agree. One person will be the decision- maker, and then we will all commit to it.” If you don’t clarify what kind of decision this is, then groups really struggle because their expectations are not set correctly.

When I’m leading through a tough decision, I try to say, at the outset, “I want all of your opinions, but I’m going to be the one who ultimately makes the decision.” Or in some cases, I will say, “I don’t know if I’m the right decision- maker. I need help exploring what the decision vectors are, and I need all of your help. And then I will let you know how we’re going to make the decision once we’ve talked about it.” If you don’t give people that guidance, which is I think a common mistake, you’re likely to run into trouble.

Ultimately, there will always be decisions that the CEO and the founder have to own, with a lot of input from the process and the system. Hiring a significant new leader for the company, for example.

One thing I’ve been talking a lot about with our engineering team is that usually your company’s plans and incentives and metrics structures aren’t built to stop things, or to stop and redo things. So if there is a need to pay down some technical debt or make a really hard call on stopping a project, you need a leadership voice, or even a CEO, to say, “Hey, we’re just not doing this anymore.” Because the org is always oriented toward making it work. I think decisions to stop or to retrench or to rebuild usually have to come from a leader if not a leadership team.

Elad: That makes a lot of sense. The one other failure mode that I’ve seen, which is in some sense maybe unexpected, is when a founder or CEO hires a more experienced senior exec—a COO or a CFO, for example—and they’re so impressed by that individual’s expertise that they effectively abdicate. They step back from the things that they’re really good at or the decisions that they’re actually uniquely geared for.

Claire: And that’s not a great signal to the org, because they think, “Wait, do they not care about some of these things anymore?” I think you’re absolutely right. That balancing is really important and it goes back to the beginning of this conversation, which was about having a clear understanding of who’s doing what and how you’re going to work together.

Elad: Do you have any thoughts or advice for founders who are navigating growing orgs and new demands for strategic planning?

Claire: It’s easy to say these things and it’s hard to take the time to do them. I would just recommend that people make the time to do these things, because it’s really valuable time. As a leadership team at Stripe, we spend a lot of time just with ourselves, talking about what we need to do and getting aligned.

And one last thing: Don’t get too comfortable. Because if you are succeeding in scaling, you’re not going to be able to use everything you came up with for the next phase. Getting your organization used to the fact that it’s an iterative process and that you’re a learning organism and actually celebrating that is much better than resisting. You can almost start viewing yourself as a failure if you have to change these things, and that’s not true. It means you’re succeeding and you need a new thing. Sometimes companies are afraid to reinvent for their next stage, and I really hope people know that it’s a very reasonable thing to do.

Elad: It’s interesting because on the employee side of that, getting re-orged every three to six months because the company is growing so quickly can feel very chaotic and uncertain.

Claire: That’s exactly right. So how do you manage expectations and actually celebrate some of what is chaotic about what you’re going through? That’s my advice: figure out a way to get ahead of that and get people ready for inevitable changes so that you don’t have fears or concerns that are unfounded.

Elad: There’s a lot of confusion around how to approach strategic planning and decision-making as startups scale. What are the different levels at which companies should be planning? How do these different levels come together, and how frequently should a company do them?

Claire: I think this is definitely an area that needs to evolve as companies evolve and as they scale. If you’re pre-product/market fit, you probably need a different cadence, one that’s a little bit more agile as you’re finding traction. It might focus more on the short term: “Okay, here are some milestones we need to get through in order to start testing and proving that we can have product/market fit.”

Whereas once you have traction with some core product, you should fairly quickly be able to get to key targets or metrics that matter as indicators of progress. You should be able to say, “Here are our short-, medium-, and long-term goals to really build this out.” Because usually once you initially get traction you still have a lot of work to do to take advantage of it and to expand on it.

There is a balance between focusing too much on either the short term or the long term. The key to me is having two documents. The first—at Stripe, we’re calling them charters—articulates the long-term view of why this team or this product or this company exists, what its overarching strategy is, and what success would look like over even a three-to-five year period. And then the second is a shorter-term plan: “Okay, in the near term, then, what are we trying to get done?” That can look like a results- based management model or an OKR—objectives and key results— model. But it’s some way that a team can say, “This is where we’re going long term. And on a quarterly basis, this is where we’re focusing. We’re hoping to move X and Y metrics.”

If you’re working on an early-stage product, even within a company that has a more mature product, that shorter-term plan looks different. You probably don’t know what X and Y metrics are yet. You’re still in the milestone mode. Any planning process needs to accommodate product life cycle, if you will. You want to establish buckets that the company understands to capture each of the product stages you have.

At every stage, though, you want to find a balance between that longterm charter (“Why do we exist?”) and the short-term plan (“What are we going to do?”).

Elad: How do you think about iterating on each of those? For example, should the long-term charter be refreshed annually? Semi-annually? What’s the cadence for that document versus the cadence for your goal-setting or OKR document?

Claire: I think a charter needs a re-look roughly annually. And the goal-setting and OKRs is probably more like quarterly or bi-annually, depending on what kind of product you have. One thing that we do annually now—in addition to the charters—is set company metric targets for the coming year. We’re adjusting the plans against those targets every quarter too.

Elad: How far ahead do you think your charter or strategic plan should go?

Claire: One thing that I have really thought about is the set of what I’m going to call “founding documents” that are really important for any company to have, especially as you get beyond, say, 50 or 100 people. That includes your mission statement and your vision, but also your overarching longterm goals. When we wrote that document for Stripe, I thought of as it the three-to-five-year plan. But we just called it long-term goals publicly in the company. And if you read those goals again today—and I worked on them, the leadership team worked on them, three years ago—they’re still the same. And I don’t think they’re actually going to change even in three to five years. They’re our long-term goals.

Then the other thing you have is your operating principles or your values or whatever vocabulary you choose. You need to codify a set of principles and behaviors and then cohere to them, culturally. And those founding documents shouldn’t change very often. We refresh those operating principles every year, but they don’t change that meaningfully. I don’t think founding documents should change frequently.

“You need to codify a set of principles and behaviors and then cohere to them, culturally.”

– Claire Hughes Johnson

When it comes to a given product or area of the business, then the longest you’re probably going to project out is three years. Because things are changing so rapidly when you’re at a growth stage that you can’t really go much past that. We have a finance plan where we try to look three years out so we can test some of our assumptions. But we’d be pretty hard-pressed to make that meaningful in a five-year period.

Elad: Who do you think should own generation and implementation of charters and OKRs? When I was at Twitter, for example, I was asked to help implement OKRs across the company, and at the time the company was 500 people. So it needed Dick Costolo, who was CEO at the time, to pound the table for us. Because, at that scale, unless you have the leader of the company reminding everybody, things like that just aren’t going to happen. It was so late in the evolution of the company.

At what scale people should adopt these different processes? And then who do you think should own them on an ongoing basis?

Claire: I think adopting some planning framework early will serve a company well. I was giving a talk recently at a startup, and they asked what operating processes I thought should be in place when. I told them that I’m not going to tell you which operating processes you should put in place. But I will tell you that you need them, and you need them sooner than you realize.

The analogy I drew was to games, or sports. I said, “You know why playing a game is fun? Because it has rules, and you have a way to win. Picture a bunch of people showing up at some athletic field with random equipment and no rules. People are going to get hurt. You don’t know what you’re playing for, you don’t know how to win, you don’t know how to score, and you don’t know what the objectives are.”

Everyone was nodding along—and this is a 40-person startup—but I could tell that they’re struggling, because they don’t really have any core goals. They’re definitely in a product/market-fit, find-our-way mode, so I don’t think they should have anything too heavy. But organizations need constraints and objectives to optimize against, so that people can actually independently make decisions.

When I first came to Stripe, we didn’t have OKRs or even the charter or the planning process we have today. We had six company goals and that was it. And what we did in my first couple of quarters was just push the goals process down a little bit into teams. And that was pretty good for about 6–8 months. That helped us get people at least to know what different teams were up to. But earlier than you think, you need these structures, and you have to choose which ones make sense for you. Ultimately, our early approaches weren’t totally right—either for Stripe as a business or maybe we grew out of them—but we were building the muscle of stopping to plan and think ahead, of creating objectives and measuring progress, and that is the main thing you need: the organizational capability from an early stage.

And then in terms of who should own it, really leaders need to own it. This needs to be something that waterfalls and has accountability all the way down through the company. And I do think the leadership team, including the CEO, has to be quite involved. I don’t think they have to lead the process every time, but they have to be visible participants.

That’s my view: you need planning structures earlier than you think, and they should proceed all the way from the top down.

Elad: One challenge is if you have one or two people on the executive team who haven’t worked in large organizations before, sometimes you’ll end up with resistance in the executive team itself to adopting these processes. Then six months after they’ve been adopted, they’ll say, “These are great. I wish we’d always done these.” But it’s often quite painful early on.

On this topic more generally, where do you think founders should continue to be involved over time, and where do they often fail to delegate? I’m curious if you’ve seen common patterns across different companies. Are there things that people often need to let go? Or, alternatively, maybe things they shouldn’t let go, but where processes would allow them to distribute decision-making so the important stuff bubbles up to them?

Claire: I’m a big self-awareness advocate, and I would say there are two things you’ve really got to spend a good amount of time on as a founder or CEO and a leadership team. The first one is, what are things that only the founder/CEO can do and which are existential to the company? What must they spend time on? One of those is often recruiting additional leaders. Others would be, in most companies, articulating the product vision and setting cultural standards.

Figure out what those are, and figure it out quite transparently with the rest of the leadership team. Then do a big self-awareness exercise across that leadership team, in terms of skills, capabilities, past experience, strengths. See if you can deploy the group against your needs and objectives, and be really ruthless about what the CEO and founder has to be involved in. Part of that will be them weighing in on what they want to be involved in versus what they have to be involved in. And ideally, you want that documented, their preferences on how they’d like to be involved and their role description in terms of where they have to be involved.

Instead, though, this stuff often goes way too organically and becomes opportunistic. “Oh, we hired this person. They have this background so we’ll have them do this.” You’ve really got to think through it as a group and you’ve got to connect it to the company’s strategy and products.

 

This interview has been edited and condensed for clarity.