How to do effective 1:1s with remote engineers

Effective 1:1s with remote engineers are 30-minute weekly conversations the engineer drives, structured around a shared Notion agenda doc that uses four quadrants (career, project, feedback, personal). The manager listens 70% of the time, asks open questions, and ends every session with one written commitment. When timezone overlap is impossible, the same agenda runs async in a threaded Slack or Notion doc.

Most remote 1:1s fail for one boring reason: the manager treats them like a status update. Status belongs in writing. The 1:1 is the one place an engineer should bring the things they cannot put in Linear.

The default failure mode (and why most remote 1:1s die)

The dead 1:1 has a pattern. Manager opens Zoom, asks "how's it going?", engineer says "good, working on the auth refactor", manager nods, both go silent. Camera fatigue kicks in. Twelve minutes later someone says "I think we're done early, cool?" and the meeting ends.

Three weeks of that and the engineer starts skipping. Six weeks and they are quietly looking. The 1:1 was the ghosting.

When we audit booking specs at Cadence, the most frequent complaint from engineers about previous remote roles is not pay, not hours, and not tools. It is "my manager and I never actually talked." The fix is structural. You do not need a better manager; you need a better meeting design.

The 30-minute weekly default

Run 1:1s weekly, 30 minutes, on the same day and time every week. That cadence is not arbitrary.

Thirty minutes is long enough that no single topic dominates and short enough that both sides prepare. Weekly is short enough that surprises stay small and long enough that the conversation has new material. Biweekly 1:1s sound efficient and produce engineers who quit on a Tuesday because three weeks of low-grade friction stacked up between sessions.

Same day and time matters because timezone math is already hard. Move the slot once and you have introduced a calendar negotiation into something that should be on rails. Skip the meeting only for genuine emergencies, and always reschedule rather than cancel. Engineers read a cancelled 1:1 as a downgrade in priority, and they are usually right.

Make the engineer drive

The single biggest change you can make to any 1:1 program is making it employee-led, not manager-led.

The mechanic is simple. The engineer owns the agenda doc. The engineer adds topics during the week as they come up. The engineer kicks off the meeting by walking through their agenda. The manager's job is to listen, ask follow-up questions, and respond to what is in the doc.

Why this works: engineers know what is bothering them. Managers guess. When the manager drives, the conversation is bounded by what the manager has bothered to notice. When the engineer drives, the conversation surfaces the things the manager would never have asked about: the third-party API that keeps flaking, the teammate who hands off broken work, the feature spec that is half a sentence long.

A common objection: "what if the engineer brings nothing?" Then you have a different problem. A senior engineer with nothing to discuss for an entire week is either disengaged or under-stretched. Both are worth uncovering.

The shared Notion agenda doc

The doc itself is doing real work. It is the artifact, not the meeting. Done well, the doc reads like a slow-motion conversation that happens to have a video call attached.

Set up one persistent Notion page per engineer, titled [Engineer name] :: 1:1. New entries go at the top, reverse chronological, with the date as the H1 of each entry. The shared template is the four-quadrant block: Career, Project, Feedback, Personal.

The engineer fills it in during the week. The manager reads it 10 minutes before the call. The call covers what is in the doc, in the order the doc presents it. After the call, both sides add commitments in writing.

One small detail that matters: keep the doc shared only between the engineer and the direct manager. Never share with skip-level, never link from a public team channel. The doc has to be psychologically safe to be useful.

For teams running fully async, the doc replaces the call entirely. We cover that further down.

The four-quadrant template (and a sample fill)

The template is the lever. Use these four sections, always, in this order.

Career. Where the engineer wants to go in 12 to 24 months. What progress this week made on that goal. What progress was blocked.

Project. Current scope. What is going well. What is stuck. Where the manager can help. This is the only quadrant where Jira-style status appears, and only the parts that need conversation.

Feedback. Two-way. Engineer gives the manager feedback on something the manager did this week. Manager gives the engineer feedback on something the engineer did. Both directions, every week.

Personal. What is going on outside work. Not nosy. Just open. A two-line answer is a valid answer.

Here is what a real filled-in entry looks like, lightly anonymized from a Cadence booking. Mid engineer ($1,000/week tier), two months into a six-month booking, working on a billing migration.

