Async standup

The daily standup exists to surface two things: what is moving and what is stuck. Neither needs everyone in the same call at the same minute. Writing the update costs the author a couple of minutes and costs the reader nothing, while a fifteen minute meeting for six people costs an hour and a half of team time plus the focus lost on either side of it. Async also fixes the timezone problem: there is no hour that is fair to Lisbon, Bangalore and San Francisco at once, so stop looking for one.

The blocker strip at the top of the board is the part that matters. Everything else is a log, useful for context and for catching up after a day off, but it is not why you read the board. Scan the blockers, reply to the ones you can unblock, and get on with your day. If a blocker needs a conversation, start a call with the two or three people involved instead of putting it in front of the whole team tomorrow morning.

Keep the updates short and concrete. "Fixed the retry loop in the importer, today I am on the deploy script" tells a teammate something. "Worked on the importer, continuing today" does not, and after a week of it people stop reading the board, which is how async standups die.

Nothing validates a code before it opens. Mistype one character into the code box, or follow a link somebody retyped by hand, and you land on a working board of your own under that name: empty, connected, and indistinguishable from a board whose team has simply not posted yet. The box takes four characters at minimum and upper-cases what you type, which is as much checking as happens. So when a colleague reports an empty board, compare the codes first. Passing the invite link around rather than the code avoids the problem outright.

What each box will take

Yesterday, Today and Blockers hold 300 characters apiece, and line breaks survive, so a two-line update stays two lines. The Post button waits for Today to have something in it and for the connection to be open. Forty people fit on one board, and forty updates fit on one day. Someone arriving at a full board is refused rather than let in quietly, though what they see is the connection failing.

Dates, and why the board is grouped by day

Your update is filed under your own device's calendar date, and the board accepts any date within a day either side of its own, which is what lets teammates on both sides of the date line post a shared working day. It also means Auckland and Los Angeles can file the same Tuesday morning under two headings. That is a fair description of a distributed team, so the board shows one heading per date rather than pretending everyone shares a day.

When the connection drops

A closed socket is retried five times with a lengthening pause, about twenty-two seconds end to end, and then the board gives up and says so. Nothing is queued while it is down, so an update typed during an outage is still in the form: reload, wait for connected, and press Post again. Every change sends the whole board out again rather than a patch, which is why a reconnection catches you up in one go and why two people editing at once cannot leave you looking at half of each.

There are no accounts here. Your name and avatar live in this browser only, which is what keeps the tool free of sign-ups, but it has a real consequence: a teammate who opens the board on their laptop and then on their phone arrives as two different people, and clearing browser data has the same effect. They will show up as a new person on the member strip until they post again under that identity.

For a small team that already knows who is who, this is fine. The board is a shared scratchpad, not an audit trail, and it should never be used as evidence of who did or did not report on a given day. Anyone with the link can post under any name, and only the last seven days are kept. If you need attribution you can rely on, you need a tool with logins, and you should be honest with your team about which of the two you are running.