Remote work, done well

Remote work is no longer a debate; it's a default for most software teams. The interesting question moved from "should we be remote?" to "why are some remote teams great and others mediocre?"

After 7 years in some shape of remote (a few companies, a few client teams), here's what I've found actually moves the needle.

What changes when you go remote#

Three things shift, and the rest follows from them:

1. Synchronous time becomes scarce. Meetings are now decisions, not coordination. Coordination has to happen in writing.
2. Context isn't free anymore. In an office, you absorb context by sitting near people. Remote, you have to ask for it explicitly.
3. Visibility becomes a choice, not a default. Your manager can't see you working. So what you produce — the artifacts, the comments, the docs — becomes how others know you exist.

Each of those points has a habit attached.

Habit 1 — write everything down#

Not "write more." Default to writing, fall back to talking.

The decisions:

You'll spend 20% more time writing. You'll save 200% in repeat conversations and lost context.

What "well-written" means at work:

• Decisions, not narrative. Lead with the conclusion. The reasoning is below the conclusion, not before it.
• Links to sources. Every claim about "this thing was decided last quarter" should link to the doc where it was decided. No links = no claim.
• Future-self mindset. Will I understand this in 6 months without context? Then it's good. Otherwise, expand.

A specific format I use for design docs:

# Title (a sentence describing what's being decided)

## Context
What is the situation? Two paragraphs.

## Decision
What we're going to do. One paragraph.

## Why
The 1-3 reasons that drive the decision. Bullet points OK.

## Trade-offs
What we're giving up. Be specific.

## Alternatives considered
Brief — *why we rejected these.*

## Implementation notes
Just enough to start. Not a full plan.

That's 90% of the design docs I've seen at well-run remote companies.

Habit 2 — make your work visible#

In an office, your boss sees you typing. In remote, they only see what you ship — if you make it shippable. The artifacts:

• End-of-week update. 3-5 bullets on what you finished + what's blocked + what's next. Posted in the team channel. Read by everyone.
• Demo on a recording. A 2-minute Loom of the feature you shipped. People watch these. They don't watch your standup updates.
• PR descriptions that explain why. Not "fixed bug." A paragraph explaining what was broken, why, and what changed.
• Decision logs. When you make a non-obvious technical call — pick library X, refactor Y, defer Z — write a paragraph in a shared doc. People link to these for years.

The unspoken rule of remote: you can do excellent work invisibly and still get a bad performance review. Make the work visible. The invisibility tax is real and unfair, and the only way to escape it is to write more.

Habit 3 — protect synchronous time#

Meetings remote are a finite resource. Spend them carefully.

Rules I push for on every team:

• Default to async. Anything that can be a doc, is a doc. Meetings are for things that can't.
• Agenda required. No agenda = no meeting. The agenda is two lines: what we'll decide, what people need to read first.
• 30 minutes max for status meetings, 60 for design. Most meetings can be 25 + 5 buffer.
• One meeting-free day per week. Pick one (Wednesday is popular). Defended by everyone.
• Recording by default. People who couldn't attend can catch up. Note: not for political/sensitive discussions.

The single best meeting habit I've adopted: a meeting starts with "what would success look like for this 30 minutes?" If we can't answer in 10 seconds, we end the call and convert to async.

The four-quadrant trap#

A model that helped me think about remote work productivity:

The trap most remote engineers fall into:

• Too much shallow async (Slack-watching) — feels productive, isn't
• Too few hours of deep work — the actual output bottleneck
• Meetings expanding to fill the time — Parkinson's law

If you find your hours skewing toward Slack and meetings, the fix is structural: block calendar slots for deep work, mute Slack channels you don't need, batch communication into 2-3 windows per day.

A loom of remote routines I've stolen#

I won't pretend I invented any of this. The good remote engineers I've worked with mostly have similar routines:

▶ GitLab's remote work playbook (overview)

(GitLab's remote work handbook is the reference text for industrial-scale remote work. Long, but has answers for almost every operational question.)

Common patterns I've adopted from people I admire:

1. First 30 minutes of the day = no meetings, no Slack. Read the most important PR, scan async updates, set the day's priority. This single habit was the biggest productivity unlock for me.
2. One async-only day. Wednesdays I've blocked from 10am–6pm. No meetings. Deep work only. Output that day is consistently 2-3× the rest of the week.
3. Walking 1:1s. When a 1:1 doesn't need a screen — career conversations, vibe-checks — I take them on a walk with my phone. The conversations are better. The endorphins help.
4. Public end-of-week note. Friday afternoon: 5-10 bullets in the team channel on what shipped, what didn't, what I'm carrying into next week. Takes 10 minutes. Has compounded into a useful personal log.

The loneliness pivot#

Same problem as freelancing: working alone is hard. Remote is less lonely than freelancing because you have a team — but the team is in your computer, and at the end of the day the laptop closes and you're in a kitchen alone.

Mitigations:

• Co-working space, even occasional. Once a week is enough. Different humans in your peripheral vision, even ones you don't talk to, calibrates your nervous system.
• A standing 1:1 with a peer outside your team. Doesn't have to be at your company. A trusted engineer you talk shop with for 30 min every two weeks.
• An offline community. Local meetups, a sport, a hobby with regulars. The relationships you make there are not work — and that's the point.
• In-person gatherings every quarter or two. If your company doesn't fund this, push for it. The week with your team in a room compounds the months apart.

What stops working remote#

Honest list of the friction points that drive engineers back to offices:

• Career stalls. If your manager defaults to promoting people they see daily, remote engineers get fewer reps. Fix: write more, demo more, push for face time at offsites, get a sponsor (not just a mentor).
• Burnout creep. No commute = no transition between work and life. Boundaries blur. Fix: hard stops (a calendar event called "off" at 6pm), end-of-day rituals (close laptop, walk), rooms reserved for specific contexts.
• Onboarding feels broken. Joining a remote team without good docs is genuinely hard. Fix: ask for a buddy, schedule learning hours, push back if there's no runbook.
• Vibe drift. You don't know what's going on at the company beyond your team. Fix: an all-hands you actually attend, casual cross-team Slack channels, occasional offsite.

If three or more of these are firing at once, your team is probably bad at remote, not remote-itself bad. Sometimes the answer is to find a better remote team. Sometimes it's to go back to an office. Both are valid.

The one habit, if you only adopt one#

If you do nothing else — write your end-of-week update. Public, in the team channel, every Friday, 5–10 bullets, no exceptions. It will single-handedly fix:

• Your visibility
• Your manager's confidence in you
• Your own sense of what you're actually getting done
• The quality of your weekly retrospective with yourself

It takes 15 minutes. Do it for six months. Watch your career notice.

Closing#

Remote work isn't a perk; it's a different operating model. Teams that treat it as "office, but at home" mostly fail. Teams that rebuild their habits around the constraint mostly thrive.

Pick one habit from this list. Do it for two months. Then pick another. `.trim(), };

• remote-work
• career
• productivity
• team