A remote engineer, working across time zones
Working from Rotterdam for teams anywhere. Written by default: decisions in the repository, progress in pull requests, a handover you can read instead of a meeting you have to attend. In English and in Dutch.
Rotterdam is UTC+1, and UTC+2 in summer, which overlaps with a working day in London, Berlin, the Gulf and the east coast of the United States. That covers most of the people who ask. It does not cover all of them, and pretending otherwise is how remote work goes wrong.
So the overlap gets stated up front instead of being discovered in week three: a block of hours that reliably meets your day, and everything outside it handled in writing. For a team on the American west coast that block is a couple of hours at the edges, and the work has to be arranged around that rather than around a daily stand-up.
Async is the default, not the fallback
The version of remote work that fails is the one where everything still happens in a call, and the call is now at an inconvenient hour for somebody. The version that works is the one where the default medium is written, and a call is what you schedule when writing has failed. That is a decision about how the work is recorded, and it has to be made in the first week or not at all.
In practice: a decision goes into the repository next to the code it constrains, not into a chat thread that scrolls away by Thursday. A change arrives as a pull request with the reasoning in the description, so review does not need a meeting. Progress is visible by reading the repository at any hour, with nobody awake to narrate it.
What you can read instead of attend
- A short written update at the end of each working block: what moved, what is blocked, what is next.
- Pull requests that explain why and not only what.
- Design notes and research kept in the repository, dated, with their sources.
- A handover document written as the work goes rather than assembled in the last week.
Two languages
The work runs in English and in Dutch. Code, comments and commit messages stay in English regardless, because that is what the next person to open the file will read. Dutch is for the conversation, for documentation aimed at a Dutch client, and for the domain terms that lose precision in translation: a factuur is not quite an invoice, and a journaalpost is not quite a journal entry.
Where it has been done this way
The outreach and CRM system in the work section was built like this and for the Dutch market: company enrichment, a scheduled sending pipeline, and a CRM recording what happened next, with the reasoning kept in the repository rather than in anyone's memory.
Common questions
- Which time zones can you overlap with?
- Rotterdam is UTC+1, UTC+2 in summer, so a normal working day overlaps fully with the United Kingdom, mainland Europe and the Gulf, and with the morning on the east coast of the United States. For the American west coast or for Asia the overlap is a couple of hours, agreed in advance and spent on the things that genuinely need talking about.
- How do I see what is happening without a status meeting?
- By reading the repository. Every change arrives as a pull request that explains its reasoning, decisions are written down next to the code they constrain, and each working block ends with a short written update covering what moved, what is blocked and what is next.
- Do you work in Dutch or in English?
- Both. Conversation and documentation can be in either language. Code, comments and commit messages stay in English so the next person to open the file can read them, and Dutch domain terms are kept in Dutch because the translation is always slightly wrong.
- What happens at the end of the engagement?
- A written handover: how the system runs, how to deploy it, where the credentials live, which parts are fragile, and what to read first. It is written as the work goes rather than assembled in the last week.