Kill the Standup: Async Status for Teams of Two or Three

You and one other person are building a product. You already know what they're working on — it's on the board, in the channel, in the pull request you reviewed an hour ago. And yet, every morning at 10am, you both stop what you're doing to say it out loud. That ten-minute meeting rarely stays ten minutes, and the damage isn't the ten minutes anyway. It's the half-hour of deep work you sacrificed to be "available" for it, and the half-hour after to climb back into the problem you abandoned.

The daily standup is a good idea that was designed for a context you are not in. For a team of eight or twelve, a tight synchronous check-in surfaces blockers that would otherwise hide for days. For a team of two or three, that same ritual costs more focus than it could ever save. This post is about why the math flips at small scale, and what to do instead.

---

What the standup was actually for

Strip away the ceremony and the daily standup exists to do three things: surface blockers early, keep everyone roughly aligned on direction, and create a small social commitment that nudges people to make progress. On a larger team those are real problems. Information doesn't flow naturally between ten people, so you manufacture a moment where it has to.

Notice that none of those three goals requires a meeting. They require visibility and a way to ask for help. The standup is one implementation of visibility — a fairly expensive one — and at large scale the expense is worth it because the alternative is chaos.

The standup also smuggles in a fourth, unspoken function: status theater for whoever is anxious. Someone wants to hear everyone is busy. That's a management instinct, and it's exactly the instinct that does the most harm on a tiny team where there is no manager to reassure, only makers to interrupt. If you've felt the pull of tools and rituals invented for big orgs, the same logic runs through why most PM tools are built for teams of 50 — ceremony scales down badly.

---

Why the value-to-cost ratio collapses at tiny scale

Here is the part nobody says out loud. The benefit of a standup grows with team size, because more people means more hidden information to surface. But the cost is roughly fixed per person — every attendee pays the same focus tax regardless of how big the team is.

So divide. On a team of ten, the meeting surfaces a lot of information you couldn't get otherwise, spread across ten people who each pay one unit of interruption. On a team of two, you surface almost nothing you didn't already know — you sat next to this work yesterday — yet you and your one teammate still each pay the full interruption tax. The ratio of value to cost doesn't shrink gracefully. It falls off a cliff.

The 23-minute figure comes from Gloria Mark's research on attention and context-switching: once you're knocked out of a focused task, getting fully back in takes far longer than the interruption itself. A standup that "only takes ten minutes" can easily cost forty-five minutes of real productive capacity per person once you count the ramp-down before and the ramp-up after. For two people, that's an hour and a half of your team's daily deep-work budget spent to confirm things you could have read.

---

The interruption tax: maker's schedule vs manager's schedule

Paul Graham's old observation about the maker's schedule and the manager's schedule explains the whole conflict. Managers live in one-hour blocks; a meeting slotted anywhere costs them an hour and they barely notice. Makers — people who write code, design, write — work in long unbroken stretches, and a single meeting in the middle of the morning doesn't cost an hour. It poisons the entire half-day, because you can't sink into a hard problem when you know you'll be yanked out of it soon.

A standup is a manager's-schedule instrument imposed on maker's-schedule people. On a big team there are managers in the room for whom this is genuinely cheap. On a team of two or three, everyone is a maker. There is nobody for whom the meeting is free. You are all paying maker prices for a manager's tool.

This is also why "let's just keep it short" never fixes it. The cost was never the duration. The cost is that the meeting exists at a fixed time and fragments the day around it. Even a perfect five-minute standup forces both makers to hold their morning hostage until it's over.

---

What to do instead: make the board the source of truth

The replacement for a synchronous status meeting is not a different meeting. It's a board so trustworthy that nobody needs to ask what's happening because they can simply look.

A well-maintained kanban board already encodes everything a standup would tell you:

• Columns show the state of every piece of work — Backlog, In Progress, In Review, Done. The shape of the board is the status report.
• Assignees show who owns what. No "what are you working on?" needed; their name is on the card.
• Priorities (P1–P4) show what matters most right now, so nobody has to verbally re-litigate importance every morning.
• Work-in-progress limits are the secret weapon. If each person is capped at one or two in-progress tasks, the In Progress column is the standup. A glance tells you exactly what each of you is heads-down on.

The discipline that makes this work is keeping the board honest in real time — moving a card the moment its state changes, not at meeting o'clock. That's a small habit, and it's far cheaper than a meeting because you pay it in seconds, inside the flow of work, rather than in a synchronized block that interrupts everyone.

This is exactly where real-time sync earns its keep. When the board updates instantly for everyone — no refresh, no "did you push that?" — it becomes safe to treat as ground truth. GritShip syncs the board live across everyone in the workspace, so when your teammate drags a card to In Review at 9:42, you see it at 9:42, not at standup. That immediacy is what lets a board replace a conversation instead of merely supplementing one. The same principle of a single trustworthy board underpins the broader argument in the solo dev PM guide without bloat.

---

The async written update — for real blockers only

Boards communicate state beautifully. They do not communicate "I'm stuck and I need you." That's what a short written async update is for — and the keyword is blocker, not status.

A status update is a report nobody asked for: "Yesterday I worked on the payments form, today I'll keep working on it." The board already said that. An async blocker update is a request: "Stuck on the Stripe webhook — signature verification fails in the test env. I think it's the secret, but I can't confirm without prod access. Can you grant it or tell me where it lives?"

