TPM Stories: Betty Luk from Stripe
Interviewed by Bhargavi Shankarananda, October 2021
Meet Betty Luk! Betty grew up in Toronto, Canada and studied electrical engineering at the University of Waterloo and Cornell University. She started her career in semiconductors, working in various engineering roles at AMD, and then moved to a Technical Program Management role at Facebook. She is currently a TPM manager at Stripe. Outside of work, Betty enjoys spending her time with her family, cooking, being outdoors, and making music.
Tell us about your career journey. What was your motivation to move to a TPM role?
I started as a hardware engineer out of school, mostly working in the lab, bringing up hardware, debugging why things didn’t work, getting products ready for production. Then I moved to a design and architecture role, writing code, specs and doing simulations. While that work was technically very interesting, I really missed working with others on a day-to-day basis. From there I moved to a roadmap planning role where my main focus was to drive planning and product roadmap definition for a business unit. It was only after that I moved on to my first official TPM role — though upon reflection, in many of my roles there was always a program management aspect to it, and I realized that was the work that really gave me energy — solving technical problems, driving programs, and working with others.
Where do you think a TPM can add the most value to an org?
To me, TPMs at the core are problem solvers and we focus on driving impact. We are in a unique position with a broad perspective. We are the neutral party whose main goal is to ensure that we solve the problem for our users and the business, and that the team is set up for success. As one of my mentors in the past put it, TPMs are the ones who have the responsibility to do the right thing for the business (and customers), regardless of organization boundaries. This helps create the right checks and balances in the organization.
Betty’s doodle on TPM career expectations.
You have previously been in a senior engineering role before becoming a TPM. How do you leverage your previous experience in your current role today? Any stories that you can share?
I think that an effective TPM is able to have empathy for the engineers on the team and having been in engineering roles has allowed me to walk in an engineer’s shoes, speak their language, and earn their trust. It enables me to participate in technical discussions, challenge things that don’t make sense, give better guidance to the team and ask questions that others might not have thought of. One of the large programs that I was running most recently as an IC involved heavy dependencies on external vendors and partnering with them closely. Having had the experience working at that type of company before in several engineering roles, and a deep understanding of their workflows and processes, allowed me to really dig deep into the data they were presenting (understandably, vendors tend to present a positive picture even in the face of challenges!). On multiple occasions, I was able to uncover hidden risks and put in additional checkpoints to help derisk the program overall.
What is the most memorable program that you have driven as a TPM? What made it so memorable?
One of the most memorable programs is one that actually never shipped in production. All the technical pieces were there, however due to viability and long-term sustainability concerns from a business perspective with an external vendor that we depended upon, it was the right decision to stop work on the program. What made this memorable was that I had the opportunity to work with a talented and thoughtful team who always put the needs of the business first, did not get emotionally attached to the work, and was unafraid to make the right decision, even if it meant that their work did not get productionized. It was an important lesson to learn that success comes in many shapes and making the right decision for the company is success.
How have you built a collaborative and high functioning team?
Bringing a team together is one of the most important things a TPM does to set the whole program up for success. Afterall, TPMs alone cannot deliver a program! My approach is to treat everyone with respect, share information transparently, ensure that everyone feels like they are equally invested in the overall success of the program and that their perspectives are valuable and heard. I spend a lot of time (especially at the beginning of a program) to make sure that everyone is aligned and bought-in to why the work matters, and how each and everyone’s work is critical to the success of the overall program. Another thing I have learned is that any interpersonal conflicts and issues need to be addressed deliberately and quickly — otherwise it can linger and really affect the morale of the whole team. For example, I once ran a program team where one of the male engineers was clearly dismissing the inputs of a fellow female engineer. The behavior was obvious to others, and it created an unhealthy tension in the room. To address this I did two things: 1) I gave direct feedback to the male engineer in a 1:1 setting letting him know the effects of his actions on the team, and that I did not think that was appropriate, and 2) within the meeting itself, I stepped in and made sure that I created space for the female engineer’s opinion to be heard. A lot of this has been applicable as well as in my current role as a TPM manager, and something I use in the approach that I take to building a healthy team.
If you had to quote that one core strength that has made you a better TPM, what would that be?
As the TPM, we are seen as leaders for the programs that we work on, and more often than not, unforeseen challenges will come up. People look to TPMs to be the calm in the storm, the voice of reason, and the person to lead the team through challenges. I think that learning to be unfazed, focused on understanding a situation, gathering data, and charting a path forward, under all circumstances, is a core strength that I’ve leaned on a lot in my work as TPM.
What were the biggest challenges you faced starting as a TPM in a new company?
A successful TPM needs to be able to influence without authority, understand how a company works, and know who to talk to. So as a TPM, we need to be able to ramp-up at a new company by absorbing a lot of context and breadth while building relationships quickly. One technique I have used is to really invest in getting to know people, asking many thoughtful questions about their challenges and genuinely seeking to understand why things are the way they are, before jumping in and proposing or making changes. I have found that goes a long way in building trust, credibility and buy-in with people.
As TPMs, what do you think is the best way to empower our leaders and make good decisions?
One of the key things TPMs do is driving changes and decision making. This involves articulating the problem, bringing in the relevant data, proposing / analyzing different options, and presenting a proposal to key stakeholders to make a decision and align on a path forward. By presenting a thorough data-driven analysis (that incorporates all the different vectors including technical, human, financial) and including all the stakeholders in the process, TPMs can empower leaders (and the organization) to make good decisions that stick and people buy-in to.
What advice would you give to someone who is considering becoming a TPM? What about a TPM manager?
I would encourage anyone who is considering becoming a TPM to talk to a few TPMs to get a sense for what the role is like and get a feel for whether that aligns with what they like to do. Unlike other disciplines, there isn’t one standard definition of a TPM, so there is always some ambiguity in the role definition, and in many ways, we have to define and set those boundaries ourselves. So for someone considering a TPM role, I would take that into consideration and figure out whether that’s something they would be comfortable with. For anyone who is earlier in their career, I would highly recommend getting a technical role and getting hands-on experience before moving to a TPM role.
As for moving into management — being a manager is indeed, as others have wisely told me, a different role than being an IC. As a TPM, we are fortunate that many of the skills required to be a manager we already use in some way as a leader of a program. That certainly helps with the transition, but doesn’t completely take away that a manager is definitely a different role, with different expectations and skill set needed. I would encourage folks thinking about this path to talk to other managers and understand their day-to-day and the challenges, and see how that resonates with what brings them energy. I would also suggest taking on manager-like responsibilities — getting involved in hiring and mentoring — to get a flavor of what being a manager is like. It is also important to consider the opportunity itself — for example, will there be support and resources to help ramp in the new role. Personally, I really enjoy being a manager because I love enabling others, and helping people grow and be successful. Finally, I think that career paths of today and in the future no longer look like straight-line paths — and the decision to become a manager (or not!) is not a non-reversible decision — I have worked with plenty of people whom I admire who have gone back-and-forth between IC and manager successfully, depending on the opportunity and timing.
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!
