I'm the lead frontend developer at dmclounge.ai and have worked remotely with teams in different time zones. Leading remotely is less about tools and more about writing, ownership, and protecting overlap.
Write by default
If it isn't written down, it didn't happen for half the team.
- Decisions go in short architecture decision records (ADRs): context, decision, alternatives, consequences.
- Conventions live in the repo (
CONTRIBUTING.md,docs/). - Meeting outcomes are posted in writing within the hour.
Make ownership explicit
Every area (routing, design system, auth, data fetching) has an owner who reviews changes and keeps docs current. People in other time zones know who decides without waiting for a meeting.
Async rituals
- Written standups: yesterday / today / blockers, posted at each person's start of day.
- Weekly written update from the lead: progress, risks, decisions needed.
- Demo videos instead of live demos when time zones don't align.
Protect overlap hours
The few hours everyone shares are precious. Use them for:
- Discussions that genuinely need back-and-forth
- Pairing and unblocking
- Relationship building
Don't spend them on status updates that could be written. More in Time-Zone Overlap.
Keep quality consistent
- A design system with documented components (building one)
- CI checks for lint, types, tests, accessibility
- Code review habits that work async
Onboarding
A new remote engineer should be able to ship a small change in week one using only written docs. If they can't, improve the docs, not the onboarding call.
Look after people
Remote leads have to look harder for burnout: people working across time zones answer messages at midnight. Set expectations about response times and model them yourself.