How to manage a remote engineering team effectively
How to manage a remote engineering team effectively
To manage a remote engineering team effectively, flip async to the default, write decisions instead of meeting about them, measure shipped output instead of hours online, and run a tight weekly cadence: one 1:1, one retro, one planning block. The tools (Notion, Linear, Slack, Cal.com, Loom, GitHub) follow the defaults. They do not create them.
Most teams that say they "do async" actually run hybrid: meetings on the calendar, Slack as a typed Zoom, decisions made in DMs. That works on a co-located team because hallway repair is free. On a remote team, every coordination gap has to be paid for in writing, in process, or in burnout. This post is the operational version of that pay-for-it-in-writing approach.
Async-first as the default, not the aspiration
Async-first means meetings are the exception, not the cadence. The test is simple: for every recurring meeting on your team's calendar, can you point to a written artifact that does the same job? If yes, kill the meeting. If no, the meeting is doing real work and stays.
Most engineering teams pass this test for two meetings (the weekly 1:1 and the planning sync) and fail it for everything else. Standup, design review, "team sync," "engineering all-hands," weekly demo: most of those can be replaced by a Loom + Notion doc + Linear ticket combination, with comments threaded on the artifact instead of spoken into the air.
A practical rule: protect three to four hours of timezone overlap per day for the small set of conversations that genuinely need real-time bandwidth. Ship the rest in writing. Engineers who are fluent with Cursor and Claude Code do not need a senior nearby to unblock; they unblock themselves and post the decision in the ticket.
The written decision-record habit
Decisions are the part remote teams lose first. A choice gets made in a DM between two engineers, the third engineer ships against the old assumption, and you find out two weeks later in a code review.
Fix this with one habit: every non-trivial technical decision lives in a single document, linked from the Linear ticket. The template is small.
Decision: <one sentence>
Context: <2-3 sentences on the problem and constraints>
Options considered: <bulleted list, one line each>
Choice: <which option, and why>
Owner: <one name>
Reversible? <yes / no, and what would change that>
Three minutes to write. Saves three days of confusion. Notion is fine for the doc, Linear is fine for the binding to scope; the format matters more than the surface. The rule is non-negotiable: if a decision is not in a document, it did not happen, and the team will revisit it.
The weekly cadence: 1:1, retro, planning
A working remote engineering cadence is small enough to fit in a sentence. One weekly 1:1 with each direct report, one weekly team retro, one weekly planning block. That is it.
The 1:1 is the only sync you should be willing to defend on the calendar against any other use of the time. Thirty minutes, weekly, no skipping. Gallup's span-of-control work points at five to seven direct reports as the cap for meaningful weekly 1:1s; eight to ten can work if you have strong tech leads doing code-level mentorship under you. Beyond ten, you are not managing, you are taking attendance.
The retro is thirty minutes async (a Notion doc anyone can drop notes into during the week, surfaced Friday morning) and fifteen minutes sync to land action items. Owners and dates on every action item, or it is decoration.
The planning block lands the next week's scope before Friday close. Linear cycle planning works for this. The goal is that everyone knows what they are shipping by Monday morning local time, with the docs already linked.
Measure output, not hours: the no-time-tracking principle
Time tracking is a co-located management tool that survived the office, badly. Hours predict nothing useful about engineering output. A senior engineer can ship a week's worth of value in a Tuesday afternoon; a junior can sit in the editor for fifty hours and produce a regression.
The principle: do not track engineer hours. Track shipped output and review weekly. The DORA metrics (lead time for changes, deployment frequency, change failure rate, mean time to recovery) tell you more in fifteen minutes than a timesheet does in a quarter. Pair those with a per-engineer "what shipped this week" written status, and you have a defensible performance signal that does not require surveillance.
This is also how the Cadence platform pays engineers. Every engineer earns 80% of the weekly rate (junior $500, mid $1,000, senior $1,500, lead $2,000), invoiced Friday for the week's shipped work, with no timesheets. The accountability comes from the daily founder rating and the option to replace the engineer the following week, not from clock-watching. The pattern works the same on a salaried in-house team: outcomes weekly, replacement fast and non-punitive.
On-call done well in a distributed team
Distributed teams should be the easiest place to run on-call, because you have humans awake in different timezones for free. Most teams squander that and put their senior engineer on permanent night shift instead.
The pattern that works:
| Practice | Default | What "good" looks like |
|---|---|---|
| Rotation | one primary, one secondary, weekly handoff | follow-the-sun where headcount allows |
| Tooling | PagerDuty (or Opsgenie) into Slack + Linear | every page has an incident ticket |
| Postmortem | blameless, single owner, 7-day deadline | linked from the affected service's runbook |
| Compensation | comp time or rate uplift | written into the offer, not improvised |
The trap to avoid: do not let on-call become "whoever responds first in Slack." That defaults to the most anxious person on the team and burns them out in two quarters.
Remote performance reviews that hold up
A remote performance review is only as good as the goals you wrote down at the start of the period. If you set them in a quarterly Notion doc and reviewed them at the weekly 1:1, the review writes itself. If you did not, you are reconstructing six months of memory under pressure, which is how bias gets baked in.
The structure that works:
- Quarterly written goals, two to four max, with a measurable definition of done.
- Weekly 1:1 references the goals; drift gets named the week it shows up.
- Peer feedback solicited in writing two weeks before the review (three peers, three prompts each).
- Manager writes the review against the artifact: shipped work, peer feedback, goal status. Not vibes.
The review meeting itself is the smallest part. The work is the year-round paper trail, which is also why this is easier in remote teams than in offices: you already have the artifacts, because async-first forced you to.
Equity of information across timezones
The biggest hidden cost of a distributed team is information asymmetry. The people in the headquarters timezone find out things first; the people six hours out find out from a Slack scrollback if they're lucky. Over a quarter, the gap compounds into a different team having a different mental model of the product.
Three rules close most of the gap:
- Channels over DMs. Hard rule: any conversation that involves a decision, an architectural opinion, or a piece of context anyone else would benefit from goes in a public channel. DMs are for "is your kid sick" and salary numbers.
- Record-and-summarize for any sync that includes someone in the overlap window and someone outside it. Loom or a recorded Zoom plus a three-bullet text summary in the channel within 24 hours.
- All-hands and town halls go out as a Loom, not a meeting. The "live" version is for questions only and runs on rotation across timezones.
When you put these in writing as team norms, the equity problem mostly solves itself in a quarter. When you don't, you import the office's worst habit (the in-room conversation that never makes it to the rest of the team) into a remote team that has no chance of overhearing it. If you want to dig deeper into the chat side specifically, our breakdown of Slack vs Teams for engineering goes into how channel discipline differs between the two.
The toolchain that actually holds it together
Tools follow defaults; they do not set them. That said, the stack matters because the wrong stack actively rewards the wrong defaults (Microsoft Teams' DM-first UX is a classic example).
| Tool | Job | Why this one | Cost (typical) |
|---|---|---|---|
| Notion | docs, decision records, runbooks | block-level linking, search that works | $10/seat/month |
| Linear | tickets, cycles, project planning | fast, opinionated, scriptable | $8-14/seat/month |
| Slack | channel-first chat, alerts | best ecosystem, search depth | $7-15/seat/month |
| Cal.com | scheduling across timezones | open source, no Calendly lock-in | $12/seat/month |
| Loom | async video for context handoffs | transcripts and time-stamped comments | $8/seat/month |
| GitHub | code, PRs, actions | the default with the deepest CI/CD ecosystem | $4-21/seat/month |
Total lands around $30 to $50 per engineer per month for the full stack. That is the price of replacing five recurring meetings. For a wider review, our tools for remote dev teams post covers alternatives in each slot, and our home office setup guide for remote engineers covers the hardware side that the SaaS bill does not.
One job per tool. Do not put product specs in Linear and Notion both. Do not run two chat tools. Every overlap is a place where the team has to remember which copy is canonical.
Anti-patterns that quietly kill remote teams
The mistakes that break remote engineering teams are rarely loud. They look reasonable on a Tuesday and corrosive over six months.
- Slack DM as the default channel. Decisions vanish into one-to-one threads. New joiners can't catch up. The fix is a written team norm, posted in the #general channel, that says "default to public channels; DMs are for personal stuff." Enforce by example: as the manager, never decide anything important in a DM.
- Perma-meeting calendars. A team where every engineer has four hours of meetings a day is not a remote team, it is a co-located team that outsourced its rent. Audit the calendar quarterly: any recurring meeting that has not produced a decision in the last month is dead weight.
- Tracking butts-in-seats via online indicators. Slack's green dot is not a productivity metric. Engineers learn within a week to wiggle the mouse. The behavior you measure is the behavior you get; measure shipped artifacts instead.
- One person in HQ as the central node. Everyone else routes information through them. They become the bottleneck and the single point of failure. Split that role explicitly into "tech lead" (technical decisions) and "delivery lead" (sequencing and unblocking) and write the boundaries down.
- Standups that survived WFH unchanged. A 9:30 daily standup that worked in an office becomes a 9:30 daily Zoom that pulls everyone out of focus. Replace it with a written status by a fixed local time and watch what happens to deep work.
McKinsey's research on distributed teams flags up to a 30% productivity drop when these patterns compound. The drop is recoverable, but only if you treat operating model as a first-class artifact, not a vibe.
What to do this week
Three concrete moves you can finish before Friday.
- Audit one recurring meeting. Pick the one with the lowest decision-density. Either kill it or replace it with a written artifact and a comment thread. One per week, for a quarter, and your team's calendar will look different.
- Publish the decision-record template. Drop the seven-line template above into a Notion page, link it in #engineering, and start linking real decisions from your Linear tickets this sprint. New decisions only; do not retro-fit history.
- Set the weekly cadence in writing. 1:1 cadence, retro day, planning block. Post it in the team handbook. Stop scheduling around it; let the rest of the calendar negotiate.
If you are running a small team and don't yet have the bench depth to absorb a hire, this is also where booking a vetted engineer by the week earns its keep. On Cadence, every engineer is AI-native by default (vetted on Cursor, Claude Code, and Copilot fluency before they unlock bookings), and the weekly billing model maps cleanly onto the cadence above: ship something useful by Friday or replace next week, no notice period.
Hiring slot to fill on a remote team? Find your remote engineer in 2 minutes on Cadence. 48-hour free trial, weekly billing, daily ratings, and the same async-first norms baked into the platform.
FAQ
How many direct reports should a remote engineering manager have?
Five to seven if you want meaningful weekly 1:1s. Eight to ten can work if you have strong tech leads handling code-level mentorship under you; beyond ten, you are taking attendance, not managing.
Should I track hours for remote engineers?
No. Track shipped output and review weekly. Hours track presence, and presence is not the product. Use DORA metrics (lead time, deploy frequency, change failure rate, MTTR) plus a weekly written status of what shipped.
What is the minimum timezone overlap that works?
Three to four hours of shared working time covers most planning, code review, and 1:1 needs. Below two hours of overlap, your async maturity has to be very high (decision records, Looms, written status) or coordination breaks down.
How do I run async standups without losing visibility?
Replace the meeting with a written status posted to a public channel by a fixed local time each weekday. Three lines per person: shipped yesterday, shipping today, blocked on. Searchable, recoverable, and timezone-friendly.
How often should remote engineering teams retro?
Weekly. Thirty minutes async to gather notes during the week, fifteen minutes sync on Friday to land action items with named owners and dates. Quarterly retros are too late to fix anything that is breaking now.