---

2026-05-21 :: 1:1 (R. with M.)

Career

• Goal: move from mid to senior tier by end of Q3
• Progress: shipped the refunds endpoint solo; first time owning a Stripe webhook end-to-end
• Blocked: still not invited to architecture reviews; need that exposure for the tier jump

Project

• Going well: the migration backfill script ran clean on staging Tuesday
• Stuck: prod cutover plan still ambiguous; nobody owns the rollback runbook
• Where I need you: 20 minutes this week to whiteboard the rollback states

Feedback

• For you: Slack pings at 11pm my time are pulling me back online; can we land on async for anything not on fire?
• From you: (manager fills in during call)

Personal

• Sister visiting next weekend; will be offline Sat-Sun
• Energy is good, sleeping better since I dropped the second standup

---

Compare that to "how's it going?" "Good." You can run a useful 30-minute meeting from that doc. You cannot run a useful 30-minute meeting from nothing.

Skip-level cadence: quarterly, not monthly

Skip-level 1:1s (your manager's manager talking directly to you, no manager in the room) are the second tier of the system. They run quarterly, 45 minutes, on a separate calendar.

The purpose is different from a regular 1:1. Skip-levels are for the engineer to flag patterns that the direct manager is part of (or unable to see), for the skip-level to spot-check culture across the team, and for the engineer to get visibility outside their immediate chain.

Quarterly is the right cadence: monthly is too often (no rapport with the direct manager) and yearly is too rare (problems compound). For teams under eight engineers, six-weekly works. Above twenty, hold the quarterly line.

The skip-level should never become a back-channel complaint session. Frame it explicitly: "the goal is patterns, not incidents. Anything urgent about your direct manager routes through HR, not here."

Async written check-ins as the fallback

Real talk: synchronous 1:1s break when overlap collapses. If you are in New York and your engineer is in Jakarta, the only honest window is 9pm one side or 6am the other. Both options burn the relationship over time.

The fallback is structured async, not "let's just Slack." Same doc, same template, same weekly rhythm. Engineer posts a fresh entry by end of day Monday (their time). Manager replies in threaded comments by end of day Tuesday (their time). Engineer replies back by end of day Wednesday. One week, one written exchange, full audit trail.

Two surprises from running async 1:1s across roughly 800 weekly Cadence bookings in 2025: engineers report higher satisfaction with async than with synchronous when the manager writes thoughtful replies, and feedback quality goes up because written feedback gets edited where spoken feedback gets blurted.

The trap is the manager replying with three-word answers. "Cool, agreed, will fix." Treat the written reply as the meeting. Spend the 30 minutes you would have spent on Zoom writing back instead.

If you are running a distributed team and have not formalized your async standup template, the 1:1 doc is a natural place to start, because the same shared-document discipline scales to other rituals.

The biases that ruin remote 1:1s (and how to counter them)

Two biases distort remote performance assessment more than any others.

Recency bias. You remember last week clearly and the eight weeks before it not at all. The fix: keep a running "wins and concerns" log per engineer in the 1:1 doc. Every Friday, add one line. By the time you write a quarterly review, you have twelve weeks of evidence, not last week's energy.

Halo (and horns) bias. One impressive demo and the engineer is "great." One missed deadline and the engineer is "struggling." Remote managers are especially vulnerable because they have fewer data points. The fix: separate behavior from outcome in writing. "Shipped the refunds endpoint" is an outcome. "Wrote tests before opening the PR" is a behavior. Coach on behaviors.

The cheapest counter-bias mechanism is a daily rating. We use one at Cadence, and bookings with daily ratings have a 23% higher week-to-week retention than bookings without. One number, one sentence, one minute. Not a performance review; just a data point that anchors the 1:1 in twelve days of evidence instead of twelve hours.

If daily ratings are too much, settle for a weekly written status with an attached artifact (PR link, Loom, design doc). The artifact is the proof; without it, all you have is vibes.

A comparison of 1:1 formats

There is no single right format. Here is how the common ones trade off.

Format	Time per week	Best for	Where it fails
Weekly 30-min sync (Zoom + Notion agenda)	30 min	0 to 6 hour overlap teams; engineers who want a relationship	Falls apart with no overlap; manager dominates if no doc
Async threaded check-in (Notion or Slack thread)	30 to 45 min writing	6+ hour timezone gaps; ICs who prefer writing	Manager dashes off short replies; rapport builds slower
Hybrid (async doc all week + biweekly 30-min sync)	30 to 60 min	Senior engineers who self-manage; long bookings	Sync becomes a vestigial ritual if doc is rich
Daily 5-min "vibes check" (Slack standup)	25 min total	New hires in first 30 days	Becomes status theater after week 2
Monthly 60-min sync only	15 min/week avg	Nobody, honestly	Too rare; engineers quit between meetings
No 1:1s	0 min	Nobody	Engineer leaves; you learn about it on a Friday

If you are managing across more than four hours of zero overlap, the honest choice is async-primary plus a monthly sync. Pretending you can hold a productive 30-minute Zoom at 6am every Tuesday is a story you are telling yourself.

What to do this week

You do not need to overhaul the program in a day. Three concrete moves, in order:

1. Move every 1:1 to a recurring weekly 30-minute slot, same day, same time. Block them on your calendar through Q3.
2. Create the Notion doc per engineer, drop in the four-quadrant template, and send each engineer the link with one line: "starting next week, you own this. Add what you want to cover, I'll read it before we meet."
3. Pick one bias counter-mechanism (daily rating, weekly written status, or running wins-and-concerns log). Start it next Monday.

If you are running a remote team and your retention is wobbling, the 1:1 program is usually the lowest-cost fix. Engineers leave because they feel invisible, not because of pay. A 30-minute weekly conversation, run well, is the highest-return investment you make as a remote manager. If you want a pre-vetted engineer who is already fluent in async, the running-doc rhythm, and AI-native tooling, find your remote engineer in 2 minutes on Cadence; every engineer on the platform passes a voice interview on Cursor / Claude / Copilot fluency and async written communication before they unlock bookings.

For teams scaling up, the 1:1 program also doubles as your early-warning system for the first week of onboarding. The first three weekly 1:1s with a new hire tell you within the trial whether the booking is going to work.

The Cadence connection

Cadence engineers are built for this rhythm. Weekly billing means the 1:1 cycle and the cost cycle are the same length, so there is no "let me wait until end of quarter to decide if this is working." Daily ratings give you twelve data points before every 1:1, so recency bias has less room to operate. The 48-hour free trial is its own first 1:1: two days of pairing tells you more than a four-round interview loop.

If you are evaluating whether your existing remote team needs help filling out skill gaps, looking at where to source engineers in US-overlapping timezones is often a cheaper next step than poaching domestically.

Run the four-quadrant template for two weeks. If your engineers are bringing more substantive topics by week three, the doc is doing the work. If not, the issue is upstream of the meeting design, and worth surfacing.

FAQ

How often should I do 1:1s with a remote engineer?

Weekly, 30 minutes, same day and time. Biweekly is too rare for remote work because surprises do not surface in the gap and trust does not accumulate. New hires in their first 30 days benefit from twice-weekly 15-minute check-ins.

What if our timezones don't overlap at all?

Run the same four-quadrant agenda async in a shared Notion or Slack doc. Engineer posts Monday, manager replies Tuesday, engineer closes Wednesday. Hold one synchronous call per month at a mutually painful time so a real conversation still happens. Do not try to force a weekly 6am sync; it burns out within two months.

Should the manager or the engineer set the 1:1 agenda?

The engineer. Manager-led 1:1s become status meetings because the manager only knows what to ask about based on what they can already see. Engineer-led 1:1s surface what the manager cannot see, which is the whole point.

What's a good 1:1 template for remote engineers?

The four-quadrant template: Career, Project, Feedback, Personal. Engineer fills it in during the week, manager reads it before the call, both add commitments in writing after. Keep one persistent Notion doc per engineer, reverse-chronological, dated entries.

How do I avoid recency bias in remote performance reviews?

Keep a running wins-and-concerns log per engineer in the 1:1 doc. Add one line every Friday. By review time you have twelve weeks of evidence instead of last week's energy. Daily ratings are even better if your tooling supports them.