TPM Stories: Andrew Cordova from Stripe

Interviewed by Iris Yuan, December 2021

Meet Andrew Cordova! Andrew is a Technical Program Manager at Stripe, supporting engineering teams building Stripe’s Global Payments and Treasury Network. He lives in San Francisco, California, where he tries to take advantage of the Bay Area’s food and access to the outdoors.

Tell us about your current role at Stripe. How has it changed over time?

Currently, I’m a Technical Program Manager supporting one of our core infrastructure teams in Payments. Specifically, I work with our engineering teams building the Global Payments & Treasury Network.

I’ve been at Stripe for 4.5+ years, and one of the things that excites me about the role and company is the breadth of projects I’ve had the luck to manage. The core competencies of the role — solving ambiguous, technical problems across several teams and orgs — has remained the same. But, the application of those skills has led me to focus on projects ranging from mitigating credit and regulatory risk to building systems that enable new user features.

Being a TPM affords you the opportunity to jump into the highest priority areas at a company. Naturally, it can feel like every quarter is a bit different, and I find that invigorating.

You have a unique background (History degree and working for law professors!) How has your previous experience helped in your current role?

While it might not seem intuitive, I think that my early days studying history and working in legal academia gave me the foundation to be an effective TPM. History requires you to ask questions and collect information. And, the best history pulls from many sources. Your job is to take that information and identify what’s consequential, structure it in a coherent way and respond to a question whose answer wasn’t obvious at the beginning. And, the law requires you to issue spot, anticipate outcomes and look around the corners. To me, that sounds exactly like the day-to-day of a TPM.

Moving into a TPM role, I think I was at an advantage because I had those previous experiences. (But, I have to say: being a TPM is much cooler than reading and writing papers/briefs all day!)

How has your career transformed over the years and how did you become a TPM?

I never expected to move into a TPM role. (In fact, I didn’t even know such a role existed when I first started working!). I naturally fell into it. I’ve always preferred to work across various teams, driving long-term thinking and making considered trade offs. And, I’m motivated by the challenge of starting with a vague problem statement and finding the path towards a solution. In a nutshell, I think that’s the value a TPM can bring to the team. And, I think that’s the work I’ve always tried to find, even if I didn’t know there was a specific role where that was the expectation.

It also is worth mentioning that I’ve been the beneficiary of great managers and mentors who encouraged me to take on this type of work. And, they really helped me navigate career choices and possible paths I could take. Luckily, I landed in a TPM role, and I have no reason to believe I’ll make a transition any time soon.

TPMs can help teams move mountains! Any instances you can relate to?

I think a lot of the glory that comes from being a TPM is helping teams get unstuck. At the end of the day, a TPM isn’t deploying code. Instead, we’re focused on everything that happens before that. And, there’s a lot of things that can impede the end result.

By applying a bit of structure, managing stakeholders, considering scale and risks, TPMs can create the environment to let engineers do what they do best: code! When we say that TPMs can help move mountains, we should think about it somewhat literally: there’s this big giant boulder in the way of a team getting from Point A to Point B. How do we (as TPMs) build the tunnel through that mountain or chart the pass over the summit?

I see TPMs do this every day, navigating small hills and the Everests.

“Everyone needs a ̶t̶h̶e̶r̶a̶p̶i̶s̶t̶ TPM!”
— Andrew’s favorite quote to represent the work.

How can a TPM contribute to innovation & overall success?

If you look at how a company is organized, the majority of folks aren’t looking at progress horizontally and over a long time horizon. Typically, an employee is focused on the task at hand, within their teams and areas. A TPM, however, is responsible for observing a much broader constellation.

TPMs contribute to innovation and overall success because we connect the dots and encourage teams to make smarter choices that align with longer architectural goals. We are a voice that pushes for more rigorous thinking and collective ownership. That means the end result is a technology that’s more scalable, extensible and performant.

How would you characterize your leadership style?

Whenever I’m working with a team, I very much see my leadership style as primarily acting as an effective facilitator. I think deeply about the conversations we need to have, with whom and with what context. And throughout that process, I need to have a strategy for how I’m going to guide the team to solve the problem or meet the goal. I might not be the person with the answer, but I am the person who can help make sure we find the answer.

Sometimes, I might need to get into the details; other times, I might need to apply a simple framework. At the end of the day, I think it all comes back to having a variety of tools and levers at your disposal to shepherd a team through or over the mountain.

Having a facilitator-first mindset has proved helpful to me in my role. I think it has allowed me to work with teams where we have shared responsibility in driving results, and I think it makes us better problem solvers.

What do you think about career development as a TPM? Any resources?

I have a lot to learn as a TPM, and career development will always be a focus for me. In the past, I’ve found I’ve learned the most from other TPMs. There’s no one way to solve a problem or achieve a goal. Some of the frameworks I use day-to-day aren’t original to me — I learned them from others (like using a MECE to breakdown problems or RACI to ensure you have the right stakeholder alignment). Our greatest resource to grow in our roles is learning from the experiences of other TPMs. We should be taking more advantage of each other.

Any tips to succeed in the role, particularly for those starting out?

We should never underestimate the power of regular communication, both out to stakeholders and up to leadership. It can be challenging to learn how to write for your intended audience: What’s the right level of detail? What’s the most critical information? What are the key takeaways? It can also be challenging to scale communication since it comes in so many variations. When I first started as a TPM, I didn’t have a good barometer for what good communication looks like, and I needed to quickly learn because I knew it’d limit my overall growth.

Some tips I use:

• I always draft important emails in a separate doc so I can edit as much as I want without fear of hitting send
• At the top of my draft, I always write who I’m sending the email to so I know my audience
• I use the SCQA method pretty frequently to give overall structure to my written communication

Sometimes we as TPMs implement a structure that just doesn’t work — that’s okay! The important thing is that we solicit feedback, hold retros, and pivot quickly. Like I said before, there’s no one way to solve a problem or meet a goal. Sometimes it takes a couple tries to figure it out. Effective TPM-ing is realizing the error and pivoting when needed.

TPMs — What’s your story? If you are interested in contributing or sharing your story, please reach out to Iris Yuan, Bhargavi Shankarananda, or Betty Luk!