
We work from home. That is the whole of the arrangement, and we have written before about why we chose it. This post is about something less interesting and more useful: what has to happen every day for a small remote team to keep working without anyone chasing anyone.
None of it is clever. Most of it is habit. But habit is the part that rarely gets written about, because "write things down" does not make a good headline. We think it makes a good company.
Write it down, or it did not happen
In an office, a decision can live in the air for a while. Two people agree on something at a desk, a third overhears, and it more or less spreads. At home there is no air. A decision that is not written down exists only in the memory of the people who were on the call, and memory is not a shared resource.
So the rule we try to hold ourselves to is simple: if it was decided, it is written somewhere the whole team can read it. Not the transcript, not the forty messages that led up to it, just the outcome, who decided, and why. Three or four lines is usually enough.
The "why" is the part that gets skipped and the part that matters most. Six months later nobody questions what was decided; they question whether it still applies. A line of reasoning is what lets the next person answer that without reopening the whole thing.
Async by default, calls by exception
A small team spread across homes is also spread across interruptions. A question that lands as a message can wait until the person has finished the thing they were doing. A question that lands as a call cannot.
So we believe in writing first. A good written question carries its own context: what you are trying to do, what you have already tried, what you need from the other person, and by when. Written that way, it can be answered in one go, at a time that suits the reader, and the answer is there for the next person who has the same question.
Calls still happen. They are the right tool when something is genuinely tangled, when a disagreement is going round in circles in text, or when someone new needs to be walked through something. The point is not to ban them. The point is that a call should be the thing you reach for after writing has failed, not before you have tried it.
What a good message looks like
- It says what it is about in the first line.
- It says what it needs: a decision, a review, an answer, or nothing at all.
- It carries a date if it has a deadline, not "soon".
- It goes to the place where it belongs, not to whoever happens to be online.
The daily check-in is a paragraph, not a meeting
Most remote teams do some kind of daily check-in. Most of them get it wrong in one of two directions: it becomes a half-hour video call that nobody needed, or it becomes a ritual line ("same as yesterday") that nobody reads.
The version we believe in is written, short and honest. Three things: what you finished, what you are on next, and what is in your way. That last one is the whole reason the check-in exists. On a team of a handful of people, one person stuck for two days is a serious cost, and the check-in is the cheapest way to find out.
It should take five minutes to write and less to read. If it takes longer, it is turning into a report, and reports are for a different audience.
One place where the truth lives
Ask a remote team "where is the current version of this?" and you find out quickly whether it has a source of truth or just a lot of places where the thing has been mentioned.
We believe every product, every project and every decision needs a single home. Not the chat history, which scrolls away. Not someone's laptop. One document, or one folder, that everyone understands to be the current state. When the chat and the document disagree, the document wins, and the chat is where you go to update the document.
This sounds bureaucratic and is the opposite. It is what lets someone go on leave for a week without anyone needing to reconstruct what was in their head. It is what lets a new person join and read their way in, instead of being told things in whatever order they happen to come up.
Keeping it honest
A source of truth rots if nobody tends it. The habit that keeps it alive is small: whenever you learn that a document is wrong, fix it then, rather than noting that someone should. Two minutes now saves a stranger twenty later.
Being reachable is not the same as being on
The trap of working from home is not laziness. It is the opposite. The laptop is on the table, a message arrives at nine in the evening, replying takes ten seconds, so you reply. Then you are a person who replies at nine in the evening, and soon everyone else is too.
We think a small company has to guard against this deliberately, because there is no building to leave. A few things help:
- Say when your day ends, and end it. Not vaguely. A time.
- Treat a message sent outside hours as something to read tomorrow, unless it is marked urgent, and be sparing about marking things urgent.
- Do not mistake speed of reply for quality of work. The fastest replier is often the person whose real work is being interrupted most.
- Leave is leave. Someone on leave who is answering questions is not on leave; they are working from a worse desk.
None of this works if it is a policy that only the most junior person follows. It works when the people who founded the company are seen to switch off too.
Why the small stuff is the whole thing
Everything above is small. Write the decision down. Ask in writing. Post three lines a day. Keep one document current. Log off at a fixed time. None of it needs software beyond what any team already has, and none of it is a secret.
What it needs is to be done consistently, by everyone, on the days when it feels unnecessary. That is the unglamorous part. A remote company is not held together by a tool or a policy. It is held together by a few dozen small habits, kept up by a few people who trust each other to keep them up.
We are a young company and we are still learning which of these hold and which need changing. But we would rather be honest about the mechanics than pretend the arrangement runs itself. It does not. It runs because somebody wrote it down.
