How to Run 1:1s With Engineers (Cadence + Questions)

TL;DR: Status has cheaper channels than a 1:1. The meeting is the highest-bandwidth feedback loop you have with each engineer: where friction gets named while it's small, growth gets steered, and struggle surfaces before it compounds. Run it weekly or biweekly, 30 minutes, their agenda first, never cancelled. Prep with receipts from the actual work ("you waited three days on that review - is that normal?") instead of opening cold with "how's it going?"

Most bad 1:1s fail the same way: they become a verbal Jira sync. The manager extracts status, the engineer performs progress, both leave having learned nothing either couldn't have read on the board. Meanwhile the things a 1:1 exists to catch (friction, confusion, drift, ambition) stay unsaid, because nobody built a place for them to be said.

What a 1:1 is actually for

The research vocabulary helps here. The DevEx framework (Noda, Storey, Forsgren, Greiler) identifies three drivers of developer productivity: feedback loops, cognitive load, and flow state, and recommends pairing workflow data with perceptions, because half of what matters is invisible from the outside. The SPACE paper makes the same demand: measure across dimensions, and always include at least one perceptual measure.

Your 1:1 is the perceptual measure. Dashboards can show you a stuck PR; only the human can tell you the migration is dreaded, the on-call is corrosive, or the promised promotion conversation is six months overdue. A manager who reads dashboards but skips 1:1s has exactly half the picture - the less important half.

So the meeting's real jobs: surface friction early, exchange honest feedback in both directions, steer growth, and hand down context. Status is banned. Not because it's useless, but because it crowds out everything above and has cheaper channels.

Cadence, length, and the rules that matter

• Weekly or biweekly, 30 minutes, recurring, protected. Weekly for new hires, new-to-you reports, and anyone in a rough patch; biweekly is fine for stable senior engineers who'd rather have the focus time.
• Reschedule, never cancel. Cancelling teaches the engineer the meeting is optional, and the topics that need psychological safety are precisely the ones people won't hold for two more weeks. They just evaporate.
• Their agenda first. A shared running doc both of you can add to during the week. Whatever they wrote goes first; your items wait.
• Private and unhurried. Not a walk past the team's desks, not the last five minutes before their next meeting.

Questions that get past "fine"

"How's it going?" produces "fine" from anyone with a functioning self-preservation instinct. Specific questions produce information:

Friction and blockers

• "What was the most frustrating part of your week?"
• "What are you waiting on right now?" (then actually go look at the review queue they mention)
• "If you could delete one recurring meeting or duty, which one?"
• "Where did you lose the most time to interruptions?" - worth asking explicitly, because the Parnin & Rugaber study of 10,000+ programming sessions found roughly 30 percent of interrupted sessions take more than half an hour to get back to editing code. A meeting-shredded calendar is a productivity problem the engineer often blames on themselves.

Growth

• "What do you want to be doing more of in six months?"
• "What's something you did recently that you're proud of and nobody noticed?" (this question finds glue work, the invisible and career-limiting kind, more reliably than any metric)

The relationship (the hard ones that earn trust)

• "What's one thing I could do differently that would make your work easier?"
• "Is there feedback you've been sitting on because there wasn't a good moment?"

The struggle check, when the work suggests it

• "Walk me through what a day on this task actually looks like." - the gentlest reliable way to find out whether someone is struggling and hiding it.

Prep: bring receipts, not suspicions

Ten minutes before each 1:1, look at the person's actual week. Not to audit them, but so your questions land on something real:

• Did their PRs sit waiting for review? Then open with "you waited three days on the payments PR - is that typical?" You'll learn more in one answer than in a month of "how's it going."
• Is their review load way above the team's? Ask how it feels before it becomes a burnout ingredient.
• Are they deep in territory nobody else knows? That's a bus-factor conversation and a growth conversation at once.

The direction matters enormously: data arrives as curiosity about the system ("what's in your way?"), never as evidence against the person ("your numbers dipped"). The first builds trust; the second guarantees you'll never hear the truth in that room again. It's the same line that separates insight from surveillance in detecting anything at all from engineering data.

The five classic 1:1 mistakes

1. Status extraction. If the meeting could be replaced by reading the board, it just was.
2. Cancelling when busy. Busy weeks are when 1:1s carry the most signal.
3. Doing all the talking. Aim for the engineer talking most of the meeting; silence after a question is them deciding whether to trust you - don't rescue it.
4. Saving feedback for the review. The no-surprises rule: if it's news in the performance review, you failed it in twelve earlier 1:1s. New managers inherit this mistake most often; the new engineering manager checklist exists to break it early.
5. Bringing a dashboard as a verdict. Receipts open questions; scores close them.

A template that survives contact with reality

A shared doc per person, newest week on top. Four headings: Theirs (their items, first) · Mine (feedback, context, coaching - small and often) · Growth (the six-month thread you revisit monthly so it doesn't dissolve into urgency) · Actions (who does what by when, reviewed at the top of the next 1:1, because unkept 1:1 promises teach reports to stop bringing problems).

Where Busfactor fits

Busfactor's job in your 1:1 is the ten minutes of prep, done for you and framed the right way: what this person waited on, what load concentrated on them, where they're the only one who knows an area, what deserves genuine praise - receipts and hypotheses, in system language, never scores. Per-person scorecards describe strengths, growth areas, and what the org would lose without them; there is deliberately no ranking, no composite grade, and no comparison ladder, so the meeting stays a conversation between two people, with the facts on the table and the verdicts left outside.