Two weeks ago, on July 15th, I started work at a company called Stripe. Two days ago, I quit.

Wherefore art thou Stripe?

For those who haven’t heard of it, Stripe is a small payments company geared at making it super easy for developers and online merchants to start accepting money. Stripe tries to take away all the pain points from the process—it deals with the nasty business of handling customers’ credit card data, it talks to all the banks and card companies, and it hides all the setup unpleasantries. It helps protect developers from fraud and makes managing payments as low-maintenance as possible.

This kind of product is my favorite kind—one that takes an existing service and reimagines it in an obviously better way. Stripe seems to be to online payments what Uber is to the cab industry; what Square is to in-person, credit-card-present payments; or what Nest is to, uh… thermostats. Startups that develop these sorts of revamps make up almost all of the very small small set of startups I think are worthwhile at all, and which I would be terribly proud to have conceived of myself.

So, to be honest, I’m not especially passionate about payments myself—but I am passionate about these sorts of the-right-way-to-do-things products. And I did love the prospect of working on Stripe’s tech stack based on what I’d heard from friends and from visits, and most importantly, I wanted the chance to work closely with Stripe’s very smart systems engineers whom I’d met on a number of occasions. I thought there was a ton I could learn from them by working with them in a close environment, and plus, having only been at Facebook before, I thought a startup was worth trying out.

What’s in a name?

As it turns out, there may have been a faulty assumption somewhere in that last bit.

What does it mean to be a startup? To some extent, that’s the question this story comes down to. Or, more precisely— What does the label of “startup” entail for me?

For me, the great joy and allure of the startup is the opportunity to get involved in all the things. It’s not to manage or to direct or to lead—it’s to be a participant in all areas of development that you want to contribute to (and sometimes, I’m sure, as a necessary cost of this opportunity, also those you don’t). It’s the ability to share in all the team’s successes and failures and the freedom to sow your productivity and efforts across a wider field than you might be able to in a larger-scale setting.

This is certainly manifested at Stripe. The trouble for me, though, was that in my two weeks there, I was just unable to apprehend what I could do to integrate myself into the company in that way—i.e., I just couldn’t tell how to become a full participant in Stripe’s startup discourse. To reify the issue, I also couldn’t discern how to find out how to apprehend such a trajectory for integration—i.e., I encountered an information discovery problem.

Scaling that dear perfection

I don’t believe that these difficulties I faced are really specific to Stripe. To me, they seem like the inevitable growing pains that come with having to scale both startup values and an onboarding process in parallel. After reaching a certain (fairly small, I would now guess) number of people, these two elements of company infrastructure seem almost inherently at odds with one another.

This blog post has a thesis in addition to a story, and this is it:

There is a tradeoff between (1) maintaining and reaping the benefits of startup values and (2) scaling the onboarding process.

Let’s consider Facebook. It’s easy, for example, to imagine how Facebook’s motto of “Move fast, break things” might have made onboarding tricky as they started growing. When you start off as a developer somewhere, especially if the people around you have built up lots of systems and infrastructure (e.g., by moving very fast), it’s hard to move nearly as fast yourself right off the bat. You can probably break things super quickly, but I’m pretty sure the motto refers not to wanton devestation of the codebase, but rather to boldness and frequent risk-taking— and at the beginning, it can be even harder to know where risks should be taken than it is to move fast.

Basically, I think that effectively onboarding new people can mean having to backpedal a bit on core values. When optimizing for speed as many startups do, someone is going to have to slow down during ramp-up—either some of the existing participants or the newcomer. Someone will need to be taking fewer risks so they can spend more time teaching the new guy how to pick risks to take.

For Facebook, it definitely seems like this scaling problem became easier with time. Once Facebook got to the point where it was onboarding small groups of engineers rather than growing person-by-person, and was doing so at a regular rate, there were probably Facebookers existing at points all along a continuous range of fast-movingness and integratedness—this is certainly the case now. This sort of environment makes it much, much easier for a newcomer to figure out how to wholly integrate, because there are more data points to base a projection for the future on. At this higher pace of growth, you also have the means to build better infrastructure for onboarding, which Facebook has in its successful Bootcamp program for all new hires. Having others who are bootstrapping along side of you also seems beneficial. These are luxuries that companies just beginning to scale have to live without—and that life can be difficult and painful.

This isn’t a huge revelation—obviously it’s easier to grow by n people if you have N people than if you have M people and N >> M. No need to thank me for the lesson here in fractions; you’re welcome.

Anyway, Facebook is definitely not a startup anymore, but I think it has scaled up its particular core value with substantial grace. Not everyone is moving super fast and breaking super things, but it is clear how to climb the hill of fastness and risk-takingness starting right in your first few days. But I’d bet there was a point long ago, before the scale at which Bootcamp became tenable, where scaling “Move fast, break things” and managing onboarding concurrently became very difficult.

To smell as sweet

At Stripe, my integration concerns involved not speed-of-development, but rather speed-of-information-gain. If I had to name Stripe’s core startup value that it strives most to preserve—its analogue of Facebook’s MFBT—it would be this: high information accessibility. One of their blog posts describes, as an example, their highly-transparent internal email communications. For Stripes, this is a high-bandwidth firehose of information that can be switched on and off as needed, and which lets everyone stay fully up-to-date on all the issues they care about and want to contribute to. It’s a pretty cool feature to support, and it helps maintain the “build ALL the things!” joy of startups.

As a newcomer, though, it is daunting. It is daunting because without the proper context, it’s impossible to interpret these channels effectively, and instead you get a bit lost in the storm of bytes. As a friend of mine analogized, it’s like being handed a flurry of entries from a foreign encyclopedia—the meaning is there, but you can’t access it. You just try to recognize the cognates and pattern-match with what you know. The bytes are opt-in, of course, but not getting enough bytes means that you may miss updates you do understand regarding parts of the company and the product that you really want to dig your hands into.