The difference is that the second one has a recipient and an ask. It exists because something needs to change, and it can be read and answered whenever the other person surfaces from their own deep work — no synchronization required.

Good async blocker updates share a shape:

1. What you're trying to do — one sentence of context.
2. Where you're stuck — the specific wall, not a vague "having trouble."
3. What you've already tried — so they don't suggest the obvious thing.
4. What you need — a decision, access, a second opinion, an unblock.

Write them like you'd want to receive them. This is the same muscle as writing tasks your future self can actually act on — the discipline I dig into in write tasks for your future self. A blocker you describe precisely is a blocker that gets resolved in one round-trip instead of three.

---

Daily standup vs async board, head to head

The async model isn't free; it trades a recurring meeting for a recurring habit. But a habit you pay in seconds, inside flow, is categorically cheaper than a meeting you pay in synchronized hours.

---

Keep one real meeting: the weekly 20-minute sync

Killing the standup does not mean killing all conversation. Some things genuinely need real-time, high-bandwidth talk, and trying to do them async is its own kind of waste — a decision that takes ten messages over two hours could've taken ninety seconds out loud.

Reserve a single weekly sync, capped at 20 minutes, for exactly those things:

• Planning the week — what are the two or three outcomes that matter, and who owns them.
• Decisions that branch — architecture forks, scope cuts, anything where the discussion changes the plan.
• Disagreements — text is terrible at resolving these; talk it through.
• The human stuff — how are we doing, are we over-committed, is anyone burning out.

That's it. One predictable, bounded slot for the high-value conversation, and the other four mornings stay sacred. If you're running several products at once, this weekly rhythm is also where you reconcile priorities across them — a problem I cover in managing multiple projects as a solo developer.

---

How to know when you actually do need to talk

Async-first does not mean async-only. The skill is recognizing the small set of moments that justify breaking someone's focus. Reach for synchronous when, and only when:

• There's a true blocker and it's urgent — you're fully stopped, it's costing you the day, and a 60-second conversation unblocks you. Don't write three paragraphs; ping them.
• A decision is genuinely two-way — both opinions matter and the choice shapes the next week of work. Decisions with real branches deserve voices, not threads.
• There's a disagreement with heat in it — the moment text starts feeling tense, switch to talking. Async amplifies misreadings; a voice defuses them.

Everything else — progress, "I finished X," "I'm picking up Y next," routine questions with an obvious answer — is async by default. If you find yourself reaching for a call to deliver information that has no ask attached, that's the standup instinct, and the board should be carrying that load. Optimizing for flow over ceremony is the same throughline as measuring what matters: forget velocity, track cycle time makes the parallel case that the signals worth watching are the ones that don't require a meeting to read.

---

A note on the backlog and what stays off the board

One failure mode of going async is over-stuffing the board so it stops being readable at a glance. The async model only works if the In Progress and Up Next columns are short and true. Everything speculative — the someday-maybe ideas, the half-formed feature requests — belongs in the backlog, clearly separated from active work, so the live part of the board stays scannable. A board you can read in three seconds is a board that replaces a meeting. A board with sixty cards in flight is just a different kind of noise.

---

Frequently asked questions

Isn't dropping the standup just an excuse to avoid accountability?

The opposite. A standup makes accountability verbal and momentary — gone the second the meeting ends. A board with owners, priorities, and WIP limits makes it visible and persistent: anyone can see what you own and where it stands, any time, without you having to perform it. That's stronger accountability, not weaker.

What if my teammate just stops updating the board?

Then async status is genuinely broken, because the model depends on the board being true. Treat board maintenance as a shared commitment, not a chore — moving a card the instant its state changes, in seconds, inside flow. If it keeps slipping, that's a real conversation for the weekly sync, not a reason to reinstate a daily meeting.

We're remote across time zones. Doesn't that make a standup even more important?

Time zones are the strongest case for going async, not the weakest. A synchronous standup forces someone to attend at a bad hour for them. An honest board plus written blocker updates means each person reads status and answers asks during their own working hours — which is exactly what remote work is supposed to enable.

How is an async written update different from a status report?

A status report narrates what you did and has no recipient — the board already covers that. An async update is a request: it names a specific blocker, what you've tried, and what you need (a decision, access, an opinion). If your written update has no ask in it, it's probably redundant with the board.

Won't we lose the team feeling without a daily check-in?

Some of it, yes — which is why you keep one weekly 20-minute sync for planning, decisions, and the human stuff. That bounded slot does the social and alignment work far better than a rushed daily ceremony, and it protects four mornings of deep work instead of fragmenting all five.

At what team size should I bring the standup back?

There's no hard line, but the value-to-cost ratio improves as information stops flowing naturally between people — roughly past five or six. Below that, a trustworthy board plus async updates almost always wins. Even on bigger teams, a current board can shrink the standup dramatically rather than replace it outright.

The daily standup isn't evil. It's a tool that solves a real problem at a scale you're not operating at. For two or three people who already sit inside each other's work, the meeting takes more focus than it returns, and the things it was meant to surface live better on a board you can trust and in a short written note when you're genuinely stuck. Keep the one weekly conversation that earns its place. Kill the other four. Then go ship something, uninterrupted.