I’m Joining Stripe! — And Why I’m Going Back to An IC Role

Edit note: After 6 months at Stripe, I wrote a follow-up post Small Startup vs Big Company where I reflected over my experience so far.

In 2015, I was in a startup, Fundly, that was going through an acquisition process. In the last 6 months I was there, I was playing the team lead role: doing ad-hoc project management, incorporating new development processes (e.g. conducting early design conversations and code reviews) and doing informal 1x1s with my fellow engineers, all the while still coding. As the acquisition process came near to a close, I started to think about my next step in my career. I arrived at a fork in the road: I can either enter a new domain where I’d be challenged technically and continue deepening my engineering craft, or I can look for opportunities that can help launch me further into the management track.

Up until that point, I’ve always been a startup guy who had never worked at a company bigger than 60 people. (Technically the first company I worked at, O’ Grady Meyers, was bought by Meredith, a giant media conglomerate, a few months after I joined. Still, OGM never fully integrated into Meredith by the time I left so I still fondly look back at it as a startup experience). Because my network of friends were also mostly working in small startups themselves, I didn’t have as much exposure to different kinds of engineering (i.e. data, devops and infrastructure). I naively thought that application development was the only kind of work that really matters. While I definitely loved doing software engineering, I started feeling comfortable and plateauing as a full-stack application developer. Combined with my strong desires at the time to do my own startup in the future, I felt that career-wise it’d be best if I began focusing on leadership and management instead.

Thus, I joined Teespring because I saw a clear opportunity for me to eventually become a manager one day. Teespring ticked all the boxes that I was looking for: a “unicorn” company with well-known investors, huge hiring plans for its engineering org and an exciting startup environment that I knew I could make an impact in (I mean who doesn’t want to disrupt the t-shirt business?!). After 6 months of being a team lead, I was promoted to an EM role. The first 3 months as an EM were tough (I would come home exhausted every night because I was learning how to deal with spending most of my days talking to people instead of quietly coding), but every trying experience made me grow stronger as a leader. It was an amazing experience as I worked with some smart, driven people, and we built some amazing pieces of technology that solved interesting problems for our customers. My experience made me feel that as an EM I could make an even bigger impact for a business than if I was just an IC.

I decided to double down on the management track and joined Reflektive in 2016 because I felt I could get great mentorship to better my management and leadership skills. The head of engineering, Erick Tai, genuinely cared for his team, both on a personal and professional level, so I felt that I could learn a lot under his guidance. Additionally, I figured I’d learn all the best practices on being a manager since their HR software was all about helping companies foster a culture of constant feedback.

When I officially became a manager at Reflektive 18 months ago, I decided to focus 100% of my efforts in that role. That meant that I completely stopped coding and empowered the engineers with making all the technical decisions. I channeled my energy towards providing my team with as much business context and advocating on behalf of the engineers to the rest of the business. I looked for opportunities to grow my team, either through direct mentorship or finding projects that challenged them professionally. I partnered with fellow EMs and PMs to improve our development processes, ranging from contributing to the release process to facilitating the adoption of scrum to introducing a technical design document process to my team. Reflektive also had formal manager training, which helped me with how I construct and deliver feedback and conduct 1x1s.

By the end of 2018, I had groomed two team leads and delegated most of my day-to-day responsibilities to them. The two teams I oversaw were running smoothly with little intervention on my part, and many people in Reflektive said that’s a testament to the good work I’ve done as a leader. Additionally, because I contributed with Reflektive’s mini-pivot away from our primary 2018 strategy (a huge engineering cost with few winning conditions), there was even less challenging work on my plate as an engineering manager.

The feeling of being comfortable started settling in again. I tried looking for new opportunities to make an even bigger impact across engineering in Reflektive, but I felt like I couldn’t make big changes through just indirect influence alone. I felt uncertainty with where I can grow and what my next career step is.

Continuing down the management track was the logical option I considered, which meant becoming a director of engineering one day. Being in a director position at Reflektive would give me the authority to make sweeping changes within the engineering organization, which would enable me to have a greater strategic impact. However, it wasn’t very clear what exact path I needed to take to groom myself for that positional leap at Reflektive, nor was it clear how long that learning process would take. Even if the director path was concretely laid out for me at Reflektive, I felt like I’d do both myself and Reflektive a disservice if I pursued that role given my limited exposure to higher-level directors. (Both Teespring and Reflektive didn’t have director roles not including the heads of engineering, so I don’t have a strong sense of what’s considered being a “good” director versus a “bad” one.) Given that there’s much more at stake when you’re higher up, I didn’t want to operate through trial and error.

