Remote engineers keep learning about decisions late. What norms fix this?

Written-by-default decisions (in a channel or doc the same day), remote-first meetings with shared notes, and a rule that decisions aren't final until everyone affected has seen them.

How do you handle a team split by a six-hour time difference?

Agree a few core overlap hours for synchronous work, rotate meeting times when overlap is small, and move status and routine updates to written, async formats.

Why should everyone join from their own laptop when one person is remote?

It gives remote participants the same experience — audio, visibility, chat and shared notes — so they're not second-class participants watching a room.

Leading Remote and Hybrid Teams — The Team Lead Handbook

Scenario

Example team: the checkout team has four engineers in one office and two remote engineers six hours ahead. Decisions happen in hallway conversations; remote engineers find out later in chat. Meetings are scheduled at the office's convenience — late evening for the remote pair.

What you see on the team

Remote engineers missing context and decisions.
Meetings at bad hours for part of the team.
A lot of synchronous meetings, little written documentation.
Remote people quieter in meetings and less visible for promotions.

The common mistake

Running a distributed team as if everyone were in the same room, with remote people joining an office-first process.

Why it happens

Office habits — quick chats, whiteboard sessions, decisions over lunch — feel efficient for those present. They silently exclude everyone else. GitLab, which operates fully remotely, publishes its all-remote guide, which emphasises written-first communication and asynchronous work as the foundation.

The playbook

Write things down by default: decisions, designs, meeting notes, status — in a place everyone can find. If it's not written, it wasn't decided.

Design for time zones:

agree core overlap hours (e.g. 2–3 hours a day) for synchronous work;
rotate meeting times if overlap is small;
use async for status (written standups) and keep meetings for discussion.

Remote-first meetings: if one person is remote, everyone joins from their own laptop; shared notes; agenda in advance.

Be deliberate about visibility: rotate presenting, give remote engineers high-visibility work, recognise contributions in writing.

Create connection on purpose: short social calls, occasional in-person meetups if possible, pairing across locations.

What to say

Setting the norm:

"From now on, decisions go in the team channel or the design doc within the day — even if we talked in the office. If Lee and Ana weren't part of it, it isn't final until they've seen it."

Meeting rule:

"If anyone's remote, we all join from our own laptops. It's the only way the remote folks get the same meeting the rest of us do."

Trade-offs

Writing everything takes effort; it pays back in fewer repeated explanations and better onboarding.
Async slows some decisions; keep synchronous time for real discussions and urgent issues.
Rotating meeting times spreads the inconvenience fairly but can confuse; keep a clear calendar.

Signals it's working

Remote engineers know decisions as soon as office engineers do.
No one regularly attends meetings outside reasonable hours.
Written decision logs exist and are used.
Remote and office engineers have similar visibility and growth.

Key points

Write decisions and context down by default.
Agree core overlap hours; use async for status, sync for discussion.
Remote-first meetings: everyone on their own laptop, shared notes.
Actively balance visibility and recognition across locations.