Manager Toolkit: Useful Manager Phrases for 1:1s

For the first 2 years I managed, I started every single one-on-one with the same question, “What’s on your mind?” I’ve branched out since then, but I still find myself using a couple phrases multiple times per week in my role as a manager. I use many of these often enough that I’m sure my team is sick of them by now, but I stick with them because they work. With the team I manage and my management style, these questions lead to the kinds of discussions and coaching moments I value.

What’s on your mind?

I’ll start with the obvious. I did start Every. Single. One-on-one. with “What’s on your mind?” for years. I’m sure I found it in some “OMG, you’re a tech manager now” book or blog post, but I kept it up because I like the kind of conversations it leads to.

I don’t like to make one-on-ones all about status. There’s a time for that, but I prefer we use one-on-one time for problem-solving and strategy. To set the tone as something other than status, an open-ended question that can be about more than work is effective. With this question, I learn about what is happening in people’s lives outside of work. I sometimes hear gossip going around the company that I may have missed. I’ll also hear about any recent product or leadership decisions that are top of mind for folks. Their answer gives me valuable context for the rest of the 1:1. If someone is upset, I can shift the meeting to be about reassurance and support. If someone is excited, I can amp my energy up to match. If there’s something they’re proud of, we can celebrate together.

When I finally got bored of “What’s on your mind?” I switched it up. Recently, I’ve used “What’s on your list?”, “What do you want to talk about?” and “What’s important to you today?” to achieve the same goals. Even then, I still use “What’s on your mind?” several times a week.

How will we know when you are done? What does success look like?

In my experience, one of the most challenging skills to master, especially for intelligent folks, is defining success or even completion. Many folks I know, including myself at times, are prone to getting stuck in a revision loop. They’ll spend hours, days, or weeks trying to make the code 1% better or the slides slightly better visually, even if they’re past the point of diminishing returns. Additionally, in DevRel, it can be tricky to define success. Many DevRel teams don’t use metrics effectively, and even if they do, it can be hard to see how one person’s work contributes to the team’s success.

I help with this skill using two questions. First, we must establish when a project is complete. My go-to question to define completion is “How will you know when you are done?” or the slightly more intimidating “How will you, me, and my boss know when you are done?” Folks usually have an answer for this, although sometimes it is challenging, particularly with learning tasks or open-ended investigations.

Once we’ve established what “done” looks like, I follow up with “What does success look like?” Sometimes, just finishing a task is success. For example, closing bugs can be success. But there’s usually a bigger story if you look deeper. Maybe the end goal of closing the bugs is to see error rates fall.

If we’re struggling to define success, my next question is, “Why are we doing this work?” If that doesn’t help us find a good definition of success, I’ll say, “Imagine we time travel 6 months into the future, and we’re deciding if we should continue/repeat this work or invest more. How would you want us to make that decision?” Usually, one of those will break loose some ideas for evaluating the success of our work.

Many folks use the SMART(ER) goals framework to define success. For me, that’s the end state. In my experience, if you start with that framework, some people will pick any random metric for the measurable part, even if it doesn’t make sense or is out of their control. By starting with open-ended questions like “What does success look like?” we can define completion and success without the strict guidelines of a framework. After we’ve deciphered what our instincts say about success and brainstormed possible ways to evaluate our work, we can use a framework to formalize the goals.

If you had a magic wand, what would you change about the product/team?

Sometimes, in the sprint to a deadline, or the frustration of yak-shaving on an issue, we can get “blinders” and lose sight of the bigger picture. Losing context like this makes it difficult to make good decisions because you can’t anticipate how your work will impact others. I’ve also seen it contribute to a lack of developer empathy.

When I notice myself or others overfocusing on something in a problematic way, I’ll use a thought experiment to try to break out of our current myopia. Usually, I say something like, “If you had a magic wand, what would you change about this product?” or “If you had a magic wand, what would you change about the team?” The magic wand bit is essential. If I leave it off, people often limit themselves to what seems doable or easy. If the goal is to get beyond the current problem, we must stop worrying about what’s possible or easy for just a few minutes. Bringing in some whimsy, like the idea of a magic wand, makes it clear that reality and practicality aren’t crucial in this moment.

What are you trying to do?

This has been a favorite question of mine for more than a decade. Before I was a manager, I would use it when helping folks at meetups who were learning to code or learning Ruby. The answer to this question helps you quickly understand the level that someone is currently thinking at. Often, it also enables you to gauge their understanding of their tools and their problem. An answer of “I’m trying to make it not throw a null pointer exception” is different from “I’m trying to remove all the keys from this HashMap that have a value of false” and is different from “I’m trying to create the order summary page for my site.”

Once you’ve established the altitude someone is working at, you can tailor your response to their current level of thinking. Someone struggling with syntax doesn’t need a lecture on architecture.

Additionally, suppose their answer is highly technical but doesn’t match their code or doesn’t make conceptual sense in their language or framework. That is a sign that they misunderstood something several steps ago. When this happens, you need to work backward to find and resolve their misunderstanding before you can help them move forward.

I now use this question to help folks debug people situations about as often as I use it for code. When solving interpersonal conflicts, I usually need to ask it multiple times to truly understand the situation. “I’m trying to get so-and-so to stop being a jerk.” will morph into something more actionable like, “I’m trying to get them to respect my opinion and accept my proposed solution.” when you repeat, “What are you trying to do?” a few times.

Tell me more about that…

This last phrase I use frequently isn’t a question. It is the simple phrase, “Tell me more about that.” My team is diverse. They have different backgrounds, interests, and specialties and work on different parts of Google Cloud. They’ll often tell me about a problem they’re facing or something technical they’ve learned that I don’t know well. When that happens, I usually respond with, “Oooh, tell me more about it!” This isn’t limited to technical topics either. Recently a direct mentioned the game The Finals. I had never heard of it, so I asked them to tell me more and learned some fascinating things about current game trends.

I’ve tried some variants of this phrase. Years ago, a friend recommended “Teach me about that” to swap roles and shift power dynamics with your team. I’ve tried it, but it doesn’t work as well for me. I feel that the word teach makes the interaction too formal and puts expectations on folks to explain things the “right” way. When I’m really struggling to follow something and need more info, I sometimes fall back on “Can you give me more words about that?” or “Can you use different words to explain that?” or even “Can you give me the explain like I’m five version of that?” If I use one of these phrases, I am careful to repeat back what I heard so they can verify that I understand. That’s good active listening, but it also lets the folks on my team correct me and ensures we’re continuing the conversation from a place of mutual understanding.

Do you have go-to phrases?

I’m curious if others have phrases and questions they use repeatedly or if I’m unique in my choice to use the same questions repeatedly. Also, if folks have great questions or phrases, I’d love to add them to my managerial toolbox.