TPM Stories — Bryan Nealer from Stripe
Interviewed by Betty Luk
Three TPMs share their experience in our mid-2022 edition of TPM stories — including being your authentic self, and transitioning from IC to management.
Meet Bryan Nealer! A bit about Bryan in his own words: “I’ve been bouncing between engineering, product, and TPM roles since graduating with CS and Math degrees from Northwestern. Along the way, I nabbed an MS in Computer Engineering and an MBA, and I found myself living in Austin, Seattle, Paris and London before settling into remote life. I’ve been lucky enough to work at amazing companies like Microsoft, Meta and now Stripe, and to work with even more amazing people, many of whom I am lucky enough to call my friends outside of work.”
Tell us about your career journey. What was your motivation to move to a TPM role?
When I started working the title “TPM” didn’t exist — there were devs, PMs, and test, and I was a dev, cause that’s what you do when you graduate with a CS degree. And honestly, I was just an ok dev. I struggled to break away from the textbook way I was taught coding — my professional code was academic, attempting to be clean and elegant (emphasis on “attempting”!); I wasn’t making the transition to “software engineering” very well. But those years as a dev helped me realize that I liked the process of figuring out what to build and how to build it, so I switched gears to Product Management. At that time, “PM” was a bit of a grabbag mix of project management, design, system architecting, product marketing, and more. Over the years, the industry clarified and teased apart into distinct disciplines these various early PM roles; given my strengths and interests in system architecture and driving cross org technical initiatives I naturally gravitated to TPM as the discipline materialized.
What do you enjoy the most about being a TPM?
At the majority of tech companies developers are a company’s most important (and usually most expensive) resource. My goal each and every day at work is to be a force multiplier to a program spanning multiple teams of devs — that is to say, if my work isn’t helping developers working across some gnarly program to build or improve the right things with higher quality and efficiency, then why am I there? Yes, I love shipping great products, simplifying program complexities, translating complicated scenarios for less technical stakeholder, being customer obsessed, driving cross org collaboration, [insert TPM JD phrases here], etc, but mostly I love TPM’ing when a program to do X simply does better because I was there.
What is the most memorable program that you have driven as a TPM? What made it so memorable?
I helped a small, hard working, smart group of developers at Meta who were focused on keeping the company’s various Android and iOS apps’ disk footprints as small as possible. Apps tend to download and cache lots of content and over time they can get bloated. Reliability and performance issues increase as apps get bigger, but more importantly, an app is more likely to get uninstalled by a user looking to download the latest version of Candy Crush on a phone with limited disk space, and that’s obviously not good. Not many companies have the resources to focus on this type of technical challenge and the work was always intellectually rewarding. As the TPM, I worked with the team to brainstorm solutions, set ambitious technically based goals, breakdown the goals into scoped projects, and to architect solutions. Then we needed to work across hundreds of teams throughout the company to encourage and consult on usage, experimentation, and more. Watching our success metrics improve over time was incredible. And the cherry on top, the team was great — collaborative, hardworking, and silly.
What have been some of the hardest challenges you have faced as a TPM? How did you overcome it?
One of the hardest challenges I face as a TPM is setting clear expectations about my team’s roles and responsibilities with both engineering and TPMs themselves — what we are best suited to do (eg, own a meaty, complex, cross group program), what we will help with but we don’t want to do forever (eg, building then driving a team’s scrum process), and what we should share with everyone (eg, taking notes). Clarifying the role takes repetition, patience, and rapport. The best TPM leaders spend countless 1x1s and coffees with their directs, EMs and other stakeholders to set clear expectations on the role. Without this groundwork, TPMs sometimes end up doing more and more work outside their scope — this negatively impacts the return on investment the company gets from a TPM, and also probably their TPM’s job satisfaction.
You have previously been in product manager roles prior to becoming a TPM. How do you see the PM and TPM role differ?
I oversimplify PM vs TPM as a simple linear spectrum. On one end you have someone (usually with a mechanical keyboard) who code reviews, builds out system architectures, and has a 500 row spreadsheet of technical dependencies that they’re tracking the status of across organizations. On the other end of the spectrum you have someone (usually with a latte) with vast user and segment knowledge, a keen marketing sense, ninja skills with Figma or Sketch, and incredible product vision. I am generalizing of course (also, I love lattes AND mechanical keyboards!), but TPMs tend to skew to the former, and PM to the latter. In my experience the best TPMs can flex towards the PM strengths, and vice versa, depending on a program’s needs.
You’ve been an IC and a manager in your career. Can you tell us what that transition was like?
Luckily the transition from IC to manager was easy for me. I had a strong support system of mentors and peers to provide guidance and course correction on the ways I was running and supporting my first few teams. If you are moving into management I encourage you to not be shy asking for feedback and guidance from your fellow managers, especially in your early days of management.
What wasn’t easy for me initially was staying authentic to myself. I can be loud, self deprecating, and certainly silly at work. As I fill awkward silences with stupid and embarassing quips I think to myself that I’d rather be rough around the edges than boring — hell, you only live once. But when I switched to management I toned that down dramatically as I didn’t want to risk it reflecting negatively on my team in any way. That was the wrong decision as by repressing my authentic self, I wasn’t leading with honesty. I truly believe that my directs could sense that and it hindered my ability to connect to my team. I now allow myself to be more true to my instincts and I even try to use them to help me do my job better. No matter what, and definitely if you want to connect well with your team, you shouldn’t hide who you really are either.
What advice would you give someone who is considering moving from IC to a manager role?
As a manager, I try to remember my favorite attributes of the many managers I’ve had during my career. For me, the best managers I’ve had gave hints and nudges without explicit direction or micromanaging; they would let me fail to learn, and have my back even if I was off course; they were laser focused on the end user and high quality; and most importantly, they were good humans: empathetic, humble, and kind. As a manager, I am nowhere near some of the great managers that I’ve been lucky enough to work with, but I try. If you’re considering the manager track, think about what made your favorite managers great and whether you have the drive and ambitions to pass those good experiences on.
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!
