TPM Stories: Emily Nava from MainStreet

Interviewed by Iris Yuan, December 2021

Meet Emily Nava! Emily studied modern languages before earning a PhD in Linguistics. She started her career in the tech industry at Rosetta Stone, and was a TPM at Amazon and Twitter. She’s now building out a TPM team from the ground up at MainStreet. She lives in Colorado where she enjoys trail running, hiking, biking, bee-keeping, homesteading, drumming, and stout beers.

Tell us about yourself! How has your career transformed over the years?

I’ve always had a deep passion for languages and decided to get my PhD in Linguistics primarily because I had a question about second language acquisition that I really wanted to answer. While in graduate school I started coding and got into data science simply as a means to an end while analyzing large datasets. After I graduated I was all set to become a professor and was offered the perfect opportunity to do so. But to everyone’s surprise — including my own — I chose a job in the tech industry and have never looked back. As my career has progressed, I’ve chosen to dive deeper into data engineering and all things data storage, which is what most of my programs have covered. I’ve held IC and management TPM roles, and now have the extremely exciting opportunity to build out my own, brand new team of TPM talent.

How would you characterize your TPM or leadership style?

A: My TPM and leadership style can both be characterized as “lead from behind”. I’ve found that the greatest success comes when you’re able to leverage the implicit motivation of the teams and individuals that you’re working with. Leadership is never about telling people what to do. Instead it includes exposing a shared purpose and harnessing a motivation that already exists — the people you work with took the job that they have for a reason and you’re there to help ensure they can be successful! I’m also very data driven, which is critical to creating persuasive narratives and giving your stakeholders all the information they need to make decisions. As a TPM, you’re representing the business goals and collaborating with others on the design of an efficient solution. Clear and plentiful data is critical to achieving this.

What is your favorite part of being a TPM?

Hands down my favorite part of being a TPM is working to ensure the success of teams and their members. I love seeing other people reach their goals. As a TPM you have the unique opportunity to work with a set of highly talented people who contribute to distinct yet interrelated aspects of a large business goal. It’s incredibly rewarding to have the opportunity to support all of those experts coming together to benefit not only the company but each team and the individuals that comprise it. My other favorite thing about TPM’ing is always having the opportunity to learn. No two programs are the same and you’re constantly having to expand your understanding, investigate new things, and acquire knowledge and additional skill sets from your collaborators and the shared context.

“Of all the things that can boost emotions, motivation, and perceptions during a workday, the single most important is making progress in meaningful work.” — Teresa Amabile

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

The most memorable program for me was certainly not the most exciting program I’ve ever managed, but definitely extremely important. It was when I worked at Twitter and contributed to the Privacy and Data Protection (PDP) initiative. It was memorable for a number of reasons, including the scale of the program, the impact, and the hard deadlines. I made an incorrect assumption that it would be relatively straightforward to get teams to prioritize the work because it was required from a compliance standpoint. Instead it ended up being the program that required the greatest amount of nuanced stakeholder negotiation. Speaking of stakeholders, it was also memorable because in addition to product managers and engineering managers, other TPMs were my primary stakeholders.

How do you manage ambiguity in your work?

Ambiguity is as ubiquitous in program management as are requirements or deadlines. In order to deal with it effectively, I think it’s important to feel comfortable with ambiguity in all of its aspects — knowing when to call it out, when to let it ride and allow things to work themselves out organically, and crucially how to understand the root causes. Of course, large amounts of ambiguity come with the territory when you are still defining your program, but you expect it to decrease as you refine. Personally, my approach is to collect the data needed in order to do a root cause analysis, and once you understand the root causes, do an analysis of the risks they pose. Then I work with my key stakeholders to get the critical inputs that unblock us at the relevant insertion points along the way. Call out ambiguity as frequently as you need to, and listen to what it’s telling you about the broader structure of the organization(s) that you serve.

What were the biggest challenges you faced throughout your career?

The biggest challenges I’ve faced as a TPM have been people not fully understanding the TPM role, and then as a consequence being pulled into a program once it’s already well under way. We’re at an interesting time with the TPM role in our industry (which is why I’m so glad you’re doing these stories!) in that different companies and even different organizations within the same company vary in how they implement the role. So it can be an increased burden on the individual TPM who has to do a lot of education about their role in parallel with driving the program. And a lack of understanding about the role can also lead to TPMs getting pulled in once a program is already in execution mode.

“Follow the path of the unsafe, independent thinker. Expose your ideas to the danger of controversy. Speak your mind and fear less the label of ‘crackpot’ than the stigma of conformity.” — Thomas J. Watson

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

Advice I would give to someone who is considering becoming a TPM:

1. Earn experience: The most talented TPMs I’ve ever worked with are the ones who have strong experience under their belt before they transition to TPM work. Be strategic in how you earn experience (especially technical!) that will set you on the path to building out the kind of “rounded out” background that you’ll need to be successful.
2. Flourish with feedback: Be open to feedback any time, anywhere. Make it a habit to actively seek out feedback and to make it easy for people to provide you with it. Your openness to receiving it is just as important as what you do with the input that you get. And you’ll learn to be discerning about what to act on and what to dismiss.
3. Become a systems thinker: Thinking in systems is one of the best ways to ensure that you’re keeping the business / program goals as your north star, and that you’re maintaining the 500-foot view of how to align so many moving parts.
4. Influence with authority: As TPMs we put a lot of emphasis on the importance of influencing without authority — and for good reason, as this is certainly a huge part of the role! But TPMs also need to embrace the formal authority that they do have and to become comfortable wielding it.

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!