#define CTO

I joined Stripe as an engineer in 2010. I began by working on the backend infrastructure: designing the server architecture, creating our credit card vault, and producing internal abstractions to make people’s jobs easier. I loved writing code, but I also spent a bunch of time on other things: figuring out our recruiting program, shaping the culture, or making our first T-shirts (which have been banned since we hired our first designer). I wasn’t doing these things particularly because I preferred them to coding: instead, I had a very strong vision of the environment I wanted to be a part of, and I was willing to go out of my way to make it exist.

As time went on, I accumulated more and more responsibilities which were not strictly writing code. As Nelson Elhage liked to put it, my job became full-time “early employee”. My days were filled with writing cultural guides, acclimatizing new people, running our recruiting program, and the like. I’d often think it was time to give up on coding altogether, but I somehow always found a way back to it.

About a year and half ago, we officially declared me CTO. It was really just putting a word to what I was already doing — the most common reaction was “wait, I assumed Greg was CTO already”. This post is the story of what happened next: finding a partner to build our engineering team with, and figuring out my role as the organization changed.

Hiring a VP Engineering #

Around last summer, to keep up with the needs of our engineering team, I started doing 1:1s with everyone. I would stack them all on a Tuesday, and be completely burned out by the end of the day. By the time I was recharged and productive again, it’d be next Tuesday, and it’d be time to do it all over again.

Through this time, I knew I was faced with a choice: the technical route or the people route. I’ve never found anything I loved more than writing code, but at the same time I knew we had a responsibility as an organization to support the amazing people we’d hired. I was talking with one of my friends, the CTO at another company, who told me about how transformative hiring a VP Engineering had been for him. I’d heard of VPs Engineering before, but I’d never really considered that you could actively go and get one. So I resolved to find a VP Engineering, and convinced our CEO and others internally that this was a good idea.

Internally, no one wanted the role. We’d hired primarily great individual contributors, people who like me wanted to be building, and correspondingly hadn’t hired anyone who really wanted to be managing the entire group. So it was clear we were going to have to hire from the outside.

Over the prior year and half, I’d been meeting with a bunch of professional managers to ask them for advice. A very small number had really stuck out to me as the kind of people who, if they were ever available, I’d work with in a heartbeat. But timing never works out that way, so I prepared to spin up a recruiting firm.

And not to be too anticlimactic, but during that time one of those managers, Marc Hedlund, coincidentally became available. I talked to everyone on the team to talk about the idea of hiring a VP Engineering generally, and this candidate particularly, and then all 25 engineers sat down to talk about it as a group. We didn’t know exactly what the role would be, though we knew one thing it would entail: lots of 1:1s (primarily with engineers today, and primarily with managers as we scaled). So we figured that the best strategy was to focus on whether the candidate would be great at 1:1s, and then once he was here figure out the rest of the role together.

We then set up interviews with Marc: four days of back-to-back 1:1 or 1:2 meetings with everyone on the team from 10a-6p, as well as a talk to the whole company. I asked him several times whether this grueling back-to-back interviewing was actually ok: it seemed like the kind of thing that would require superhuman stamina. But he reassured me that yes, this was totally fine. And sure enough, he was great.

I also talked with a bunch of people who had worked with him previously, some of whom were references given to me by Marc and some of whom were backchannel. There were very clear themes in the feedback: “he’s been an amazing influence and mentor for me”, “I still keep in touch”, “I’d love to work with him again”. I very much wanted to be working with someone who others say that about.

Finally, just as important was figuring out how well Marc and I would work together personally. Between the two of us, we’d have responsibility for growing and shaping the engineering team, and we’d be in trouble if we weren’t acting in concert. We spent a bunch of time together, talking about some of the problems Stripe was facing, Marc’s view on management and leadership, and the like.

I asked him, “How would we resolve disagreements?” His answer: “Well, we’d talk about it, like we’re doing now. The ideal setup is one in which we trust each other to work to make engineering better, and if either one of us has significant concerns about an approach, we talk about it, and if those concerns remain then hold off on that solution.”

Later, when I asked him what he thought about the process, his answer was “you folks have clearly never hired a manager before”. He took on the task of designing our management interviews. Ironically, I’d had much the same reaction to my own interview process back in the day, which had motivated me to work on our engineering interview design.

Once we had a VP Engineering #

So we brought Marc in. In advance of his start, I added him to the email lists and added him on IM. We spent many hours talking over what was going on at the company, how to approach particular issues, reviewing email drafts for each other, and the like.

Once he started, I immediately transitioned all the 1:1s over to him. He also told me that I should feel free to send him any other stuff that I wanted off my plate (music to my ears given how overwhelmed I was at the time). Recruiting in particular was one that he suggested could make sense. I was actually kind of surprised: I’d never really known where recruiting fit, and had never really expected to be able to stop running our program. But it turns out that recruiting is typically part of the VP Engineering’s role. In fact, I slowly realized that the role I’d developed organically actually was almost entirely the usual VP Engineering role.

As time went on, one important shift was making sure people would take their problems to Marc rather me. The best thing I did on this front was take a vacation (my first ever) to Hawaii, and then holed myself up with a few engineers building CTF3. I also transitioned more and more responsibilities: because Marc was now talking to so many people, he was much better situated to know the problems any given group was facing, or how an organizational change was playing out.

The integration for any new executive is never smooth. There are false starts, and the rockiness of any change — in some places the culture needs to change to match the executive, and in others the executive needs to change to match the culture. I suffered from something I think a lot of engineers do, which is having trouble distinguishing “not the way I’d do it” from “bad”. Marc would run recruiting, or hold the team lead meetings, or communicate, in a very different way from me, and it took a while for me to really grok that everything was still ok.