Having a core value of moving fast means that onboarding will slow someone down a bunch. Likewise, I think, valuing high accessibility of information, which facilitates up-to-date data consistency across the company, means that, during onboarding, someone will have to expend comparatively extraordinary effort to facilitate information exchange.

Email was not really the most pertinent manifestation of this tradeoff for me. The information channels I most needed were those pertaining to what I could do—I wanted to start coding and building the things. However, it was very hard for me to discover tasks on my own; others had the information needed to sort out what needed done, and I didn’t. It took lots of poking to make sure I had something in my pipeline to work on. Maybe more importantly, this same lack of information made it hard to assemble a bigger picture of how I could be productive at Stripe while frobbing all the bits I thought were shiny and which I could be of good use in twiddling. It was even hard to find these desired bits because I couldn’t find the discovery mechanisms.

But this is a bit of an Ouroboros—without the context needed to see this bigger picture, or a substantial external force relating such context, it was hard to be productive in a self-driven or self-aware way. Doing the work didn’t make it much clearer what doing work in the future would be like or quite where the work was meant to take things, and this in turn kept such context out of reach.

Basically, I was a new Paxos acceptor at Stripe and I needed a copy of the log, but I wasn’t sure where to get it—and maybe also the log updates were written in another language, say Pisidian, and the Pisidian-to-English dictionary was also itself a log entry, and moreover I wasn’t entirely sure whether Pisidian was a language or maybe a fish.

Thou art thyself…

So, I promised a story way up in the subtitle, but so far I’ve mostly been waxing philosophical about the difficulty of onboarding while trying to keep startup values at-scale. It is difficult—for the newcomer, in my experience, and also I think for the company; and I’d expect this is the case for more companies than just Stripe, and in more cases than just mine.

When you order a startup, you’re also served some unavoidable FUD—a storied term I learned at Stripe, repurposed to refer to the unknowns about your work. When you join a startup as it begins to scale, you start with this other FUD about your own integration into the company instead—you get FUD about when you’ll be able to have the first FUD, which is the FUD you actually meant to order. But the second FUD is probably not so bad in general. Why, then, did I leave Stripe so soon, before finishing my meal?

There were a bunch of other confounding factors. One was that, as it turned out, I just did not like San Francisco, or at least the areas in which I was working and living (or at least sheltering in, since I was still staying in a hotel Stripe offered me as I apartment-hunted). The Mission was a far cry from the South Bay area which I’d quickly grown to love in my previous internships at Facebook. SF on the whole seemed very disjointed to me. The feeling of suddenly being in a totally different area after only a few blocks is unnerving—and some of these parts are strangely empty, even though neighboring areas are dense.

The Stripes I was working with tended to keep late hours, which for me made communicating with my friends on the East Coast a challenge. The office was also less lively than I’d like. I’m used to having a lot of commotion when I work, and those settings full of hubbub are the ones I’m most productive in. As someone accustomed to wider environments and easier mobility to places I wanted to be (which in this case just happened mostly to be situated a couple thousand miles away), being where I was made me feel trapped there.

…though not a Stripe

Some of these pain points, in retrospect, I might have anticipated—but others were unforeseeable. My entire spin-up process at Stripe was beset by a smattering of misfortunes. I think my onboarding concerns and my troubles with information discovery are shared by some of the other newcomers, too, but these other bad experiences were just strokes of particularly awful luck. When bootstrapping engineers, for instance, Stripe always sets the goal of shipping code on Day 1—however, I didn’t end up touching any code until the afternoon of my third day there, and I didn’t feel like I had a true task to work on until Thursday evening, though not for lack of pinging and poking. Neither those that came before me nor those that came after have encountered this Heisenbug, so I’m pretty sure it’s not really a thing in general.

Nonetheless, it still left me feeling unproductive and underutilized from the beginning. Some belated onboardings were added my second week so that I could make up time working more closely with other engineers that I had lost. But both of these had the unfortunate property of starting some three to five hours later than scheduled.

I felt like there was a huge disconnect between the context and information that I had available and the information I wanted to obtain—which others seemed to enjoy immeasurably more of. And the issue was that I didn’t have enough information to see how big the gap was, nor how I could possibly ever be able to make the jump given the pace I was at. I’d fallen on an extreme end of the tradeoff; Stripe’s core value of information accessibility was completely lost on me, and I just couldn’t project how it might someday be a joy and a benefit that I, too, could reap.

Sometimes you just need to climb a hill. When you join a startup, the environment may not be as continuous—it’s more of a cliff, and you need to find your own way to scale it, and you might not have any equipment, and so you’ve gotta search. And sometimes you spend a week walking along the sand in one direction, and then you start over and spend a week walking the other way, and the cliff is just as tall as ever in every direction, and you feel like maybe you’ve got too much FUD to start with and what you really need is actually FLUDD, so you do what your gut tells you it’s time to do.

You look for your princess in another castle.

That which we call a startup

Is Stripe still a startup? I know parts of this post must imply that question. I think the answer is, “Yes”, and I just happened to miss all the magic startup dust, and maybe got left behind in some regular dust instead. I didn’t leave because Stripe was awful—I left because circumstance (some of it, to be fair, Stripe-derived) had pushed me all the way to one side of the values-scaling/onboarding tradeoff, and navigating from such a foggy corner didn’t seem like the problem I ought to spend my time solving.

Stripe offers a cool product which I expect to succeed, and so as a corollary, I expect it to succeed in negotiating this tradeoff as well. I’m curious to see what they come up with to solve this human scaling problem alongside their more technical ones.

Just not quite curious enough to wait it out myself.