How to build a remote-first engineering culture
How to build a remote-first engineering culture
A remote-first engineering culture is one where the office is the exception, not the default. You build it by writing down seven things: a values doc, a hiring rubric, a week-one onboarding script, an all-hands cadence, a retro format, an offsite playbook, and a psychological safety contract. Everything else (tools, timezones, Slack norms) follows from those seven artifacts.
If your team needs a meeting to make a decision, you have a remote-tolerant culture, not a remote-first one. The difference is whether async is the path of least resistance or the path of most. Most "remote" engineering orgs are still hybrid in the muscle memory: one person in a timezone routes everything, decisions happen in Zoom, and onboarding is a person sitting next to a new hire (just over Zoom). A remote-first culture flips that. This post walks through the seven artifacts, with the actual scripts and cadences we use at Cadence, plus what we changed after watching them break.
The seven artifacts you actually write down
Here is the cheat sheet. The rest of the post unpacks each row.
| Artifact | Length | Owner | Re-reviewed |
|---|---|---|---|
| Remote-first values doc | 1 page | Founder | Annually |
| Hiring rubric (autonomy + writing + async empathy) | 2 pages | Eng lead | Quarterly |
| Week-one onboarding script | hour-by-hour | Manager + buddy | Per hire |
| All-hands cadence (monthly demo day) | 60 min agenda | Founder | Monthly |
| Retro format (team-level, async-completable) | 1 doc template | EM | Bi-weekly |
| Off-site playbook (frequency, duration, agenda) | 4 pages | Ops | Per offsite |
| Psychological safety contract | 1 page | Whole team | Quarterly |
If you only do one this quarter, write the values doc. The rest fall out of it.
1. The values doc (one page, founder-written)
The biggest mistake is treating "remote-first" as a logistics statement. It is a values statement. The values doc should answer five questions in plain language:
- What is the default mode of communication? (Async writing in a shared doc.)
- When are meetings allowed? (When a decision needs three people in a room and the doc has stalled twice.)
- What gets a same-day response, and what doesn't? (Production incidents and customer escalations, yes. Slack DMs, no.)
- What does it mean to "be at work" if no one can see you? (You shipped something visible today, or you wrote down what blocked you.)
- Who is allowed to schedule a meeting on your calendar without asking?
Read the GitLab handbook section on building culture for the long version of this; their ~3,500-word document is the most cited example for a reason. Then write your own in one page. Long values docs don't get read.
The doc lives in the same repo as your code, in culture/values.md. Engineers can PR changes to it. That is the loudest signal you can send that culture is not HR's problem.
2. Hiring for remote (autonomy, writing, async empathy)
Most engineering hiring loops test two things: can the candidate code, and is the candidate likeable. Neither predicts whether they will thrive in a remote-first team. The signals that do:
- Autonomy. Did they ship anything in their last role without a senior nearby? "I worked on the payments team" is not evidence. "I owned the Stripe migration end to end and here is the PR" is.
- Written communication. Their take-home write-up is more important than the code in it. If their PR descriptions are two sentences, they will be two sentences here too.
- Async empathy. In the interview, ask: "Walk me through the last decision you made that affected someone in another timezone. How did you communicate it?" If they say "we got on a call," that's a no.
- AI-native fluency. Every Cadence engineer is AI-native by default, vetted on Cursor, Claude Code, and Copilot in a founder-led voice interview before they unlock bookings. This matters culturally because engineers fluent in AI tooling don't need a senior nearby to unblock; they prompt their way out. That is what makes async actually work.
For more on the operational side of running the team after you hire, see how to manage a remote engineering team effectively.
The interview itself should be 60 minutes max, founder-led, voice over video. Cameras on, no slide deck. You're testing how the candidate thinks out loud, because that is what you'll be reading every day in their PRs.
3. The week-one onboarding script (hour by hour)
GitLab's data says structured knowledge sharing produces 64% faster onboarding. The way you operationalize that is a literal hour-by-hour script for week one. Here is the one we use at Cadence:
| Day | Block | Activity |
|---|---|---|
| Mon AM | 2h | Read the values doc, the hiring rubric, the last 4 weeks of demo-day Looms |
| Mon PM | 2h | Pair with buddy: get laptop, repo access, first commit (typo fix is fine) |
| Tue AM | 3h | Pair on a real ticket. Buddy drives, new hire watches, then swap |
| Tue PM | 2h | Read the last 10 PRs in the repo and comment on 3 |
| Wed AM | 4h | Solo on a small ticket. Buddy on call but doesn't initiate |
| Wed PM | 1h | First retro: what was unclear, what surprised you |
| Thu | full day | Solo work. Buddy is read-only |
| Fri AM | 2h | Demo day: new hire shows whatever they shipped (even small) |
The non-negotiables: a paid first day spent reading, a buddy who is not the manager, a real commit by end of day one, and a public demo by end of week one. The buddy is rotated quarterly so onboarding knowledge spreads. For the pairing rituals themselves, see our breakdown of pair programming remotely: tools and rituals that work.
4. The all-hands cadence (monthly demo day)
The default failure mode for remote all-hands is a CEO talking at a webcam for 45 minutes. Don't do that. Run a 60-minute monthly demo day instead.
Format:
- 5 min: founder shares one number that moved (revenue, retention, NPS) and one decision the company is making
- 40 min: 6 to 8 engineers each demo something they shipped, 5 minutes each, recorded
- 10 min: open Q&A, async questions submitted in advance
- 5 min: shoutouts (peer-nominated, posted in #shoutouts the week before)
Record everything. Post the Loom in the company repo. The recording is the meeting; the live event is for people who like live events. Anyone in any timezone can opt to watch the recording instead. That single rule (recording is the artifact) is what makes "all-hands" actually work for an all-remote team.
5. Retros that work in async (the format that actually closes the loop)
Most remote retros become Zoom calls where one person reads sticky notes aloud. That is hybrid theater. The async-completable version:
- Bi-weekly cadence, opened Monday, closed Friday
- Single shared doc with three columns: kept, drop, try
- Every team member adds entries by Wednesday EOD their timezone
- Manager threads on each item Thursday with: "owner, due date, or 'noted, no action'"
- Friday: 30 min synchronous call (recorded) for the 2-3 items that need debate
The doc is the artifact. The call is optional. If your retro requires the call to function, you don't have a remote-first retro; you have a meeting with a doc attached.
What makes this hard is the manager's job. Threading on every item by Thursday takes 90 minutes per cycle. That is the unglamorous work that actually builds the culture. Skip it twice and the team stops adding entries.
6. The off-site playbook (frequency, duration, what actually happens)
Honest answer about offsites: most teams underspend on them, and the ones who overspend usually overspend on production (custom hoodies, agency-run icebreakers) instead of time and travel.
The modal cadence that works for remote engineering teams: two offsites per year, four days each, full company. Optional team-level offsites once a year if the team is more than six people.
Cost benchmarks (two offsites a year, 20 people):
- Travel + lodging: $3,500 per person per offsite = $140,000/year
- Food and venue: $1,500 per person per offsite = $60,000/year
- Production and swag: $300 per person per offsite = $12,000/year
- Total: ~$210,000/year for a 20-person team
That is roughly 1.5% of payroll for a team of mid-level engineers. If that number scares you, you are not running a remote-first team; you are running a distributed team that will quietly drift toward an office.
What actually happens at the offsite matters more than where it is. Our format:
- Day 1: travel + casual dinner, no agenda
- Day 2: AM work session on the single biggest open question (roadmap, architecture, whatever), PM unstructured
- Day 3: AM team-level work, PM organized activity (cooking class, hike, escape room, whatever), evening team dinner
- Day 4: AM retro on the offsite itself, travel home
No keynotes. No external speakers. The point of the offsite is the unstructured time, not the agenda.
If you're hiring globally and worried about visa or travel logistics, the best EOR services for hiring international developers covers the operational side; bring your EOR provider into the offsite planning early because some country-of-record rules complicate cross-border travel reimbursement.
If you want a 4-vetted-engineer shortlist within 2 minutes (with a 48-hour free trial so you can pressure-test the async fit before committing), Cadence's onboarding flow is the fastest path. Every engineer is pre-vetted on async written communication, so the cultural fit work is mostly done before they show up in your Slack.
7. The psychological safety contract (one page, signed by the team)
Psychological safety is the dimension everyone talks about and almost no one operationalizes. The standard cite is that teams with high psychological safety show 43% higher deployment frequency and 65% faster mean time to recovery. True, but that is downstream of behaviors you have to spell out.
The contract has six lines. We literally write it on a one-pager and every new hire signs it in week two:
- We push back in writing, not in DMs.
- We disagree with the idea, not the person, and we name the disagreement explicitly.
- We do not interrupt in meetings; we use the queue (raise hand or thread).
- We blameless-postmortem every production incident within 48 hours.
- We assume good faith on the first read of any message; if it still feels off, we ask.
- We make it cheap to be wrong. Reverting a PR is not a failure.
The harder version of psychological safety in async is reading Slack messages and not assuming tone. Lines 5 and 6 do most of the work there.
What to do this week
Pick the artifact that is most broken and write it. If the answer is "all of them," start with the values doc; everything else cascades from it. Then book one calendar block per week for the next month to write the next four. Most teams never do this because no one has the time, and the result is a Slack-heavy hybrid that calls itself remote.
If you don't have an engineer to ship it with, every engineer on Cadence is async-default, AI-native, and bookable for a week at a time at $500 (junior), $1,000 (mid), $1,500 (senior), or $2,000 (lead) per week. Weekly billing means you can pressure-test the cultural fit in seven days, not in a 90-day notice period. Our engineering pool is 12,800 engineers and median time to first commit is 27 hours.
Try Cadence for one week. Find your remote-engineer match in 2 minutes, get a 48-hour free trial, replace any week with no notice. Async-fluent and AI-native by default. Get started.
FAQ
What's the difference between remote-first and remote-friendly?
Remote-first means async is the default and the office (if one exists) is optional. Remote-friendly means the team operates in-person and accommodates remote workers, who are usually treated as second-class. The test: if a decision happens in a hallway, you're remote-friendly, not remote-first.
How often should an all-remote engineering team meet in person?
Twice a year, four days each, is the modal cadence that works. Once a year is too thin to build trust; quarterly is too expensive and disrupts shipping. Budget 1-2% of payroll for offsites; that is what the math actually requires for a 20-person team.
How do you onboard an engineer remotely in week one?
Hour-by-hour script: paid reading day one, real commit by end of day one, paired ticket day two, solo ticket day three, public demo day five. Assign a buddy who is not the manager. Rotate buddies quarterly so onboarding knowledge spreads instead of bottlenecking.
What tools should we standardize on for a remote-first culture?
Linear for work, Slack for chat (with thread discipline), Loom for recorded explanations, Notion or a markdown repo for docs, Cursor or Claude Code for AI-pair coding, GitHub for code, Zoom for the rare synchronous call. The full breakdown is in our guide to the best tools for remote software development teams.
How do you measure performance when you can't see anyone?
Three signals: weekly written status with a shipped artifact attached, peer code review participation rate, and retro contributions. Daily ratings (the Cadence pattern) work for booked engineers; for full-time hires, weekly written status with a Loom demo attached is the standard that scales.
Does a remote-first culture work for early-stage startups?
Yes, and arguably better than for mature ones. Startups have less institutional muscle memory pulling them back to the office, and async hiring lets you reach engineers in any timezone in week one. The pattern that breaks: "we'll figure out culture later." You can't retrofit remote-first; write the values doc before your fifth hire.