Remote-first that actually works

When decisions live in someone's memory or a meeting nobody recorded, half the team is permanently out of the loop. Writing things down, decisions, context, and the reasoning behind them, is the foundation of remote work.

Good written docs also scale across time zones in a way meetings never can. Someone five hours behind can catch up without waiting for you to wake up. We keep a short decision log per project: date, what was decided, why, and what was rejected. It takes two minutes and saves hours of 'wait, why did we do it this way?'

The test: if a new person joined tomorrow, could they understand the last month of the project from the written record alone?

Engineering and design need long, uninterrupted stretches. A calendar shredded into back-to-back calls is the fastest way to kill the very productivity remote work promises.

The rules that hold:

• A small window of core overlap hours, we aim for about four, when everyone is reachable. Outside it, asynchronous is the default and nobody is expected to reply immediately.
• Meetings need an agenda and a purpose in the invite, or they get declined. Default length 30 minutes, not 60.
• No-meeting blocks that everyone respects, so there is a reliable stretch each day for focused work.
• Recordings and notes for every meeting, so missing one is a catch-up, not a gap.

In an office, context leaks naturally through overheard conversations. Remotely, it has to be shared on purpose, or people optimize for the wrong thing in good faith.

That means posting the 'why' behind a change, not just the 'what'; sharing a rough direction early rather than a polished conclusion late; and narrating your work in a shared channel enough that a teammate could pick it up if you were out sick.

Saying why a little too often is far cheaper than discovering a week of work pointed in the wrong direction.

Remote onboarding exposes every gap in your written record. If a new hire is productive in their first week, your documentation and setup are healthy. If it takes a month and a lot of synchronous hand-holding, that is a signal about the whole team's day-to-day, not just onboarding.

We give every new person a first-week task that touches the real system end to end, a written runbook to get the environment working, and a named buddy for the questions that are faster asked than looked up.

Then we ask them, two weeks in, what was confusing, and fix the docs. They will never see it with fresh eyes again.

Remote work falls apart the moment it turns into surveillance. Measuring hours online instead of outcomes shipped breeds exactly the behavior you do not want: people performing availability instead of doing the work.

We hire people we trust, give them real ownership of a problem, and judge the work, not the activity. Status is visible through the work itself, pull requests, demos, the decision log, not through a green dot.

That trust is what makes the flexibility actually worth something, and it is the hardest thing to rebuild once it is gone.

The warning signs are consistent: meetings creeping back to fill the calendar, decisions that only exist in chat threads nobody can find, the same context explained three times in three DMs, a new hire still lost after three weeks, and people online at odd hours to prove they are working.

When you see two or three of those, the fix is not a new tool. It is going back to the basics: write the decision down, cut the meeting, share the context in the open, and judge the output.

Remote-first done well is quieter and calmer than an office. If it feels busier, something is off.

Remote teams lose the ambient connection an office provides, so the connection has to be deliberate. A few low-cost rituals do most of the work: a weekly written update per person (what shipped, what is next, what is blocked), a short demo session where teams show real work, and a non-work channel that is actually used.

The demo is the highest-value one. Seeing what other people built keeps the work visible, surfaces overlap early, and gives quieter contributors a place to be recognised for output rather than presence.

Keep the rituals few. A calendar full of 'culture' meetings is its own kind of failure.

A team spread across more than about six hours of time zone difference cannot rely on overlap for coordination, and pretending otherwise leads to people working late to catch a call. Treat the spread as a constraint to design around: hand off work at the end of your day with enough written context that the next person can pick it up cold, and structure projects so parallel tracks do not block on a synchronous decision.

When a decision genuinely needs everyone, batch several into one well-prepared call rather than scattering them through the week.

Done well, a wide time-zone spread is an advantage: something is always moving. Done badly, it is just everyone tired.