Stripe++

After ~4 years, I wrapped up my time at Stripe just before this year’s BFCM.

And, this year, Stripe again surpassed its previous year’s payment volume and maintained the rock solid stability and reliability it has been known for over the last few years. Easily, my time at Stripe was one of the best and fun times of my career, having gotten the opportunity to work on several things in Stripe’s Core Infrastructure, ranging from the service mesh to service discovery system to image management to resource management to cluster/cloud provisioning and cloud efficiency. And all these roles entailed interfacing with systems that spanned other parts of Infra like dataland, databases, security, deploy services, configuration management to name a few. At Stripe’s scale, pretty much anything we work on was similar to changing the tires of a car (or swapping out the engine at times) when you’re going at 100mph! Times like this is when you get to exercise your creative muscle as an engineer and I’m glad Stripe gave me the opportunity to hone and develop these skills.

Why I joined Stripe?

When I accepted an offer to join Stripe in late 2021, I wanted to join a relatively small company. I was coming from Salesforce, which grew 5x the time I was there. Salesforce was a 15k+ person company when I joined in 2017, from a 40 person startup. Even if Salesforce was a behemoth, my experience was quite pleasant, partially owing to the fact that I was working on teams that came through acquisitions - first on the authentication and identity space and later at Heroku. This also was aided by the fact that I had fantastic managers and a wonderful team to work with during this time. However, even if I was in relatively fast-moving parts of the company, I hit the unfavorable parts of staidness in such a company a non-trivial number of times. This was one of the main motivators for moving on from Salesforce.

Stripe was a company that I had been following for a while then, given their very public presence in the interwebs. The culture and the people attracted me initially and their attention to detail in their docs and engineering articles was another factor. Admittedly, it was a small shock for me when I joined since Stripe was much bigger than I anticipated. But, one thing that stood out during my interviews and also eventually when talking to the team members is the culture. Stripe heavily biases towards action and this was re-affirmed many times over during my 4 years. Even if the decision was suboptimal, Stripe optimizes for taking a stance and then course correcting in the event of a surprise.

To be entirely honest, I was on the good side of this for pretty much my entire time. Very rarely did any course corrections we needed to do rendered us paralyzed later on. Sure, there were hiccups but the culture in Core Infra meant we could pivot fast and help was available. It also helped that the leadership during my time was stable throughout in spite of a few reorgs/departures the first few months after I joined. Owing to this, getting buy-in from leadership got easier over time as we built trust!

Another reason why I joined Stripe was the general scale of problems that were at hand. Of course, I didn’t know much when I joined other than some initial projects that I was going to work on, I could predict the general shape of problems in the space of networking that Stripe was grappling with at the time. This is typical for any company that is growing and every order of magnitude brings its own set of challenges that will often require a complete rethink of the architecture.

Impact Driven Development

One of the OG Stripes had coined a term for how Stripe operated in its early days - Incident Driven Development. This isn’t just incorporating proper incident response management in your engineering practice but actively identifying issues in your system through incidents and prioritizing to fix these over several other competing priorities. The good side of this practice is it’s often plain and clear what is on fire and what you need to prioritize. The bad side is often times, remediations for incidents have a deadline and you will have to contend with something that is not necessarily perfect and kick the can down the road.

Stripe’s Infra had evolved largely in its nascent years in this model and this meant, there were several systems that were just a huff and puff away from being blown over. A critical piece of Stripe’s service discovery stack had been largely neglected and an incident at Roblox in 2021 was the wake-up call. I was lucky (or unlucky - however you want to put it) to have just joined Stripe when we had our fair share of incidents that were similar in shape and these taught me what was important to focus my attention on. And what came out of it was something that helped us overhaul our entire service discovery system for an in-house one. This formed the meat of my time at Stripe (almost 75%) and helped me grow my muscle as a good engineer. A resounding success led me to other projects subsequently in Core Infra which required some, albeit considerably smaller, firefighting as well.

While I learnt a ton from all these escapades, the major downside personally for me, which I ignored for many months was burnout! While it’s super fun to be firefighting something every 4-6 months and then move to focus on something else that needs your attention, this also drains you a lot! I wish I had realized this earlier and expressed what I wanted more clearly to leadership in retrospect.

Stripe, like many other companies hinges a lot on the potential impact that an engineer delivers and this is absolutely crucial when it comes to performance, promotions etc. And of course, as an engineer, you want to work on impactful projects that deliver some business value. And this is the main reason companies have some form of exec-level goal setting like vision/OKRs that ultimately trickle down to all parts of the company. The fact that I was firefighting meant that I was largely delivering impactful projects but in the last few months or so after a recent reorg, I felt the work became increasingly vague to determine impact! It wasn’t hard to determine impact, but every impact felt as though I was trying to fit a square peg into a round hole. From what I understood talking to other staff+ engineers at both Stripe and outside, this isn’t something that is uncommon. And when this happens, people generally try to manufacture impact by looking at obscure stats (you can almost always find some stat that corroborates your assumptions) and tie it back to some business metric. While this is something that can buy you out in the short-term or perhaps even medium-term, it will definitely come and bite you long-term.

