Asynchrony vs. synchrony is a constant struggle. Design meeting or design doc? Pair programming or code review? Pop-in or Slack message?

Synchrony grants speed, but asynchrony grants efficiency. Like debt each has their use, and each can be misused. As engineers we love to spout the good word of asynchrony so we can reclaim some time to actually build stuff, but there's nothing like a five-minute conversation to take the place of a weeklong email thread.

I've been in a secure war room exactly once in my career, for a week minus sleep handling a business-threatening emergency.¹ In that room we built some of the fastest product I've ever had the pleasure of vomiting onto my keyboard.

It solved the problem well. And we spent six months cleaning it up. That both those statements can be true is oft overlooked by engineers, junior and senior.

Like tech debt, synchrony trades away future velocity for present velocity. Sometimes you need that.

In the long run we are all dead. Economists set themselves too easy, too useless a task if, in tempestuous seasons, they can only tell us that when the storm is long past the ocean is flat again.

—John Maynard Keynes, A Tract on Monetary Reform (1923)

If you optimize too much for the future, you'll die before you get there. It's up to each project, team, org to find the right balance. I recommend asynchrony by default, with an eye trained on the efforts that really need to succeed in the present.

Employ synchrony when you need speed, but don’t call a 10-person meeting for anything that doesn't.