Most of my client engagements are remote, and have been for years. UK clients, European agencies, US product teams. Calendars never line up neatly, and "let's hop on a call" stops scaling about three meetings in. So I built my workflow around the assumption that good work happens between meetings, not in them.
Here is how a remote engagement actually runs day-to-day.
The principle: writing beats meetings
None of this is original. Basecamp made the case twice. Rework in 2010 has a chapter called "Meetings are toxic" that has aged better than most productivity advice from that decade, and Remote in 2013 is the whole playbook for running a distributed team without everyone living on video calls. The maths is simple. A 30-minute meeting with five people is a 2.5-hour line item, and most of those decisions could have been a Slack thread. Calendar-driven work also fragments the day into 90-minute slots that are useless for anything requiring real thought.
So my default is simple. Whatever can be written, gets written, as a Loom or a Slack thread. Calls happen when conversation genuinely beats writing, usually contract scoping, sensitive feedback, or someone who is actually stuck.
Step 1: a spec before code
Every engagement starts with a short written spec. Not a 40-page requirements doc, usually one to three pages covering four things: the problem (what is broken, missing, or slow), the scope (what is in, what is explicitly out), the acceptance (how we will know when we are done), and the decisions (anywhere I had a choice and went one way, like "Drizzle, not Prisma", with the reasons). The architectural calls in that last bucket I keep as short ADRs: decision records that stay put while the implementation underneath them changes.
The spec lives in Notion, Google Docs, or GitHub markdown, whatever the client uses. It is editable for the first week, frozen after that. Changes after the freeze go through a written change-request, even if it is just a Slack message saying "spec change: scope now includes X".
This sounds bureaucratic. It isn't, in practice. The spec is the difference between an engagement that ships in five weeks and one that drifts into eleven. Most "scope creep" is just verbal agreements that nobody wrote down.
Step 2: workstreams, not standups
Active work lives as workstreams. Depending on what the client already uses, a workstream might be a Linear or Jira ticket, a GitHub Issue, or just a short itemised list of milestones in a markdown file. The format matters less than the shape: each one is a small, named deliverable ("Add multi-tenant column to users table"), carrying the relevant slice of the spec and a running thread where I drop progress notes async.
This replaces the daily standup. If you want to know what I worked on yesterday or what I am working on now, the workstream tells you, without a 9:30am call where everyone takes turns.
The team can drop questions on the ticket. I answer at the next break in deep work, usually within a few hours during UK business hours. I don't expect instant replies on Slack and I don't promise them.
Step 3: Loom for reviews and walkthroughs
Most code reviews and design walkthroughs go out as a 5-minute Loom that the team can watch at 2× when convenient. Loom (or Cleanshot, or just QuickTime with a shared link) is the best workflow upgrade I have adopted in the last decade. The video says: here is what I built, here is why I went this way instead of the alternative, here is the bit I would appreciate eyes on before we ship.
The team watches, drops timestamped comments, I reply. No one had to clear a 30-minute slot. Reviews land within a working day, and the recording stays as documentation for future contributors.
Step 4: calls only when they earn it
I still take calls. Four kinds:
- Kickoff: the initial spec walk-through and contract scoping. One call up front, usually 30 to 45 minutes.
- Architecture inflection points, where a trade-off is easier to discuss out loud than to write up.
- Feedback that needs nuance: performance reviews, scope changes, anything where tone matters.
- The stuck call. Once a fortnight someone is stuck for a reason that won't unblock async. Hop on, fix it in 20 minutes.
Calls happen on whatever the client uses. Google Meet most often, Zoom for some agencies, Microsoft Teams for the enterprise contracts. I don't have a preference. The tool is the easy part. What matters is that the call has a clear question and ends when it is answered.
The communication stack
For reference, the actual tools across an engagement:
| Channel | Used for | Async? |
|---|---|---|
| Slack / Teams | Quick questions, status updates, threaded discussions | Yes, no instant-reply expectation |
| Linear / Jira / GitHub Issues | Source of truth for the work | Yes |
| Loom / video | PR walkthroughs, demos, async reviews | Yes |
| Google Meet / Zoom / Teams | Kickoff, scoping, sticky topics | No, booked in advance |
| Notion / Google Docs | Specs, decisions, retros | Yes, written and durable |
The ratio in practice: maybe 80% async writing, 15% Loom, 5% live calls. Heavier on calls during the first two weeks, lighter once the spec is locked.
What this looks like from the client side
The deal I make with clients up front:
- You will get a written spec before code starts. Edits welcome before the freeze.
- I reply to every Slack message and every email within 24 hours during working days. Usually faster, but 24 is the contract.
- Status comes from tickets, Loom updates, and a written end-of-week summary. No standups.
- Calls when the topic earns one, and we both end them when the question is answered.
Most clients prefer this once they have worked with it. The engagement runs faster because nobody is waiting on a calendar slot to make a decision, and the team gets their deep-work hours back. Nothing important falls through because everything that matters gets written down.
Where this came from
A lot of this came from running engineering teams remotely during 2020 to 2022 and watching meetings expand to fill a Zoom-shaped life. Remote is the closest thing to a manual for the way I work, and Rework gave me the language for why meetings cost more than they look. Cal Newport's Deep Work gave me the argument for protecting the focus time. Shape Up, Basecamp again, gave me the cycle and cooldown structure that frames most of my engagements.
If you want to default to async on your next hire, this is what working with me looks like in practice.
Let's talk if it sounds like a fit.
