How to be a great product partner to your Tech Lead

Feb 01, 2022

Today's memo is sponsored by Flatfile: Solve the critical stage of your product onboarding with the platform built to get customers to value, faster. Flatfile enables you to focus on building product features your customers need, not wasting cycles on cleaning spreadsheets. Your product deserves a world-class data import experience.

I’m always thinking about how to be a better partner to my tech lead (TL) and how to distill my learning into a repeatable formula I can adapt to any situation. I remember once kicking off a meeting for a PRD I had just written with a new tech lead. My goal was to finish the meeting with a timeline and milestones. While we accomplished those things by the end of the meeting, I had a sinking feeling that the meeting didn’t go well, but I couldn’t pinpoint the reason.

I realized the uneasiness came from the tech lead’s confidence that the project would be easy to implement. I didn’t feel like we were able to dig deeper into the risks, but at the same time, I wasn’t an engineer and didn’t feel equipped to identify technical risks, and I didn’t want to make her feel like I didn’t trust her technical judgment.

Over the years, I realized there were two guiding principles to approach conversations with my tech leads in order to maximize the likelihood of a product launch:

Evaluate my technical lead
Evaluate the product

1. What can my tech lead do?

The first thing I do is assess what my tech lead is able to do.

Are they junior or senior?
Are they proactive or dependent?
How long can they run with ambiguity for? 1 month? 3 months? 6 months?

I’ll ask about the size of projects they’ve worked on in the past, and ask them to walk me through decisions they made for each project:

Junior TLs tend to describe projects with smaller scope and limited variance in outcome. They usually describe successfully executing a plan rather than including their own judgment and decisions in the outcome.
Senior TLs tend to recount times they’ve come up with their own brilliant solutions given little information about goals and parameters, and can speak in detail about the reasoning behind their decisions.

An example conversation:

PM: “Great working with you! I want to be the best PM I can be for you, and I value our partnership. I want to learn about your past projects so I can learn about your working style. Could you tell me about a few things you worked on?”
TL: *describes projects she’s worked on*
PM: *diagnoses the tech lead, and decides on the best way of partnering with them, and the amount of ambiguity and scoping to provide as a PM partner*

Here’s a framework:

2. Evaluate the product

Depending on what success means for the product, different types of products will dictate different conversations, since you will need your technical lead to prioritize different things. Specifically, there are two types of PRDs:

Use conversations as an opportunity to work their brain

A Great PM adjusts the approach to conversations with tech leads differently, based on an understanding of the tech lead’s capability and the needs of the PRD. Sometimes there's a temptation to rush to get a finished list of milestones and associated risks. This can often lead to gaps and ambiguity in the project -- for example, suppose a TL says "We can build the front end in React, which will take 1 week, and a Node.js backend which will take 2 weeks, this will be pretty easy to set up."

Bad PM: *gives into the temptation to trust the TL without the above 2 diagnoses; blind trust leads to believing that everything will go smoothly* Ok great.
- Outcome: risks get swept under the rug

Good PM: *resists the temptation and instead sees this as an opportunity to work their brain and dive into details* What are the different components of the React front end? Which of those components are most likely to fail?

By calibrating answers from the TL with the context you’ve gathered about their capabilities and PRD, you can ensure the success of your product launch.