This is typically where strategy comes into play. A successful staff+ engineer has enough time to form opinions about the infrastructure. They spend at least a few months in the trenches trying to understand what’s wrong to make an informed decision on where to focus next! The downside to firefighting and being moved around is that you don’t necessarily get to form these opinions or even if you do, you aren’t necessarily confident about them. This is something that was increasingly consuming me towards the end and wore me down eventually. Another benefit of time on the role is trust - what you build with the team, what you build with your management chain and more importantly, what you build with yourself. In retrospect, I did fairly well in the former but I do have some personal learnings around the latter two, especially in the face of re-orgs and reestablishing trust with a new management chain.

Lastly, one of the things I wished I did more at Stripe was learn more about the product. Sure, I know enough about the product to understand how it interacts with our infrastructure, but working in a relatively large company, especially in infra, means you’re fairly removed from the product. There’s definitely no dearth of information internally to learn about the product, but it comes at the expense of time not being spent on other important stuff that your team cares about. This is one of the main reasons I enjoyed working at Heroku where the infra is the product and it was a fun gig where I had a lot of insight into the business side of things having had the opportunity to work closely with solutions architects, support staff and the like. Over the past year, I was realizing that increasingly my responsibilities at Stripe were misaligned to what my personal goals were and not addressing them sooner was another source of burnout. In retrospect, I wish I had made a decision sooner since I wasn’t necessarily progressing much in the last few months.

Should you join Stripe?

This is more of an aside section - absolutely! I loved my time there, and I’m sure you’ll too.

As I alluded to early on, the average team at Stripe is probably the most talented and fun to work with, in my career. Another commendable thing is the overall transparency from leadership about everything that happens in the industry! For a company that is as big as Stripe, the founders are committed to doing a Fireside chat every week still is amazing. Granted, not necessarily every one can attend these in person owing to meeting conflicts, but the information is available to consume later on. Besides, any person at Stripe is just a slack message away from a quick coffee chat about what they’re working on.

Stripe is a big company now which means that things can be different in different parts of the company. There’s a very popular saying in the industry - People don’t quit jobs, they quit managers! and this is very true at Stripe too. As much as a lot of companies are opting to do common interviews across the board (Stripe including), you as a candidate should definitely ask to talk to someone on the the team once you’re close to an offer. Knowing who you are working with and reporting to will help you level-set your expecations and ensure you have a good time ahead.

Another important thing is the average engineer at Stripe, at least in Core Infra where I spent all my time is extremely collaborative. The typical attitude that I’ve seen people taking is to look at any situation as us v/s the problem as opposed to you v/s me. Again, isolated exceptions may or may not exist, but overall I enjoyed my time there!

What next?

If you’ve actually read this far - kudos to you!

I graduated from undergrad in 2009 and almost a week after my final project presentation, started working my first job. And since then it has been a snowball of sorts where I have hopped on from job to job, interspersed with 2 years of Masters as well. I hadn’t had the opportunity to sit and relax for a bit and I’m taking the next couple months to mentally recharge and take a break. I thought hard about mentioning this here because there’s a bad rap around admitting to taking a break in the industry! You see people taking short breaks in any and every industry out there but somehow in tech, there’s still some sort of a taboo associated with it. And I decided to put this in here in the hope that it resonates with a few of us out there. Every person has their own notion of what a break looks like. And the most important thing to acknowledge is what you do in your break doesn’t have to be anything similar to what someone else does.

At the end of the day, working on hard problems and working with people fulfills my purpose and working with other engineers and helping them solve their problems brings the best out of me. I’m also extremely fortunate to be consulting with a couple of friends at startups during my break to help them scale their infrastructure to support the next magnitude jump. Every time going into a meeting with them to design or fix issues with them has been energizing in the last few weeks. And I hope to continue to do that for a while. I’ll also be volunteering for my grassroots alumni association and a friend who works on Genomics research.

I’ve also been upleveling my toolchain during this time by using and trying a bunch of coding agents and tools. This has been truly transformative and I’m glad I took the break to explore.

As the new year rolls in, I also want to write more and hopefully kickstart a small YouTube channel where I discuss and learn tech by teaching. As much as everyone knows how the world is being transformed with AI, there’s a lot of stuff that goes underneath that keeps all the GPUs whirring. I last touched CUDA and MPI about 12 years ago when I worked on my Master’s Thesis and I’ve been chipping away at learning how to build infra in the world of non-deterministic execution. Admittedly, this is vague and unclear at the moment and I can’t realistically learn everything in a month or two, but I at least where how to start.

There’s also a long laundry list of projects that I want to work on - both in the physical world around the house and on my computer to ease some parts of our lives that need constant TLC. Hopefully, I want to use this opportunity to dust up some of my skills in that esoteric programming language that I learnt a while back! And yes, after many years, I solved some AoC in December in the first 24 hours of problems being released.

Of course, I do want to make some head start into 2026’ reading. I’ve been like many where I’ve committed to reading X amount of books every year only to have that commitment wane off mostly owing to my own lack of prioritization. I do want to spend some time figuring this out and hopefully I can write some more about this in the near future.

One of the most important things I did this year was to restart my music practice with someone I hugely respect and adore - my guru, Sri Sriram Parthasarathy. Sitting every night after the house has gone to sleep and singing for a few minutes, wrestling to get that specific phrase right, is truly an exercise in humility. I do hope to build a habit around this that I can sustain going into 2026 and beyond.

So, yeah, I maybe taking a break but I’m still going to be having a lot of fun! :)