What do you use one-to-ones for, how do you give feedback that lands, and where does your responsibility for someone's growth end?

The one-to-one belongs to them

The clearest signal in an answer to this question is what the candidate excludes. A one-to-one where you walk the ticket board is a status meeting with a smaller audience, and it wastes the only recurring slot you have for things that never surface in a stand-up: whether the work is interesting, whether they trust their teammates, what they are worried about, what they want next, and what you are getting wrong. Status has a home already — the board, the written update, the planning session. Protect the slot by refusing to use it for that, and say so on the first one.

Practical shape that holds up: weekly for thirty minutes as the default, biweekly for very senior people who prefer it, never monthly, because a monthly cadence lets a problem run four weeks before you hear about it. Never cancel it; move it. Cancelling communicates its priority more clearly than anything you say about caring. A shared document owned by them, with a rolling agenda you both add to during the week, solves the two commonest failures at once — they arrive with nothing, and neither of you remembers what was agreed last time.

A workable default structure, in this order deliberately:

Segment	Who leads	Purpose
Their topics	Them	Whatever they came with, first, so it is never squeezed out
Feedback both ways	You, then them	Small and current rather than saved up; ask for yours explicitly
Obstacles	Them	Things you can remove, decisions they are stuck behind
Direction	You	Context they cannot see: roadmap, org changes, why priorities moved
Growth	Alternating	Not every week; monthly, deliberately, with something concrete

Feedback that lands

Feedback fails for structural reasons far more often than emotional ones. Four properties do most of the work: it is specific to an observed event, it arrives close in time to that event, it separates the behaviour from its effect, and it ends with a request rather than a verdict. Removing any one of those is what produces feedback people nod at and ignore.

Compare a version that does not land with one that does.

"You need to work on your communication in reviews."

"In yesterday's review of the pricing change, you told Sam his approach was naive and moved on. I don't think you meant it as dismissive, but he stopped contributing for the rest of the session and came to me afterwards. What I'd like is that when you disagree with an approach, you say what specifically breaks — you're usually right, and the reason gets lost. Can we try that in Thursday's review?"

The second is longer and that is the point. It cites one event, it describes the effect without asserting intent, it acknowledges the substance was probably correct, and it makes an actionable request with a next occasion attached. It is also harder to argue with, because every clause is checkable.

Two rules about timing and setting. Deliver critical feedback privately, promptly, and in person where possible, and never save it for a review cycle, because feedback that arrives at review time reads as a case being built. Deliver positive feedback specifically and sometimes publicly, but be careful that praise in public is genuinely about work and not about visibility, or you will teach the team that being seen matters more than contributing.

And ask for feedback on yourself in a way that can produce an answer. "Any feedback for me?" reliably returns nothing. "What's one thing I could have handled better in the replatform decision?" returns something, because it is narrow, it names a specific episode, and it presumes there is an answer.

The division of labour on growth

The framing that survives scrutiny is that the engineer owns their growth and the manager owns the conditions for it. Concretely, they own the ambition, the effort, and the choice of direction — including the choice not to grow along the axis you would prefer. You own four things they cannot get themselves: work that stretches them, which is the only real development mechanism; honest signal about where they stand against the level they want; air cover when the stretch work goes wrong, which is the thing that makes stretching safe; and visibility of their contribution to the people who make decisions about them.

Both sides of that line get crossed. A manager who wants the promotion more than the engineer does ends up pushing someone towards a level they never asked for, and it ends in an exit. A manager who gives no honest signal and then delivers a disappointing cycle has withheld the one input the engineer needed.

Say the uncomfortable half plainly. Promotion is a lagging indicator of scope already being operated at, and it is constrained by calibration and headcount that you influence but do not control. So the honest commitment is not "I will get you promoted", it is "I will make sure you are working on things that build the case, I will tell you every time I see a gap, and I will not let the decision be made in a room where nobody knows what you did".

The failure that hides inside a good meeting

The subtle way this goes wrong is that the meeting is pleasant and empty. Both of you like each other, the half hour passes, nothing hard is said, and eighteen months later a difficult conversation arrives with no foundation under it. The tell is that you can go a quarter without either of you saying something the other did not want to hear.

Two habits work against it. Track the ratio of talking, and if you are speaking most of a one-to-one, you have converted their time into your broadcast. And learn to sit in silence after asking something real — the answer to "how are you finding the team at the moment" usually arrives second, after the polite version, and only if you do not fill the gap.