TPM Stories: Simon Karpen from DoorDash

Tell us about your career journey. What was your motivation to move to a TPM role?

TPM is really the third phase of my career. I started out building infrastructure (my first role out of college was essentially “Solaris wrangler”), then spent several years doing consulting around infrastructure, security, and compliance. TPM has been a fantastic way to stay close to the technology while having a broader impact on the extended team and organization.

What do you enjoy the most about being a TPM?

I really enjoy helping partner teams be successful. It’s a really great feeling when you put in a ton of work building cross-functional alignment, setting up structures, tracking work, diving into the technical details, helping the team execute — and in the end, the team successfully ships a feature, launches a new tool, closes down a fraud vector, builds a new process, secures a system, passes an audit, or moves a business critical metric.

What is the most memorable program that you have driven as a TPM? What made it so memorable?

The most memorable program so far was probably Uber’s London license renewal. This was a huge cross-functional effort involving several technical teams, multiple TPMs, legal, policy, internal auditors, external auditors, and of course the Uber London operations team. At the culmination of the whole effort, it was a tremendous feeling to see the Magistrate determine that Uber London was indeed a “Fit and Proper” operator.

Simon’s doodle on the TPM experience

You have previously been in other technical roles before becoming a TPM. How do you leverage your previous experience in your current role today? Any stories that you can share?

There are two different dimensions of leveraging the technical experience — technical context, and hands-on technical experience.

What have been some of the hardest challenges you have faced as a TPM? How did you overcome it?

Some of the hardest challenges I’ve had as a TPM haven’t come from difficult projects, tight deadlines, or challenging stakeholders — they’ve come from challenges around maintaining a healthy boundary with partner teams. There is a fine line here: you need to be enough of a part of the team to be inside the decision loop, and to have the right relationships, but you need to also maintain a healthy distance. In one case, I had a partner team of junior engineers with an absentee EM, no PM (in this role, TPM doubled as PM), and minimal engineering mentorship. I worked really closely with the team as a functional TL / tech mentor, even going as far as joining engineering work sessions and debugging / rewriting queries for engineers. This enabled us to ship critical deliverables (good), but didn’t allow me to scale the role in the ways that it should have been scaled (bad). I learned a lot of lessons there about both appropriate boundaries as a TPM, and when to escalate rather than just accepting the situation as-is.

You have been a TPM at various companies. What are some of the similarities in the roles you’ve had, and what are some differences?

The fundamental key tenet across all of the TPM roles has been influenced without authority. Your job is to drive programs to completion, on behalf of a key stakeholder or set of stakeholders (might be business, product, engineering, etc). As a TPM, you do not have anybody directly in your reporting chain (and the people completing this work are often well outside your reporting chain). Your primary tool is your ability to influence people to do what is needed. You can’t assume context; you have to help partner teams understand why what you are driving is important, and of course bring data where it is at all possible.

  • One company with a team of storage TPMs
  • One company with a single TPM for all things storage
  • And at DoorDash we have one TPM for all things infrastructure

Can you share some tips on how to ramp up as a TPM in a new company?

On the technical side, it’s hard to beat going through the normal engineering onboarding. Even if it’s optional, or you have to ask for an exception, go through engineering onboarding if at all possible. At DoorDash, TPMs go through engineering onboarding by default. You may never commit code as TPM, but it’s a great way to quickly learn the vocabulary and the overall system architecture and design. You’ll also likely learn who some of the SMEs (subject matter experts) are, and maybe even learn something about the business.

In what ways have you grown as a TPM? What resources have helped you grow?

The majority of my growth as a TPM has come from experience and mentorship. As a TPM, you should be looking to take on projects that are a bit of a stretch; maybe they have components or aspects that you know well, but there are also areas that are a stretch or will require some quick learning. I’ve also had some great mentors as a TPM, including my current manager here at DoorDash. It’s important to find yourself both formal and informal mentorship (the informal is often more valuable), and remember that mentors don’t have to be in your management chain or organization.

What advice would you give to someone who is considering becoming a TPM?

TPM is an intersectional role — you work across the business and technical domains, and your long term growth will be in both of these domains. It’s also mostly not a hands-on technical role — you may do some data analysis, dashboarding, maybe light scripting — but you’re likely to never touch production. On the business side, you’ll be partnered with business teams, but you’ll never own a P&L. There is a huge opportunity for impact, but you have to be comfortable with the fact that your impact is all indirect. If you really want a pure technical or pure business role, TPM is likely not the right role for you. If this level of indirection, intersectionality, abstraction and ambiguity sounds like a great adventure, TPM may be the role for you.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
TPM Stories

TPM Stories


TPM Stories is a collective of experiences and journeys featuring Technical Program Managers across the industry.