TPM Stories: Simon Karpen from DoorDash
Interviewed by Betty Luk, October 2021
Meet Simon Karpen! Simon is a Technical Program Manager supporting Business Intelligence at DoorDash. Simon has also managed programs around Security, Compliance and Infrastructure at DoorDash. Prior to DoorDash, Simon has worked as a TPM at Uber, Facebook, and Google. In his spare time, Simon enjoys the outdoors, cooking, travel, books, movies, and spending time with his family and two cats.
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.
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.
For technical context: many years ago, in multiple contexts and roles, I was on call for databases or responsible for production database operations. This ranged from a small startup (up to 14 people when I left) all the way up to enterprise SaaS. Much more recently, as a new hire TPM at DoorDash, I was able to dive right into an urgent database reliability program. While I was still learning the business, having this technical context allowed me to ramp up quickly and be successful as a TPM.
For the hands-on experience, one of the most valuable skills (for me) has been SQL. Time and time again, I’ve found that it’s incredibly useful to be able to go directly to the data myself, write my own queries, and draw my own conclusions. For example — I was trying to figure out why widget deliveries were late. There was an accepted explanation, but I suspected it did not fully explain the problem. I was able to dive into the data myself, verify that the accepted explanation was insufficient, test alternative hypotheses, and dig deeper into the problem space. Based on the data, I knew who to talk to and what questions to ask. It turned out that the problem was a constraint that was poorly understood and, once we started planning around it, we had a much better record of on-time deliveries.
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 huge difference between TPM roles has been scope. In a larger company, with a substantial established TPM team, the scope of an individual TPM role tends to be narrower but deeper. In a smaller company, with a small TPM team, you tend to have a much broader scope. For example, in the Infrastructure space, I’ve seen:
- One company where each storage team has a TPM or two
- 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
A fast-growth company like DoorDash offers a tremendous opportunity in terms of breadth, scope and influence, versus larger companies which can provide more opportunities for depth and specialization.
Another important difference I’ve experienced is organizational structure. In some companies, including DoorDash, TPMs generally belong to a TPM team (though larger companies may have a few different TPM teams). This can provide great opportunities for mobility and mentorship, and a sense of community within the TPM community. I also greatly appreciate that my manager has worked as a TPM — she’s done the job and truly understands the role. In other companies, TPMs report to engineering managers, which means that you have an opportunity for deeper engagement within a single team / organization, but tends to lead to a heavier process for mobility.
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.
However, as a TPM, the most important thing to do is get to know key stakeholders and SMEs. Start by asking your manager, mentor, onboarding buddy, etc who you should meet up with, and get some time on their calendar — in 2021, this almost certainly means a Zoom meeting, but if you are in the same physical location, coffee is highly recommended. Ask questions, understand their role / world, and make sure you ask who else you should talk with. If you’re managing TPMs, include a list of “who to meet” in their onboarding plan. I found this really helpful when I started at DoorDash.
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.
At the same time, growth as a TPM needs a solid foundation. I’ve found formal training in traditional waterfall (PMP class, didn’t take the test) project management to actually be quite useful. I’ve also done formal Kanban training, which provides a great foundation for managing operational flows. While it’s absolutely not a hard requirement, I’ve found that the foundational business knowledge from an MBA pairs quite well with a technical undergrad degree and early career. I’ve also found experience in consulting to help in building this foundation, and in many ways a TPM can be similar to an internal consultant.
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.
If you are considering TPM as a new graduate, I would strongly recommend getting at least 5 years of hands-on technical experience first. As a TPM, you need to be technically credible — the TPM role is much more than a project manager, and the hands-on experience will give you the experience you need to be technically credible.
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!