Last November, I started seeking advice from people about how I could go about my next step in my career, specifically how to prepare myself for a director role. Ironically, the feedback I got wound up pushing me to go back to an IC.

An experienced friend of mine bluntly told me that my work experience has been only limited to medium-sized companies (≤ 400 employees, ≤ 50 engineering teams) and web app technologies like Ruby on Rails and relational databases. As a director, I will probably have to oversee teams or work closely with other teams that operate in domains I have little familiarity with, and it’ll be harder to initially inspire confidence with the troops if you don’t have that “street cred.” There are two forms of managers, he argued: those who are hands-on with the team and continues giving architectural guidance, or those who completely get out of the way and just shields the team from organizational distractions. There’s no right or wrong way to be a manager, but he suggested that if I want to be the former type, I would benefit from broadening my technical perspective. There’s a whole slew of technical challenges that I haven’t experienced yet, whether it’s working with big data, working with alternative data stores or dealing with scaling challenges on a whole new level. Having that kind of exposure would enable me to make better strategic decisions down the road. He also mentioned that bigger companies operate at a much more mature scale, so joining a big company will give me a deeper perspective into what good engineering practices/processes really look like.

His feedback brought me back to the same exact fork in the road that I faced in 2015: I can either enter a new domain where I’d be challenged technically and continue deepening my engineering craft, or I can look for opportunities that can help launch me further into the management track.

The red pill, or the blue pill.

For a split second, his feedback was a punch in the gut and I felt foolish for thinking I was ready to be a director. But after the initial sting went away, it suddenly hit me that this is an amazing opportunity to deepen what I still enjoy: the craft of software engineering. I continued to learn and grow as an engineer outside of work; in my spare time I would research deeply technical topics such as information retrieval, database internals, operating systems and scalable distributed systems just for fun. Several of my close friends worked at big companies like Twitch and Uber the last few years, and I realized that our conversations around the product/design problems they faced also involved talking about the interesting underlying technical challenges that had to be overcome.

Unlike in 2015, where I thought creating software was as trivial as rails generate scaffold User and storing data in some managed PostgreSQL, I have a deeper understanding and appreciation of how technology choices truly are sources of differentiation for many companies. For example, technologies like Apache Storm and Spark has enabled companies to process data at scales never seen before with near real-time capabilities. High-availability data stores like Apache Cassandra are powering global systems like Uber’s and Facebook’s. (Side note: If you peel away a few of the layers for these technologies, you’ll see the familiar data structures and algorithms that we’ve learned to loathe in university. It may sound corny to hear, but there’s a real beauty in seeing these complex systems built on top of basic building blocks that I’ve learned nearly 12 years ago.) I feel I understand the theory of building a scalable distributed system, but hearing his feedback triggered something deep within me and made me excited again: there’s still much more room to grow.

In addition to wanting to scratch the engineering itch in me, a part of me wanted more financial security, something that a bigger company could provide. If I went back in time 5 years ago and told my former self what I just said, I think he’d be absolutely shocked. But my situation and goals are a lot different at age 32 than age 27. Back then, I wanted to optimize for autonomy and growth, and I was in such a rush to accomplish my career goals. If it weren’t for the startups I’ve joined, I don’t think I would have grown as much as I did across all dimensions. But now I’m marrying the love of my life, and I’m starting to think about what it’d be like to start a family. Several of my good friends who have worked in big companies recently told me that they’re grateful for the opportunities their financial situations afford them (buying a house, taking on more creative projects, not worrying about their children’s tuitions). While having autonomy and making an impact is still really important to me, I realize that I’d be much happier providing for and spending more time with Steph, my family and friends.

Finally, I believe that deepening my engineering craft in a big company will make me a much better technical leader, which will enable me to be an even more effective manager down the road. I always tell engineers that regardless of role or title, leadership is leadership. As a manager, I tended to operate a bit more on the strategic level: given all the different priorities and data that we have about the business and our team, what do we want to focus our team’s efforts? However, when it came to the implementation phase I depend heavily on key engineers at Reflektive to define out how we intend on executing against our roadmap, and executing it in a way that not only solves the requirements in a timely manner but also somehow improves the system long-term. This creates a natural feedback loop where the how sometimes opens up doors for the what that was previously thought impossible to do. It was through this experience that further deepened my appreciation for strong technical engineers who can lead projects across the finish line. Leaders in general are hard to come by, which makes the technical ones even more crucial. By broadening and deepening my technical expertise, I believe that it will further enable me to define the technical vision that brings engineering value beyond solving the immediate requirements, which will then further enable me to understand and identify critical strategic opportunities for the business.