The best advice I’ve gotten here is you have two traditional choices for how to delegate: you either delegate completely (and maybe you define some principles, but otherwise you have to leave the execution alone), or you stay involved in all the details. The latter model can work — think Mark Zuckerberg’s involvement in product — but you really only get to do it for one area. (There’s also a non-traditional approach, which is to train some people to be really good at simulating you, and have them run the delegated function. This may work but is not necessarily healthy.) But universally, “sparse micromanagement” (the best term I’ve heard for jumping in to some random issue, overturning all the decisions, and then disappearing) is the worst.

The way Marc and I worked through this was actually pretty simple: we spent way more time together. We started doing two hour-long 1:1s a week, one on Monday and one on Friday. There would be times when we wouldn’t have a ton to say, but it was incredibly important that we’d spend a bunch of time saying what we were worried about, what we were working on, where things are going. As a result, I went from having a bunch of issues where I didn’t know how Marc would react, to never being more than a few days from finding out, to eventually having a good enough mental simulator of him that I’d basically know how he’d respond. We employed a few other communication tricks, such as both getting IM on our phones or using the pattern of “I plan to do X thing; will time out and go for it in 24 hours barring objections”.

When you have a rapidly-growing company, you’ll find the organization itself constantly changing out from under you. As Marc learned to make changes in the organization, I found myself having to re-learn the same. We went from being an organization of close friends to being a post-Dunbar’s number company, where we had to figure out how to operate well even though some people have never even met. Having a partner in this (especially one who had run larger organizations) was incredibly valuable, and I don’t know how I would have made it through otherwise.

My role #

I’d expected that I would find myself suddenly with a role vacuum, and I’d get to fill it however I wanted. This was hugely appealing: since about a year in, my role had been almost entirely reacting to the problems of the day. This would be the first time I’d have a chance to define what I wanted to focus on.

I went on a bit of a CTO vision quest, asking about 20 different CTOs and VP Engineerings to describe their roles. I went in expecting every CTO to be chief architect. But I wanted to know how they pulled it off: I was trying to be chief architect in addition to “early employee”, and I had no idea how to do that job well part-time. (And most scarily, I felt our systems were being held back because everyone was assuming that I would be on top of the problems.)

But to my surprise, I found only one CTO for whom that was true. Everyone else viewed themselves as the facilitators of the technology organization. Sometimes this was about connecting senior engineers. Sometimes it was mentoring. One thought-provoking case for me was a CTO who was effectively head of product. I realized that there’s a huge difference between head of product and head of infrastructure: a good product is simple and digestible, so one tends to quickly distinguish bad from good. In contrast, you can tell good infrastructure only by building on it extensively. So it’s much more tractable to be part-time head of product than to be part-time chief architect.

I realized the most important thing to do was to empower our engineers to make big changes and improvements (plus, we’d been hiring some especially amazing engineers recently, and anything else would be kind of nonsensical). Marc and I set to work on enabling and encouraging major projects to improve the core of Stripe. I also started an “architecture working group”, a group of engineers available to help others build better systems, and a forum for figuring out where we’re taking our infrastructure.

However, one thing I hadn’t anticipated was suddenly losing my feedback loop. I had a snapshot of the organization from back before Marc joined, but I wasn’t getting any updated information. If I tried convincing someone that X was a problem, or Y was the right approach, all my anecdotes and evidence were from the before-time. It was like being a ship formerly tied to shore, but now adrift after someone cut the lines. And most worryingly, the problem was getting strictly worse with each passing day.

I spent a bunch of time thinking about how anyone can even know what’s going on in an organization, or what the problems of the day are. I came up with at most four possible mechanisms:

1. Doing the work: if you’re, say, writing code, you have direct experience with what’s good and what’s bad.
2. Talking to lots of people: you get an aggregate view and can tell what the sentiment is.
3. Observing the work: maybe you could try to be architect-y and read all the diffs. (I actually once spent a month doing this, but it felt like a waste of time — most of the work was reconstructing the author’s state of mind.)
4. Plan the work: you could try to plan everything out, though I’m actually not sure that this is sustainable without some other feedback loop.

I realized I was doing none of those. And looking at that list, I knew exactly which one would make me happiest. The question was how to get there.

I played with a variety of patterns for writing code. Many of them didn’t work: for example, “go off in a corner, come back with a prototype, and dump it onto an engineer to maintain (or just leave it unmaintained)”. I know there are CTOs who do this, but I’ve never found a variation that feels great (if you’ve seen this working, please let me know). An incrementally better version was “work with an engineer from a team, and build a new prototype together”. But this was also a bit of an uphill battle, since it required constantly fighting for people’s time.

I’d met another CTO at a dinner who told me he’d recently gotten back into coding. I met up with him asked him to reveal his secrets. How had he done it? He looked at me and said, “Coding’s the thing that I love. I knew I’d do a far better job at writing code than at anything else. I just needed to figure out how to get leverage out of it.” For him, that was improving both his company and the industry better by building an open-source platform for their infrastructure.

This was last month. I’ve started working on a team and writing code again. It’s not been easy: there are a million other things that come up. But the more time I’ve spent immersed in producing code, the better perspective I’ve had on the organization, and the better I’ve been able to support people, get them excited about what we’re building, and help them improve their work.

Sometimes I wonder whether I’m justified in making this choice — am I missing higher-leverage activities by focusing on code? But one of the best pearls of advice I’ve heard (from yet another CTO) is that it’s not about time management, it’s about energy management. It’s important to find activities that recharge you (independent of leverage) so that you have the energy to deal with the high-leverage draining stuff.

What my role will look like from here, I have yet to define fully. I’m too busy coding.