I still run a weekly 1-on-1 with an engineer I hired seven years ago as a junior. Back then, most of our thirty minutes went to me unblocking her: which library to use, whether her migration plan was safe, how to read a stack trace she'd been staring at for two hours. Last week she spent our whole slot telling me she thinks our payments reconciliation team is understaffed by two people and walking me through the risk model to prove it. Same meeting on the calendar. Completely different meeting.
That drift is the point. If your 1-on-1 with someone looks the same in year three as it did in month three, one of two things has happened: they stopped growing, or you did. Neither is good, and the second one is your fault.
The meeting is a mirror of where they are
A 1-on-1 is not a status update. If you want status, read the board. The meeting exists to give a specific person what they can't get anywhere else in the org, and what that is changes as they get more capable. Treating the format as fixed is like giving every patient the same prescription because it worked on the first one who walked in.
The mistake I made for years was assuming the agenda belonged to me. I had a little mental checklist: are they blocked, are they happy, do they know what's next. Fine questions for a nervous new hire. Insulting to a staff engineer who has been shipping to production without my input for three years. When I kept running the checklist on senior people, they went quiet in the meetings, and then I'd wonder why the 1-on-1 felt like pulling teeth. It felt like that because I was interviewing them for a job they already had.
The junior phase is about safety, not answers
With a new or junior engineer, the temptation is to make the meeting a technical clinic. Some of that is real and useful. But the actual job in the early phase is establishing that it is safe to not know things in front of you. If a junior engineer will tell you they're stuck on day two instead of day nine, you've saved a week of silent flailing, and you only get that if the meeting has taught them you won't punish confusion.
So early on I ask small, concrete questions and I answer them plainly. What are you working on, what's slow, what confused you this week, what did you Google three times. I want the confusion out loud. The worst junior 1-on-1 is the one where they say "everything's fine" for six weeks and then you find out during a code review that they've been quietly guessing at how our idempotency keys work in the settlement service. Fine is a word that hides things. Early on, my job is to make "fine" an unacceptable answer without making the person feel interrogated.
The mid-level shift: from what to how
The interesting turn happens somewhere around the point where an engineer stops needing help writing the code and starts needing help deciding which code to write. This is the mid-level phase, and it's where a lot of managers get lazy, because the person seems self-sufficient. They ship. They're fine. So the 1-on-1 drifts into a chat about nothing, or gets cancelled twice a month because "there's nothing urgent."
That's exactly backwards. This is the phase where the questions get harder and more valuable. The engineer can execute; now they need to learn judgment, and judgment is transmitted in conversation, not in code review. I start asking things like: of the three tasks in your sprint, which one actually matters and which one is busywork someone added? If you had to cut one, which and why? What did we build last quarter that you now think was a mistake? These are not status questions. They're the questions that turn a good coder into someone who owns outcomes.
The clearest signal that someone is ready for the next level isn't that they solve the problems you give them. It's that they start bringing you problems you didn't know you had.
The senior inversion: they set the agenda
With senior and staff engineers, the ownership of the meeting flips. I stop bringing an agenda at all, and if I have one I say so up front so it doesn't crowd out theirs. The default assumption becomes: you drive, I'll react. My value is no longer answers; it's context they can't see and obstacles they can't remove.
Concretely, the senior 1-on-1 tends to be one of a few things. Sometimes it's them thinking out loud about a design and using me as a wall to bounce off. Sometimes it's them flagging organizational rot I'm too far from the ground to notice, like two teams quietly rebuilding the same fraud-scoring logic because they don't talk. Sometimes it's them telling me a decision I made is wrong, which is the most useful version and the one I have to actively protect. The senior engineer who has stopped disagreeing with you in private is not a happy senior engineer. They've decided it isn't worth the effort, and that's the beginning of a resignation you won't see coming for six months.
The topics move from technical to human
There's a second axis of change that runs alongside seniority, and it's about what people worry about. Early-career worries are usually about competence: am I good enough, am I slow, did I break the thing. Later, once competence is settled, the worries become about meaning and direction. Am I still learning. Is this the right company. Do I want to manage or stay technical. Is my work visible to the people who decide promotions.
If you keep steering every 1-on-1 back to the ticket board, you never make room for the second set, and those are the ones that actually drive whether someone stays. I've lost exactly one person I'd have moved mountains to keep, and the postmortem was brutal: she'd been telling me for months, in her own coded way, that she wanted to move toward architecture, and I kept hearing it as a complaint about her current project and "fixing" the project. I solved the wrong problem three times before she gave up on me hearing the real one.
What actually changes, and how to notice
People rarely announce that they've grown. The 1-on-1 changes underneath you and you either adapt or you become the manager they've outgrown. A few signals I've learned to watch for, roughly in order of how much they should change your behavior:
- They answer your questions before you ask them, because they've started anticipating what you'd worry about. Stop asking those questions.
- They bring decisions instead of problems: "I'm going to do X, here's why, tell me if I'm wrong" rather than "what should I do about X?" Match their altitude and stop prescribing.
- They start caring about people other than themselves in the meeting: a teammate who's struggling, a process that's grinding the team down. That's a management or tech-lead instinct waking up. Feed it.
- They get bored. Boredom in a strong performer is almost always a signal that the meeting, and often the job, has stopped stretching them. Take it seriously before it turns into a LinkedIn update.
None of these are subtle once you're looking for them. The trap is that they arrive gradually, one good meeting at a time, and if you're not paying attention you keep running the old playbook out of habit long after it's stopped fitting the person in front of you.
Cadence should flex too, and mostly downward
I'm going to say something a little contrarian: most senior engineers are over-met, not under-met. A junior might genuinely benefit from twenty focused minutes twice a week early on. A staff engineer often does better with forty-five minutes every other week, plus a standing "grab me any time" that they actually use. Forcing a weekly slot on someone who has nothing to raise trains them to manufacture content, and manufactured 1-on-1 content is worse than no meeting.
The thing I won't cut is the meeting existing at all. I've seen managers "graduate" their best people off 1-on-1s entirely because "we talk all the time anyway." Then a hard conversation comes up, there's no established channel for it, and it gets had in a hallway or not at all. Keep the container even when it's mostly empty. Empty space in a trusted channel is where the important, uncomfortable stuff eventually shows up, usually about eight minutes after you thought the meeting was over.
The one thing that never changes
For all this talk of change, there's a constant, and it would be dishonest to skip it. Across every level, from the terrified first-week hire to the staff engineer who could probably do my job, the meeting is theirs, not mine. It's the one recurring block of time in the week that exists for their benefit and not the company's immediate output. The forms shift wildly. The ownership doesn't.
What changes is my role inside their meeting. Teacher, then sounding board, then peer, and eventually, if things go well, a person they update out of courtesy because they've largely surpassed the need. That last one stings a little and it's supposed to. If you're doing the job right, you are steadily making yourself less necessary to each individual, which is a strange thing to optimize for and the entire point of managing.
Conclusion
Here's the practical challenge I'd put to you, because I think it's more useful than any framework. Pull up your recurring 1-on-1s and, for each person, ask when the meeting last changed shape. Not the small talk, the substance. If someone's 1-on-1 has looked identical for a year, that's not stability, it's a signal you've stopped tracking who they've become. Go into the next one with no checklist and one honest question: what should this meeting be doing for you now that it wasn't doing a year ago? Then shut up and let them redesign it. The good ones will have an answer ready, and you'll wonder why you didn't ask sooner.