I think a big part of this article is that the author doesn't like being interrupted and therefore has defined this as the problem. I don't like being interrupt

I think a big part of this article is that the author doesn't like being interrupted and therefore has defined this as the problem. I don't like being interrupted either - but often the interruptions I experience are the best opportunities I have to communicate ideas, have creative back and forth, and importantly, communicate the details that are going to get me shouted at for saying on the wiki. The problem with asynchronous communication is that I need to predict what information you're going to need, before you need it. The result is huge amounts of documentation work going on - 90% of which is useless, and the other 10% is either undiscoverable or could as just as easily be solved with "has anyone touched the db" in chat. The example is great - because it's absolutely something that I've seen happen. You post on the group chat "did anyone touch the db" and someone replies, "Oh Johnny mentioned something about it the other day". Suddenly you're not searching through thousands of jira tickets and wiki pages, and most likely not finding what you want anyway - since no one can predict how they'll scre up. You just ping Johnny, and if Johnny isn't there? Well he'll reply when it's back. It's fine. That is part of flexible working. Flexible working isn't "I get to pick up my kids at 12" it's about everyone having flexibility, and everyone giving flexibility. To me, this asynchronous communication plan sets an unacheivable goal, because you're never going to know what it is other people are going to need to know, and documenting everything exhaustively is an uneconomical.