What my 1:1s are for
The weekly 1:1 is the only meeting I refuse to cancel. Here is what happens in mine, what I stopped doing, and the three questions I ask every engineer at least once a quarter.
For my first year as a manager I ran 1:1s the way I had seen them run: thirty minutes, a quick status on the project, a look at the ticket board, and whatever was left for "anything else?" Most weeks there was nothing else. I took that as a sign the team was fine.
Then an engineer I thought was fine handed in his notice. In the exit conversation he told me he had been unhappy for four months. Four months of weekly meetings with me, and I had not noticed. I had been using the one hour a week that was supposed to be about him to talk about work he could have summarized in a Slack message.
That was the last status 1:1 I ran.
The meeting belongs to them
The rule I use now is simple. The 1:1 is their meeting. They own the agenda, they decide what we talk about, and if they want to spend thirty minutes on something that has nothing to do with the sprint, that is a good use of the time. Status lives in the standup, in the ticket, and in the weekly written update. It does not live here.
This sounds obvious and it is surprisingly hard to hold. Engineers who are used to status 1:1s will keep bringing status because it feels safe. When that happens I let them finish, then ask what they actually wanted to talk about. The first few weeks are awkward. Around week four the real topics start showing up: a teammate who keeps rewriting their code in review, a worry about being the only person who understands a subsystem, a question about whether they should go for the senior promotion this cycle or next.
None of that arrives if the meeting is about the board.
What I keep constant
I have a few fixed habits, and I keep them fixed because consistency is most of what makes a 1:1 useful.
The meeting is weekly and thirty minutes. I move it when I have to. I do not cancel it. Cancelling tells someone they are the lowest priority thing on my calendar, and they will believe that long after I have forgotten why I did it.
I keep a running document per person that only the two of us can see. Their items at the top, mine below, and a section at the bottom for things they have told me they want: the kind of work they enjoy, what they want to be doing in two years, what drains them. I read that section before every meeting. When a project comes up that matches something in it, I can hand it to them and say why.
I end with the same question every time: is there anything I should be doing differently? The first ten times the answer is no. Somewhere after that it stops being no, and the answers are the most useful feedback I get all year.
Three questions, once a quarter
Beyond whatever they bring, there are three questions I make sure I have asked every person at least once a quarter. I do not ask them all at once and I do not ask them in the same words every time.
What is draining you right now? Not what is hard. Hard is fine. Draining is the thing that makes them dread Monday, and it is almost always something I can change: a recurring meeting they should not be in, an on call rotation that has become unfair, a stakeholder who treats them like a vending machine.
What do you want to be doing a year from now that you are not doing today? This one takes a few tries before people answer honestly. The honest answers tend to be specific: leading a project end to end, presenting to customers, mentoring a junior engineer, moving toward infrastructure. Once I know, I can look for the opening. Most growth on my teams has come from matching an answer to this question with a piece of work that showed up two months later.
What should I stop doing? Different from the closing question. This one is about my habits, and I ask it directly. Answers I have received: stop rewording their design docs in the review comments, stop answering questions in the channel before they have a chance to, stop scheduling meetings at 4:30 on Fridays.
What changed during the AI rollout
The year we moved the team to an AI first way of working, the 1:1s did more work than any other meeting I ran. Adoption numbers came from the platform analytics, but the reasons behind the numbers came from these conversations.
One engineer who had stopped using the tools told me, after two weeks of asking, that a generated change had introduced a bug she caught in review and she was embarrassed enough to go back to writing everything by hand. Another asked, quietly, whether the point of all this was to need fewer engineers. A third had figured out a prompting pattern that cut his test writing time in half and had not told anyone because he assumed everyone already knew.
Every one of those became a program change. We added a session on reviewing generated code. I addressed the headcount question with the whole team, in public, with the roadmap. The prompting pattern went into the shared library with his name on it. None of that would have surfaced in a status meeting, because none of it was status.
The measure
If you want to know whether your 1:1s are working, count how many weeks it has been since someone told you something in one that surprised you. If it has been more than a month, the meeting has drifted back to status. Give it back to them.