There’s a standard canon around how best to approach one-on-ones with your manager. A less common flavor is for product managers having one-on-ones with the direct engineering team they work with.
To be upfront, this can be a big time commitment — I personally can only manage a monthly cadence with everyone. That shouldn’t be a blocker though — the upside is worth it. In this article, I’ll explain the purpose of these one-on-ones and share the best practices I employ.
The purpose is to build genuine relationships with the people that your work most directly influences. Remember, the engineering team is the “user” of the output of your product management.
You might not become friends with everyone you work with, but at the very least you should see the engineering team as more than “resources.” This is important when work hits rough patches and disagreements arise. When intensely debating a decision, you have to separate the ideas from the people presenting them. You can judge an idea to be stupid, but you shouldn’t assign that label to the person who presented it. Everyone comes up with clunkers. If you have a one-dimensional view of the people you work with, you won’t have space to make that necessary separation.
One-on-ones also provide space for valuable feedback. It can take some effort to uncover (see below for more), but there’s a ton to be learned if you can figure out how to tap into it.
The #1 rule of general one-on-ones also applies here: it’s not a status update. It’s fine to have a conversation about ongoing work, but it should be higher-level than what you get from a standup. For example, debriefs on recent projects can be quite valuable: Where were the operational pain points? What worked well that we can apply to the whole team? Did you enjoy the work?
The #2 rule of one-on-ones also applies here: Come with questions and an agenda. Ideally the agenda is a shared responsibility, with both parties bringing discussion points, but you should also be ready to lead the conversation.
That being said, your goal is to turn the spotlight on the person you’re talking with and spend most of your time listening. Get them rolling on a topic, then get out of their way. Information flows as words flow, and topics will emerge and evolve naturally. You’re just along for the ride, so get in the habit of “active listening.”
The first step is “listening”. Don’t jump in with your opinions, solutions, or advice. I’m sure you’re a cool person and have a relevant story that you can share. Resist. This is their time to shine, not for you to one-up a story.
The second step is to encourage the speaker and keep them rolling. A fantastic, simple technique is to “edit back” what they’ve said, at natural intervals. It boils down to succinctly summarizing what they just said and slapping a question mark on the end. Doing so shows you’re listening, shows that you’re interested, and tosses the ball right back to them.
A basic summary structure to use is “So it sounds like …”, which is typically followed by a “Yes, and …”
Speaker: “One of the slowdowns was having to wait on team X’s approvals before we could make any of our changes. I spent a whole week stuck in PR review!”
You: “Oh man, sounds like our execution expectations aren’t aligned.”
Speaker: “Yeah, and they keep asking why we need to make these changes in the first place! …”
Take care to pass the ball back to them. For example:
Speaker: “Last week, I went to the mall and saw 100 people without masks!”
You: “100?? That’s crazy! What did you do?”
You: “Ugh, I hate it when people don’t wear masks! Last week when I was out, I saw …”
That being said, you should still find opportunities to share your own experiences and personality. One extremely simple way is to give an actual answer to the standard opener, “How are you doing?”. Instead of defaulting to “Pretty good, how about you?”, give a snippet of anything. A funny comment you saw, a frustrating encounter, a shower thought. Anything is better than “Pretty good, how about you?”
One parting note: these conversations can be awkward, stilted, and unenlightening at first. Keep going. It’s the repeated experiences that build familiarity, which leads to openness. And for yourself, use it as a chance to iterate and improve. Which questions led to dead ends? What were you surprised to find out, and how did you find it?
I put together a 9-part course on algorithms designed for non-technical readers that's a great, gentle introduction to thinking like a programmer. Get the course for only $5, or download the first chapter.