Reflecting on my IC path, Part III

A little over two years into my Uber ride, I moved downstairs¹¹ Stripe subleased a floor from Uber in the early days of its Seattle office. Interestingly, that was the same floor where my Uber ride began. It was not until another year later when Stripe moved to its current office in Seattle. to join Stripe in January 2018. There I got to work with some of the most rigorous thinkers I have met, and embraced the largest shift in my professional career. In the third post, I share my learnings in reaching the next stage, and describe my considerations in making the engineering management transition.

It all began with Bratwürste and Bier

It was the Saturday night before MLK Day 2018 in a German bar in downtown Seattle. There I was celebrating the new year with my new colleagues. Holding a glass of beer, a tipsy Anders Conbere, who would be my manager over the course of the next year, shouted to me under the influence, “Yuan! We are going to migrate to ephemeral servers, and you are going to help us do that!”

Anders was referring to a huge undertaking that would obsess me for the next two and half years. We were on a mission to migrate our EC2 fleet from long-lived antique hosts to short-lived ephemeral servers.

This quest, by all means, was nothing new. It had been completed by many other companies. Mesos and Kubernetes are two popular technologies among many for this purpose. It had also been done at Stripe. Our very own Paul Carleton talked about Lifespan Management at LISA18.

My team still faced a unique challenge though. We operated Stripe’s cardholder data environment. The infrastructure there needed a make-over before we could even consider short-lived servers. Among other things, we had to find ways to:

• Automatically provision new EC2 instances,
• Deploy software to said instances in a way that does not involve copying files from laptops, and do it in a secure fashion,
• Perform server and service discovery,
• Implement graceful termination to decommission old instances safely and regularly,
• Support stateful services and databases.

I did not drink since I was driving, but I was no less excited about the challenge.

Becoming a force multiplier

It was not obvious whether I would qualify to lead the effort, and even that was a polite overstatement. I never used AWS prior to Stripe; I had never worked on infrastructure before; I also lacked the crucial multi-year context on the system’s evolution.

I had many chats with Anders, Brian Delahunty(Anders’s manager), Bryan Berg(my tech lead), and Will Larson(Brian’s manager) on how I could be effective in my role. One theme emerged from those conversations. The mission was so enormous that it was beyond the limits of myself or even my team. The only way for me to succeed was to become a force multiplier, and here is a list of things that got me there:

• I manually provisioned about 100 hosts and replaced old ones, one-by-one, in an effort to stop the bleeding. That ramped me up on our existing tech stack, and gave me useful context around the business domain.
• I spoke to many engineers around the company, particularly those in the infrastructure group, to find ways to leverage existing technology and/or to brainstorm new ideas.
• I authored a roadmap memo outlining the series of problems, presented multiple solutions to each, and proposed an opinionated least-resistance path forward. Most, if not all, of the solutions were ideas from other brilliant people.
• I socialized the proposal around the organization, and mentored engineers from new-grads to seniors to pick up and solve those problems.

As we made steady progress towards the outlined target, it became increasingly difficult for me to pinpoint any specific artifact that I personally created. Nevertheless, I was quite certain that I brought some value to the table. I did my best to ensure every stakeholder felt their voice got heard; I worked with engineers with strong opinions to agree to disagree²² In one specific case, Person A pitched a revolutionary Option X with sound arguments. Person B was super uncomfortable and proposed a more modest Option Y instead. We went with Option Y by following the least-resistance rule, but I told Person A that I thought Person B would eventually change their mind once we scaled the system and had more operational experience. A year and a half later, Person B did exactly that, which overjoyed me.; and I was constantly nudging for forward progress.

The value I brought was force multiplication.

Multiplying my impact

One year after joining Stripe, I made the formal request to transition into engineering management, an idea that had been unthinkable³³ See Part I on my naive understanding of leveling up on the individual contributor path. for me a few years before. Brian and Will interviewed me for the new role, where they asked me the same question: Why?

I had a breadth-first career. I moved up and down the stack all the time, from Windows Desktop apps, to React Web apps; from writing data pipelines, to creating streaming platforms; from customer-facing interfaces, to low-level infrastructures. I also put on multiple amateur hats, from software engineering to product management; from user experience to customer support. I had come to realize that I cared more about creating value, and less about the specific technologies I used or the particular roles I played.

In trying the management path, I thought, there was nothing for me to lose but a huge potential upside. In the worst case, I would be unfit for the role and go back to being an individual contributor again. From that failure though, I would learn the perspectives of an engineering manager, which would be super valuable for me to collaborate with my future managers. In the best case, I would find a good fit and devote 100% of my time to multiplying my impact.

That was a pretty good deal.