Need someone to lead product management at your software company? I create software for people that create software and I'm looking for my next opportunity. Check out my resume and get in touch.

What should you talk about in a 1:1?

Freshness Warning
This blog post is over 5 years old. It's possible that the information you read below isn't current and the links no longer work.

The first thing to remember when conducting one-on-one meetings is that this is your employee’s meeting. It’s there for them to bring things up that need discussion. It’s for them to solve problems, to make you aware of roadblocks, to celebrate successes. Because of this, the employee should drive most of the agenda.

You might have some things to bring up, but 80% or more of the agenda to be owned by your report. (And you shouldn’t assign work in a 1:1. More on that in a future post.)

For an effective 1:1 it’s crucial that there’s an agenda. Like any other meeting, without an agenda, you’ll just wander from topic to topic and tend to miss things. I like to get an agenda the day before the 1:1. This is mostly a forcing function to get the employee to think about what they want to talk about and to maintain a list of topics that come up throughout the week. If they have to send an agenda, they’ll find it’s easier to build one over the course of a week than it is to make one up from scratch each time. This has a side effect of helping ensure you’re not just talking about whatever issues are recent and top of mind, but covering things that are deeper than that.

It also helps me prepare. If I know they want to talk about funding for Project Unicorn, I can be ready with the budgets for that project or ask Finance for the latest status before I walk into the meeting.

If someone doesn’t have an agenda at all, I’ll spend the first 3 minutes discussing the agenda. What are the bullet points you want to talk about today?

The key to having effective 1:1s is to keep them from becoming status reporting meetings. Status should be reported in email, and if I have a report that’s just giving me status reports in our 1:1, I’ll ask them to start sending me a status report by email or chat on Friday afternoons or Monday mornings. Give them another channel for this, so they won’t want to duplicate efforts by discussing it live. That said, occasionally, someone really just needs to talk through what they’ve going on. Try and recognize the difference between “I have nothing else to say, so here’s a list of what I’m working on” and “I’ve got a lot going on and I could use a sounding board while I list it all off.”

Likewise, you’ll want to avoid doing work during the 1:1s. The 1:1 is about improving the way you work, not about improving the work. If your report needs to talk in depth about their ideas for how to accomplish Project Unicorn, get them to set up another meeting about that. If you start letting the 1:1s become working sessions, you’ll lose the benefits of having 1:1s. You can always schedule a working meeting, but you can’t really add a new 1:1.

The 1:1 should be reserved for harder conversations. What’s your report having problems with right now? Where can they use your help? What are they doing that’s hard, where are they overwhelmed? How are they doing as a human?

This is one of a series of posts about holding 1:1s. View the rest of the series.

Recently Written

Mastery doesn’t come from perfect planning (Dec 21)
In a ceramics class, one group focused on a single perfect dish, while another made many with no quality focus. The result? A lesson in the value of practice over perfection.
The Dark Side of Input Metrics (Nov 27)
Using input metrics in the wrong way can cause unexpected behaviors, stifled creativity, and micromanagement.
Reframe How You Think About Users of your Internal Platform (Nov 13)
Changing from "Customers" to "Partners" will give you a better perspective on internal product development.
Measuring Feature success (Oct 17)
You're building features to solve problems. If you don't know what success looks like, how did you decide on that feature at all?
How I use OKRs (Oct 13)
A description of how I use OKRs to guide a team, written so I can send to future teams.
Build the whole product (Oct 6)
Your code is only part of the product
Input metrics lead to outcomes (Sep 1)
An easy to understand example of using input metrics to track progress toward an outcome.
Lagging Outcomes (Aug 22)
Long-term things often end up off a team's goals because they can't see how to define measurable outcomes for them. Here's how to solve that.

Older...

What I'm Reading

Contact

Adam Kalsey

+1 916 600 2497

Resume

Public Key

© 1999-2024 Adam Kalsey.