Working across six to eight hours of time difference does not have to be stressful. Over the years I have learned that remote projects either feel calm and predictable, or messy and reactive. The difference is rarely tools, it is how you use them, how you set expectations, and how you design the rhythm of the work.
In this article I will walk through the exact approach I use when I run client projects from Shanghai with teams in Sweden, the rest of Europe, or North America. You will see how I structure onboarding, how I use async communication, what I promise around response times, and how I avoid the classic trap where everyone is waiting for everyone else.
Why time zones are a feature, not a bug
Many people think that large time differences automatically create delays. My experience is the opposite. When you lean into async work, a six hour gap can become a built in accelerator. While you sleep, I move things forward. While I sleep, you review, comment, and make decisions.
Problems start when people expect a remote partner to behave like a colleague at the next desk. Endless chat pings, unclear tasks, and decisions that only live in someone's memory are what create chaos, not the time zone itself.
So my starting point with every client is simple: we design a way of working where time zones serve the project, instead of fighting the project.
What a typical project with me looks like
Most of my work falls into a few categories:
- Launching or refreshing a WordPress or WooCommerce site.
- Setting up or restructuring sourcing from China or Vietnam.
- Creating 3D product renderings and product pages for e-commerce.
- Helping a small team clean up operations and content workflows.
These projects are perfect for async work because a lot of the value is created in focused blocks: design, writing, development, supplier research, documentation, negotiations. They do not require constant real time meetings, they require clarity and predictable check ins.
Onboarding: week zero sets the tone
I treat the first week as an investment in how we will work together. This is where we remove most of the future friction.
The five things I set up in week zero
- One anchor document. A single page that holds the project goal, scope, success metrics, owners, deadlines, and links to everything else. I wrote more about this in The Anchor Doc: Async Rhythm for Distributed Teams.
- Access and permissions. I ask for what I need up front: WordPress logins, hosting access, product sheets, supplier lists, or CAD files. This avoids last minute access drama later.
- Tools and channels. We agree where decisions live, where tasks live, and what we use for quick questions. Usually this means email plus one shared workspace, such as Notion, Google Docs, or a simple shared folder.
- Cadence and time boxes. We pick one weekly slot that works for live calls if needed, and we define when you can expect updates from me.
- Definition of done. For each deliverable we write down what “done” means. For example, a completed product page needs copy, images, meta data, and one review pass from your side.
When week zero is done you should be able to answer three questions: What are we building, how will we work, and when will I see progress. If any of those are fuzzy, I will push to clarify them before we dive into heavy work.
The simple tool stack I use with clients
I try to match the tool choices to what you already use, as long as we can keep things structured and searchable. The exact apps matter less than the rules for how we use them.
Core tools
- Email for formal updates, approvals, and anything that we might need to search for a year later.
- One shared document space such as Notion or Google Docs for the anchor doc, specs, copy drafts, and meeting notes.
- A light task board if the project is complex enough to justify it. Trello, Notion boards, or a simple Kanban in your existing system is usually enough.
- Video calls through your preferred platform when we need live discussion, usually weekly or biweekly.
Rules that keep tools from becoming noise
- If a decision is important, we write it in the anchor doc or in a clearly labeled section of the main project doc.
- If a task is bigger than a single message, it gets a card or a bullet in a task list.
- If something is urgent, you mark it as such and use the agreed channel for urgent messages, usually email with a clear subject.
This means you never have to scroll through endless chat history to find what we agreed last Tuesday. You always know where to look.
Weekly rhythm: how work actually flows
Here is a typical weekly rhythm for a project where you are in Sweden and I am in Shanghai. The example assumes five to seven hours of time difference.
Monday: your priorities, my plan
- You share your top priorities for the week in the anchor doc or by email. This takes ten minutes.
- I confirm what I will deliver, clarify any open questions, and adjust the task list.
- If needed we have a short call to align on changes or new information from your side.
Tuesday to Thursday: deep work blocks
- I work in focused blocks on the agreed tasks, such as building templates, creating 3D renders, writing copy, or speaking with suppliers.
- You review what I have shared, leave comments, and answer questions when it fits your schedule.
- I avoid sending small updates every hour, instead I send one clear progress update at the end of my work window.
Friday: review and next steps
- I send a structured update that includes what was done, links to deliverables, what is blocked, and what is next.
- You can quickly see the status and decide what needs your attention before the new week.
The exact days are flexible, but the idea is the same: we start the week with clarity, spend most of the time in deep work, and end with a snapshot that you can share with your team or manager.
Response time expectations and how we avoid bottlenecks
One of the most important parts of working across time zones is agreeing what fast and slow actually mean. I prefer to be explicit.
The basic response rules I propose
- For normal questions we aim for a reply within one business day. This keeps momentum without forcing anyone to live in their inbox.
- For urgent issues we agree on what counts as urgent, and we use a specific subject line or tag so it stands out.
- For approvals we aim for a clear yes or no within two to three business days, or we agree on a date when you will decide.
- For large changes we schedule a short call instead of sending long walls of text.
When you know roughly when you will hear back from me, you do not need to send follow up messages just to check in. And when I know how quickly you usually reply, I can plan my work blocks so that I am not blocked while waiting for information.
Designing handoffs across time zones
A handoff is the moment where work moves from me to you or your team, or the other way around. Designed well, handoffs are where time zones become a multiplier. Designed poorly, they create long gaps where nothing happens.
What a good async handoff looks like
- A short summary of what changed or what needs review.
- Links to the exact pages, files, or boards you should look at.
- Clear questions, such as “approve this layout”, “choose one of these three options”, or “confirm this quantity”.
- A note on impact if it stays unreviewed for several days.
This means you can open my update in the morning, spend fifteen minutes reviewing, and unblock me before I even start my work session.
What happens when something goes wrong
No matter how well you plan, there will be moments where something breaks, a supplier backs out, or a plugin update does something strange at the worst possible time. The point of a good async setup is not to avoid all problems, it is to make sure we know what to do when they appear.
My simple incident playbook
- Stabilise first. For websites this means backups and quick rollbacks. For sourcing this means confirming what is actually true, not reacting to rumours.
- Communicate early. I tell you what happened, what I have already done, and what options we have.
- Decide on the smallest safe step. In many cases we can implement a temporary fix while we investigate deeper.
- Capture the lesson. We add one or two lines to the anchor doc or a risk log, so that we do not repeat the same mistake next quarter.
Because we already know which channels to use and how to mark something as urgent, we do not waste time figuring out how to reach each other in the middle of the issue.
A concrete example timeline
To make this less abstract, here is a simplified week from a real project with a client in Sweden. The project was a WordPress refresh plus new product pages, combined with some supplier research in China.
- Monday morning, Sweden: Client updates the anchor doc with two priorities: finalise the homepage and prepare ten new product pages.
- Monday afternoon, Shanghai: I confirm the plan, add tasks for copy and layout, and ask three questions about shipping options for the new products.
- Tuesday: I work on the homepage layout and send a preview link. Client reviews in the evening, leaves comments, and approves the overall structure.
- Wednesday: I build the first five product pages and send them in a batch with a short checklist of what to review.
- Thursday: Client approves three of the pages as is, and leaves comments on two that need adjustments.
- Friday: I implement the changes, update the status in the anchor doc, and send a weekly summary email with links and next steps.
We only had one short call that week, still the project moved forward in a steady way because each handoff was clear and the expectations around timing were explicit.
When this way of working is a good fit
This async, time zone friendly approach is not for everyone. It works best when:
- You are comfortable with writing and reading short structured messages.
- You value calm, predictable progress over constant live interaction.
- You want a partner who can move independently, not just wait for instructions.
- You are willing to invest a little time up front to set up the anchor doc, access, and rhythms.
It is less suitable if you expect someone to be online at the same time as you all day or if the project is extremely reactive by nature, such as live event operations with many last minute changes.
How to start a project with me
If this way of working sounds interesting, the next step is very simple. Send me a short message with:
- A few lines about your company and what you do.
- What you want to improve or build in the next three to six months.
- Where you are based and who else will be involved on your side.
I will reply with a short overview of how I would approach your project, what I expect the first month to look like, and a simple pricing structure. If it feels like a good match, we book a call and start week zero.