Async project management for small remote teams: let the tracker do the standup

Five people, three time zones, and a fifteen-minute video call every morning that is 9am for two of them and 6pm for one. Nobody defends it. Nobody cancels it either.

Almost everything written about async project management for small remote teams is advice about communication tools. Write more down. Move decisions out of calls into threads. Agree a response-time expectation. All of it is correct, and none of it touches why the daily call survives on teams who have already done all of it.

The call survives because it is the only moment anyone is confident they know the state of the work.

The case for keeping standup, made properly

The strongest argument against going async is not that remote teams need face time. It is that a meeting which can be replaced by writing was never worth holding.

hyperpape put it on Hacker News in 2020: "I think if your standup can be async, then it's ineffective, and you should get rid of it." The value is not the round of updates at all — "the purpose of the standup is just to get that moment of 'I know about that, let's talk'" — and for that, being present at the same time beats writing, because async carries "higher coordination costs" (news.ycombinator.com).

The framework agrees. The Scrum Guide gives the Daily Scrum's purpose as "to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work" (scrumguides.org). That is a planning meeting, not a status round.

So if your standup is genuinely the moment two people discover they are about to collide, keep it.

Why it became a status round anyway

Teams do not drift into status rounds because they forgot the theory. They drift because the round is doing real work. jVinc described the end state: "the daily stand-up gets changed into a 30 min status meeting, and people start hating it" (news.ycombinator.com).

It survives as a repair mechanism. Somebody says out loud that the auth branch merged on Tuesday, and four people silently patch their model of a board they already knew was wrong. The meeting is not producing information; it is reconciling an untrusted record against the only people who know the truth.

So it is downstream of a tracker problem, not a communication problem. We have written about why the record goes stale in why nobody updates the project board: a status field is a second manual copy, and copies drift fastest when the team is busiest.

The two properties async project management actually requires

Neither is on a pricing page, and together they decide whether you can drop the meeting.

State changes as a side effect of the work, not as a decision to record it. If moving a card is a separate act of will performed after the real job, it happens late or not at all.

Catching up is a pull, not a scroll. Moving standup into a channel does not make it async, it makes it a transcript. Someone waking six hours later does not want two hundred messages in chronological order. They want two answers: what changed on things I am attached to, and what is mine now. A channel is ordered by time. A tracker can be ordered by relevance.

Cancel it for a week and see what you miss

Drop it for five working days and notice which question you keep wanting to ask.

If it is "what is everyone doing", the board is broken and the meeting was covering for it. Fix the record, not the calendar.

If it is "is anyone stuck", no tracker resolves that. Keep the meeting, hold it weekly instead of daily, and stop pretending it is about status.

What the tools offer here

Basecamp's Automatic Check-ins is the best-known product answer, blunt about what it replaces: "Cut back on meetings and stand ups by setting up Automatic Check-ins instead. Set up questions that are asked on a regular schedule", with everyone's answers "saved back to a single log for easy review whenever" (basecamp.com). It is on every plan, including the free one, which covers up to 20 users on one project (basecamp.com/pricing).

It genuinely works, and Kevta has nothing equivalent. A written prompt at a time that suits each person beats a call at a time that suits two of them. But it still asks a person to type what happened after they have finished doing it — a better time and a better medium for the ritual, and the same second copy.

Deriving state instead of asking for it

Kevta's answer to the first property is narrow: for work that has code attached, git already knows the state, so the tracker reads it rather than asking.

You copy a branch name off the issue — feature/MS-42-refactor-router — and push. When the pull request opens, Kevta matches it back by scanning the branch ref, PR title, body and commit messages for the board key. No linking step, no magic word. Five rules then ship switched on: branch push to In Progress, PR opened to In Review, PR marked ready to In Review, approval to Ready for QA, merge to Done.

Three more rules exist and ship switched off — PR back to draft, changes requested, PR closed unmerged. They are all reverse transitions, which is where automation embarrasses itself. The branch-push rule carries a guard for the same reason: it only fires when the issue is still in To Do, so a stray push to an old branch cannot drag finished work backwards at 3am. Co-located, someone spots it. Across time zones it sits there for a day.

Making catch-up a pull

The second property is the unglamorous half, and the one that decides whether anyone can actually skip the call.

Kevta's inbox collects changes across every board you belong to, grouped under Today, Yesterday and Older, newest first. A status-change row names both the status the issue came from and the one it moved to, so the row is the update rather than a pointer to it. You are attached to a task by being assigned it, by watching it, or automatically because you created or commented on it, and your own actions never notify you — so the list is other people's news. Separately, My issues collects everything assigned to you across every board, bucketed as Overdue, Today, This week, Later and No due date.

An inbox that answers what changed, and a list that answers what is mine. Six hours of scrollback replaced by two pages.

What Kevta does not do

No Slack integration today, so nothing posts into a channel. No check-in feature. No display of anyone's local time or working hours. And no notification email at all — updates live in the app, so the inbox waits for you and never chases you, which is either what you wanted or a dealbreaker. Nothing fires because a due date is approaching, either.

The real limit is scope. Deriving state from git only covers work with a branch behind it. Design review, a customer conversation, a decision waiting on somebody — those are still a person typing, and still the part of the board most likely to be wrong. If most of your work has no code attached, a written check-in habit is the better answer. Keeping the tracker itself running is a separate tax, covered in being the Jira admin for a small team.

Cancel the meeting for a week first. If the board holds you have your answer; if it does not, you know what the fifteen minutes were buying. If you want the version where the board keeps itself, Kevta is in beta and you can join the waitlist.