After interviewing with some of the bigger companies, I decided to join Stripe, specifically the Payouts Platform team. There were three criteria that I valued most: impact, learning, and great team culture. Stripe and the Payouts Platform team ticked all those boxes.

Payouts is a critical component to Stripe’s value proposition (I mean, nothing gets more critical than giving our customer’s money to them with accuracy and in a timely manner), and because Stripe has aggressive plans to penetrate even more countries in 2019 (essentially doubling their presence in total number of countries), Payouts will be crucial in the growth plans. One example that I learned recently: while Brazil has a population of 200 million, nearly 90% of the credit cards issued in Brazil cannot be used to purchase goods outside of Brazil. Payouts will play a huge role in reducing the barriers to accept payments for merchants. Additionally, because it’s Platform work, the team’s responsibility is to support multiple teams across the organization with a reliable and simple interface. I know that whatever work I’ll do in the team will have great impact within the company.

There will be tons to learn at Stripe. The problem space itself is extremely interesting: how do you make inherently unreliable 3rd-party integrations power a reliable capability for the rest of the company, how do you build out the platform in such a way that doubling or tripling the number integrations will require minimal effort, and how do you guarantee correctness of the amount to be paid out to the merchants when dealing with a messy world of archaic banks with wildly varying SLAs, fraudsters and customer disputes? On top of that, what is the right abstractions that we want to provide to our upstream clients that provides them the capability of transferring funds from one account to another while at the same time hiding the complexities of the complex domain?

While it’s a Ruby-first shop, I’ll be working with Sinatra, Kafka and the document store MongoDB, which I’ve never really worked with professionally (other than building out a prototype many years ago). Because the Payouts team owns their own reporting infrastructure, there’s currently talks of rebuilding it from scratch, which means there will be potential opportunities to work with newer big data technologies as well. Also, the Payouts team manages its own Kubernetes cluster, and while the hiring manager seems keen on handing that off to a centralized devops team, I’m excited to get my hands dirty with it!

Stripe will be the biggest company I’ve ever worked for. With over 400 engineers and 1600 employees, I’m excited to see not only how it’s organizationally structured (how priorities and goals are created and how different levels of leadership operate), but also how teams build their software in a way that enables efficient interfacing between teams as well as learning different ways of thinking from the sheer number of people I’ll be working with. I’d imagine there’s going to be a ton of learning just purely through osmosis; and since I’m a curious cat, I know I’ll be sticking my nose into things that will be new and exciting to me.

I really connected with individuals on the Payouts team on multiple levels. I can see their passion and desire to build not just immediate value for the company but also do it in a way that will long term scale with the engineering and business needs. There’s strong alignment between the Product Manager and the Engineering Manager about where Payouts directionally needs to go and how building a system with rigor and correctness is a strategic asset. The EM did a really good job articulating the architecture and the vision, and I have a feeling that I’m going to have a great relationship with her. And on a personal level, I felt genuinely welcomed and really comfortable around them.

While the team is crucial, since they will be the ones I’ll be spending up to 50% of my waking life with, what also compelled me to join Stripe was its company culture. I was skeptical at first, since you’ll hear people throw out the word “culture” like it’s candy in Halloween even though they don’t have the faintest clue what having a strong culture entails (or, on a basic level, even why it even matters). But everyone I talked to, including a friend of mine who works there, talks about how they really enjoy the culture there in a sense that a) people are empowered to make decisions on an individual level, b) product and engineering work very closely together to come up with the requirements, c) the leadership team holds bi-weekly all-hands and share meeting notes with the entire company, d) the culture is blameless when there are production issues (I’ve heard positive stories of the CEO cautiously messaging on-call engineers to better understand the issues) and e) everyone is so nice. Each of those points are rare by itself (at least from what I’ve seen in my 9 years in startups), so to see all of them in one company is really impressive. On top of that, Stripe does a 2 week onboarding process where they not only talk about different aspects of the business, but they also walk through the general architecture of the platform and hold a Q&A with members of the executive team for the onboarding group. This just further reinforces their image that they’re really a people-driven organization.

Looking back, Reflektive was an incredible experience and I don’t regret a single moment. I grew a lot as an engineer, leader and, more important, as a human being. I’m grateful to have met so many passionate and smart people in this journey. While it’s tough to leave a place that gave so much to me the last 2.5 years, I’m excited for the opportunities, challenges and people that awaits at Stripe. I can’t wait to see where I’ll be 2.5 years from now!

If you enjoyed this post, I wrote a follow-up post Small Startup vs Big Company where I reflected over my experience 6 months into the job.