Hopping on a Call

A message lands in Slack. “Hey, got a sec to hop on a call?” You look at the clock, at the thing you were in the middle of, at the thread of thought you’d just about pulled into focus. You type back, “sure.” It is almost never a sec.

I don’t hate calls, exactly. Calls in the right place are fine. I hate the reflex. The assumption that my time is there for the taking, cheaper than writing three sentences. “Hop on a call” pretends to be casual while asking for something that isn’t. It treats attention as a common resource, yours to draw from whenever the question in your head gets uncomfortable enough to share.

And the worst part is that it works. You do hop on, because saying “could you write that out?” sounds standoffish, and because the social cost of pushing back is higher than the cost of losing another half-hour you can’t get back.

The actual cost isn’t the half-hour. It’s the context switch on either side of it: the ten minutes before, where you start winding down so you can be present, and the twenty or so minutes after, where you try to find the rope you were holding and discover it’s on the floor somewhere. Cal Newport has written about this for years and I don’t need to reproduce the argument. Anyone who does knowledge work for a living already knows, in their body, what a fragmented afternoon feels like.

Meetings also reward the wrong things. Whoever talks fastest tends to win, and that usually isn’t the same person as whoever has thought the hardest. Confidence gets read as correctness. The person who would have written a better proposal never gets to, because the question already got decided in the room. “Alignment” very often means “I didn’t want to write it down.” “Sync” very often means “I wanted to feel like progress was happening.” A lot of meeting culture is theatre with calendars.

The counter-example that gets cited most, and deserves to, is GitLab. GitLab is an all-remote company of over a thousand people, and their entire operating manual is published on the open internet. The handbook is the single source of truth. Decisions get written down. Proposals are merge requests. Discussion happens in issues. Meetings exist, but they’re the exception, and the culture is built so that async is where actual work lives. Nobody has to enforce that by yelling. The handbook is just the thing everyone is pointed at, so the work ends up there.

The principle behind it is stark: if it isn’t written down, it didn’t happen. That sounds punitive until you work somewhere that operates the other way and watch the same decision get re-litigated three times in three different meetings because nobody bothered to put it in a document. Writing things down scales across timezones. It leaves an artefact the next person can read. It forces the person proposing the change to think it through before they take up anyone else’s time. Those three things are, quietly, most of what “good communication” at a company actually means.

The other counter-example is older and, if anything, stranger. The Linux kernel, one of the largest and longest-running software projects in human history, is coordinated almost entirely through a mailing list. Patches are sent as email. Code review is public, written, and archived forever. There are no daily standups on the kernel. Nobody pings Linus asking if he has a sec. There is a queue of patches and a lot of very opinionated prose.

Linus Torvalds has said, in various forms over many years, that he prefers written communication because it forces people to structure their arguments, and because it lets him ignore the performance and read the substance. He’s famously blunt on the list. Also famously hard to reach by phone. The kernel ships anyway, and probably because of all that, not in spite of it. You cannot coordinate a project of that size, with contributors scattered across every timezone and every employer on earth, in a meeting. Trying would collapse the thing. Writing is the medium it runs on.

The throughline in both cases isn’t really about remote work, or tooling, or time zones. It’s about what writing does to an idea. Writing is how you find out whether the thing in your head is any good. A call lets a half-formed thought pass as a conversation: you say it, someone nods, it sounds reasonable enough out loud, and the moment is gone before anyone has to look at it too hard. A paragraph is less forgiving. You read it back and you can usually tell, fairly quickly, that you don’t actually know what you’re proposing yet. That’s the paragraph doing its job.

Preferring async isn’t really about productivity, either, at least not for me. It’s about taking your own thinking seriously enough to put it through the effort of sentences, and taking other people’s time seriously enough not to spend it on your first draft.

I’m not anti-meeting. Hard conversations need voices. Early brainstorming, when the problem is still mushy and nobody is sure what they’re even trying to answer, sometimes needs a room. Occasionally a team needs to hear each other and remember they’re working on the same thing. I’ve been in meetings that mattered. I know the difference.

What I’m tired of is the default. The “quick sync,” the “jump on a call,” the afternoon eaten by half-hours from people who never had to decide whether their question was worth asking. Write it down first, read it back, and see whether it still holds up. Most of the time that process answers the question on its own.