We used to do a 15-minute standup at 9:30 every morning. It had all the classic problems: it usually ran 25 minutes, two people did most of the talking, and the half of the team that was remote would lose the first ten minutes to audio issues. The version I remember most fondly was a day when four people joined from four different coffee shops and we spent the whole meeting troubleshooting Sam’s microphone.
Three months ago we replaced it with a text document. Everyone writes three lines by 10 AM:
- What I shipped yesterday
- What I’m doing today
- Anything I’m stuck on
That’s it. No meeting. No call. No scheduled time.
Here’s what actually happened.
The obvious wins were real
I’ll get these out of the way because they’re boring and everyone already knows them. Async updates give you back thirty minutes a day. Writing things down forces clearer thinking. The log is searchable. People in different timezones aren’t punished. The people who are shy in meetings contribute more when they can draft their thoughts first. Tick, tick, tick.
If this was all that happened, you wouldn’t need to read a blog post about it.
The thing I didn’t expect: nobody asked for help
In the standup, when someone said “I’m stuck on X,” three other people would immediately jump in. In the write-up, “stuck on X” just sat there. Nobody scrolls back to check other people’s entries unless there’s a specific reason to. The surface area for serendipitous help collapsed overnight.
It took us about two weeks to notice this was happening because we were mostly unblocked on the big things. What we were losing was the small stuff — the “oh, I ran into that exact bug last week, here’s the fix” moments. Those happened in person because you were forced to hear each other.
The fix: We added a convention. If you write “stuck on” anywhere, you have to explicitly tag the person you want eyes from. Default is @team, which notifies the Slack channel. It felt bureaucratic for about three days and then became second nature.
The other thing I didn’t expect: the log became a weapon
Not in a malicious way. In a subtle, accidental way that took me a while to spot.
When every day is written down, it’s very easy to fall into the habit of optimising your update for how it reads rather than reflecting what actually happened. “Shipped PR #283” is a better-looking line than “spent five hours debugging a memory leak that turned out to be a typo.” The second one is more valuable to the team and more honest. The first one is what you start writing when you know your manager reads every update.
I caught myself doing this. A week of my own updates had no “stuck on” entries at all, which is absurd — I’m stuck on something roughly every forty minutes. I was writing the person I wanted to be, not the engineer I was being.
The fix: I started leading with the ugly thing. “Lost three hours to a Redis eviction policy I didn’t understand. Fix was one line. I feel dumb.” Nobody else has to do this, but I did, because the tone of the top of the doc sets the tone for everything below it.
The meta-lesson
Asynchronous communication doesn’t replace synchronous communication — it replaces regularly-scheduled synchronous communication. Those are different things.
You still need to talk to each other. You just do it when there’s something specific to talk about, not on a cron job. The thing we thought we were solving (too many meetings) wasn’t actually what standups did for us. What standups did was give us a forced daily ritual where the thin, invisible threads of team cohesion got pulled back into focus.
When you replace the ritual with a text file, those threads go slack. If you don’t replace them with something else — a clear convention for asking for help, a weekly longer sync, a Friday demo, something — the team gets quietly more siloed every week and nobody notices until the output drops.
Would I go back?
No. The write-up is better. But “better than a broken meeting” and “solved the underlying problem” are different bars, and I confused them for about three weeks.
The real win isn’t that we killed the standup. The real win is that we had to articulate, out loud, what the standup was actually for — and then build something that served that purpose directly instead of as a side-effect of a scheduled meeting.
Most process improvements are really opportunities to understand what your current process was doing that you didn’t know about. The upgrade is just the reason you finally had to look.