Skip to main content

How to one-on-one

6 min read
TL;DR: Stop using 1:1s for status updates. Prep async, focus on career growth, coaching, feedback, and human connection, and protect the time like it matters—because it does.
Table of contents

It’s Thursday afternoon. Your direct report sits down and reads from a list: “Closed three bugs, reviewed two PRs, started the migration doc.” You nod. They nod. Thirty minutes pass without either of you saying anything that couldn’t have been a comment on an issue.

Most 1:1s fail in one of three ways:

  • The most common: spending your team’s only protected synchronous time on information that belongs in writing.
  • The second: sugarcoating hard feedback until nobody walks away clear on what actually needs to change.
  • The third is quieter—the 1:1 that keeps getting canceled because “something came up,” until the relationship slowly starves.

What belongs in a 1:1#

Great 1:1s focus on topics that only work synchronously. Five keep coming up:

  • Career growth. “Should I chase the tech lead role or move toward management?” isn’t a question you resolve in an issue comment. It needs back-and-forth, and half the signal is in what your report doesn’t say out loud when you name each path.
  • Coaching. A report is stuck on how to push back on a staff engineer who keeps silently rewriting their PRs. There’s no doc to link them to—they need to talk it through with someone who has the context and no stake in the outcome.
  • Feedback. “Your design review comments are landing as combative” reads like an ambush in Slack and like a favor across a table. The pause where they react, and your chance to say “that came out wrong, here’s what I meant,” is the entire point.
  • Human connection. “How are you actually doing?”—and then sitting through the silence that follows. Remote work strips out the hallway read on whether someone’s thriving or quietly burning out. The 1:1 is where you get it back.
  • Clearing the air. The passive-aggressive thread that’s been simmering all week gets defused in four minutes of talking, or festers for another month in writing. Pick up the phone.

What doesn’t belong: status updates, information transfer, and approval requests. If you’re listing what you shipped last week, you’re wasting the meeting. (share this quote) Your manager should see your work before the 1:1, not hear about it during. Approvals create bottlenecks—ask async. Information sharing belongs in a doc sent beforehand. Use synchronous time to discuss implications, not convey facts.

How to prepare#

Great 1:1s start before the meeting does.

Keep a running shared agenda—a Google Doc, a GitHub issue, whatever works—where both parties add topics throughout the week. When something comes up worth discussing, add it immediately instead of trying to remember later.

Add context to each item. Don’t just write “career growth”—write “I’ve been thinking about whether to pursue the tech lead path or people management, and I’d like to talk through the tradeoffs.” The more context upfront, the more productive the conversation. Prioritize ruthlessly—you won’t cover everything every week, and if something keeps rolling without getting discussed, that tells you something about its actual importance.

A good test of your preparation: could you cancel the meeting without losing anything? (share this quote) If yes, you either don’t have enough prepared or you’re covering topics better handled async.

How to run one#

Start with the human, not the agenda. Take a few minutes to check in personally. This isn’t small talk—it’s the relationship that makes hard conversations possible later.

Ask questions more than you give answers. For managers, your job isn’t to solve every problem—it’s to help your report think through problems themselves. “What options are you considering?” is often more useful than “Here’s what you should do.” For ICs, don’t just wait to be told what to do—challenge assumptions and push back.

Follow the agenda, but hold it loosely. If a topic opens up a more important conversation, follow it. The rest can wait.

Make space for what’s unsaid. The most important topics often aren’t on the agenda because they’re hard to articulate or feel risky to raise. Make it safe by raising difficult topics yourself and responding non-defensively when others do.

End with clear next steps. What actions came out of this? Who’s doing what by when? Document them somewhere durable so they don’t get lost. Leaders who show their work in shared docs make this easy—the same transparency that helps distributed teams function day-to-day makes 1:1 follow-through automatic.

Skip-levels: why they matter#

Skip-level 1:1s—regular conversations with your manager’s manager—build rapport and broader perspective. They’re typically less frequent (monthly or quarterly), but they matter for career visibility and organizational context. They give senior leaders unfiltered signal about how the team is actually doing, and they give ICs a line of sight into strategy they wouldn’t otherwise have.

Anti-patterns to avoid#

  • The ghost meeting. Neither party prepares, there’s no agenda, and you spend thirty minutes in a conversational holding pattern. If you have nothing to discuss, either something is going well or something is going unaddressed—figure out which.
  • The cancellation cascade. 1:1s keep getting canceled because “something came up.” That signals the relationship isn’t a priority. Protect the time, especially for remote relationships where it’s harder to connect informally.
  • The manager monologue. The manager talks the whole time, sharing information, giving advice, or thinking out loud. 1:1s should be conversations, not presentations.
  • The reverse 1:1. The entire meeting becomes the report briefing the manager on the work. If your report is educating you for thirty minutes, you owe them a different format, not a recurring appointment.

The real test#

Your 1:1s are a microcosm of how you lead. Shared agendas, documented outcomes, async preparation—every practice that makes a 1:1 great is the same practice that makes a distributed team work. If you manage like an engineer, you already have the instincts: treat the meeting like a system, instrument it, and iterate.

Get the 1:1 right and the rest follows.

Originally published April 27, 2026 View revision history
Share

More to explore

AI-first program management

11 min read

AI-augmented program management is the natural evolution of async-first and engineering-inspired workflows — amplifying human judgment, not replacing it.

The brag doc

5 min read

Why you need a running record of your wins—and how to keep one without dying of embarrassment

Eight tips for working remotely

10 min read

Tools alone won't make remote work succeed. Eight cultural rules for effective async communication, regardless of your industry or role.

15 rules for communicating at GitHub

16 min read

How GitHub uses issues and chat for async communication — fifteen rules that eliminate the 'you had to be there' problem in corporate workflows.

Open and Async: the remote-work playbook is out

3 min read

Open and Async is the practical playbook for making remote and distributed work actually work—two habits, working in the open and communicating asynchronously, drawn from a decade of remote-first lessons at GitHub.

Work loudly

6 min read

In an office, some of your visibility is free. Go remote and it drops to zero. Working loudly makes your impact visible as you do it—not after the fact in a status update nobody reads.

Leaders show their work

10 min read

Great leaders don't just communicate decisions—they explain how and why. Without that context, every decision sounds like "because I said so."

Ben Balter

I'm Ben Balter — I write here about engineering leadership, open source, and showing your work. I wrote Open & Async, the playbook for remote and distributed teams. My open source projects have hundreds of millions of downloads. I was the Director of Hubber Enablement at GitHub, where I helped thousands of GitHubbers do their best remote work. Before this role: Chief of Staff for Security, enterprise PM, and GitHub's first Government Evangelist. Before GitHub: attorney, Presidential Innovation Fellow, and member of the White House's first agile development team. More about the author →

Follow along: Bluesky LinkedIn

This page is open source Help improve this article on GitHub