A manager and employee in a focused one-on-one conversation

Most 1:1s I've seen follow the same script. The manager asks "How's the project going?" The employee runs through a list. The manager nods, makes a note, unblocks something. The meeting ends. Repeat next week.

This isn't a 1:1. It's a walking stand-up.

The problem isn't the questions themselves. "What are you working on?" is fine. "Any blockers?" is useful. But these questions put the manager in observation mode. You're watching the employee's work, not leading them.

According to Gallup's 2025 State of the Global Workplace report, only 21% of employees worldwide are engaged at work, down from 23% the year before. Manager engagement dropped too, from 30% to 27%. The trend lines are clear: 1:1s are happening, but something isn't working.

Why Most 1:1s Miss the Point

There are five signs a 1:1 has gone wrong. The manager comes in unprepared and wings it. There's no clear objective for the meeting. The manager does most of the talking. Nobody follows up on last week's commitments. The whole thing stays on the surface of work rather than the experience of doing it.

Most of these failures share one root cause: the meeting is structured around the manager's needs, not the employee's. The manager needs to know project status. The manager needs to identify risks. The manager needs to check the box on "having 1:1s."

The employee needs something else. They need to feel seen, heard, supported, and equipped to do good work. A status update gives them none of those things.

The Question Most Managers Skip

A notebook with a question mark on a desk

Here's the shift: stop asking about their work and start asking about your performance as their manager.

Lee Woollsey put it precisely: "The three magic words every 1:1 should ask are 'What aren't you getting from me?'"

It sounds simple. It isn't.

Most managers are trained to see themselves as the evaluator in a 1:1. They're assessing, coaching, guiding. But the employee is looking for something specific from you... and too often they don't get it because you never ask.

"What aren't you getting from me?" flips the entire dynamic. Now you're the one being evaluated. You're signaling you want to serve them, not supervise them. You're giving explicit permission to tell you where you're falling short.

This matters because the answer will be true. Employees know what they're not getting from their manager. They think about it. They talk about it with their peers. They don't tell you because nobody asked, or because asking felt pointless, or because previous attempts to give feedback went nowhere.

A Gallup study on leadership trust found only 14% of employees feel their leaders actively seek their feedback. Fourteen percent. Meaning 86% of your team are sitting in 1:1s with feedback they're not sharing, because nobody created the space for it.

Why Tech Leaders Need This Most

If you lead a software team, this question matters even more.

Engineers are trained to be precise. They solve problems with information and specification. When they don't get what they need from a manager, they often won't say so. They'll work around it. They'll make do. They'll assume the manager knows what they're doing.

Then they leave.

The research on knowledge worker disengagement is consistent: people don't leave companies, they leave managers. And most managers have no idea what they're doing wrong, because they never asked.

"What aren't you getting from me?" asks.

What You'll Hear

A manager sitting alone at a desk, thoughtful, with a notebook open in front of them

The first few times you ask this question, you'll hear something vague. "No, I think we're good." Fine. Trust needs to build before someone tells their manager the truth.

Keep asking. Ask every few weeks. Make it part of your regular 1:1 rhythm.

When people start answering honestly, here's what comes up:

"I don't get enough context on why we're building this."

Engineers want the reasoning behind decisions, not only the decisions. When they don't get it, they fill the gap with assumptions... and wrong assumptions make wrong code. You fix this by sharing more: send the document before the decision is final, invite them to the conversation earlier, explain the trade-offs you weighed.

"I never know how I'm doing until performance review time."

Your feedback loop is broken. Engineers want signals along the way, not a verdict at the end of the year. Feedback delayed is feedback denied. Fix this by making one piece of specific feedback a weekly habit, not a quarterly event.

"I feel like I'm on my own when things get political."

They need air cover. They need to know you'll go to bat for them when a product manager or stakeholder pushes back on scope, timelines, or technical decisions. Without it, they protect themselves by saying less, taking fewer risks, and shipping safer work. A disaster for a team trying to do anything meaningful.

"I don't know what 'good' looks like here."

No clarity on how you define success for them. They're flying blind and trying not to crash. Fix this by writing it down. A clear, shared definition of what good looks like for their role removes enormous amounts of anxiety.

Each of these is something a manager controls. Not the employee. The manager.

Do Something With the Answer

Ask the question. Write down what they say. Then act on it.

The worst thing to do is ask "What aren't you getting from me?" and change nothing. Do it twice and you've taught them the question is performative. They stop answering honestly. And now you've made things worse, not better.

If they say they need more context, start sharing more. Bring them into the room earlier. Send them the reasoning, not only the decision. If they say feedback is missing, make it weekly instead of quarterly. Find one thing each week to name and respond to.

If they say something unexpected... thank them. Don't get defensive. Don't explain why you did what you did. Listen, write it down, and come back next time with evidence of what's changed.

Roy Rapoport describes this well: before someone improves, they need to agree there's a problem, want to fix it, own their role in it, have a plan, and execute. The same applies when the person improving is you. You have to agree you're the blocker, want to change, own it, plan it, and follow through.

Creating the Conditions for Honest Answers

"What aren't you getting from me?" only works if the environment is safe enough for a real answer.

If your 1:1s have historically felt like performance checkpoints, people won't answer honestly at first. If previous feedback has been met with defensiveness or excuses, people won't try again. If you only ask once and never follow up, nobody will take it seriously.

The way to build safety is small and consistent. Show up to every 1:1 prepared. Follow up on last week's commitments before starting new topics. When someone shares something uncomfortable, thank them specifically for saying it. When you act on their feedback, name it out loud: "You said you weren't getting enough context on decisions, so I've started sending these summaries. Is it helping?"

Visibility closes the loop. It teaches people your question was real.

The Trust Payoff

Lee Woollsey says it plainly: "Wanna speed up your team? Build trust. Nothing else comes close."

Low trust is a hidden productivity tax. Your team spends energy managing around gaps in leadership instead of building great software. They hesitate before bringing problems forward. They don't ask for help when they're stuck. They write overly defensive code reviews because they don't trust the environment.

Three words in a 1:1 won't fix all of this overnight. But they open the door to fixing the right things.

Ask the question in your next 1:1. Write down what you hear. Come back the time after with one thing you've changed. See what happens to the quality of the answers.

What are your people not getting from you?