What I think a one-on-one is for

A wooden pier railing in the foreground, with a harbor of moored boats and a tugboat under a cloudy sky

The one-on-one is the meeting most likely to drift into a status update, and I think that is the one thing it should never be. Status has other places to live, such as the standup, the board, and the pull request. The one-on-one is the only half hour in the week that belongs to one person and their working life, and spending it on ticket numbers gives that away cheaply.

What I think it is for

Three things, in rough order of how often they come up. First, the thing that is bothering someone and has not been said anywhere else. A review that landed badly, a decision they did not understand, a worry about where the product is going. Second, growth. What they want to be good at in a year, and what in the next month moves toward that. Third, context from me that they would not otherwise get, such as why a priority changed or what a conversation two levels up actually meant.

None of these fit a status format, because none of them have a ticket.

Why I believe this

In fifteen years of running UI teams I have noticed that the problems that became expensive were almost always said out loud early, quietly, in a one-on-one, and then not heard because the meeting was busy with updates. The meeting that catches those is worth more than any report it could replace.

It also changes who owns the meeting. If it is a status update, the manager is asking and the engineer is answering. If it is about the person, the engineer brings the agenda and the manager mostly listens. I think the second shape is where trust gets built, and trust is what makes the hard conversation possible later.

The best argument against this

Some people genuinely want to talk through their work in that slot, and for them the work is the person. I think that is fine, as long as the conversation is about the work as they experience it, what is hard and what they are unsure of, rather than a readout for me. The difference is who the information is for.

Where it stops being true

A new hire needs more structure than this, and for the first month a one-on-one that walks through the week is a kindness, not a waste. A team in the middle of an incident or a release crunch will have status in every meeting whether anyone plans it or not. And a very senior engineer may want the meeting monthly and use the time between for the work. I would rather adjust the cadence than let the meeting become a form.

The question I keep asking myself afterwards is whether the person left with something they did not have before. When the answer is a list of tickets, I think the meeting went to the wrong thing.

Photo source: https://photos.robertstowe.com/tasmania