> The communicator is responsible for communicating effectively, either by writing, speaking, diagraming, messaging, or designing tools that clearly convey intent.
> Meetings are a last resort. Favor asynchronous communication first.
Yes, the sender is responsible, but the context always matters. The receiver has to be familiar with the sender, trust them, etc. I've seen first how "less meetings" can be applied to a fault. And the team members with average or below comm skills suffered, as did the rest of the team.
An entire team simultaneously in flow is a wonderful ideal, but the reality is that's very rare (read: often a waste of energy). Accept the friction, monitor what works and what doesn't, and operate around thst
Just like everything else in software delivery, you are not aiming for perfection and ideals, but to continuously optimize and improve. You may never get there but that also doesn't mean you need to accept friction and not do anything about it.
"Fewer meetings" could indeed be applied to a fault (like everything else) but that's definitely not the aim, the aim is to optimize for async communication and have more substantial meetings with outcomes when you need to have them. And also, it is far more rare to work at companies where they don't have enough meetings, usually, it is the opposite.
AD: I have to disagree with the assumption there are only 3 communication forms (work, async, sync) - it's not hard to fathom a counter example such as Pairing where-in synchronous communication is necessary for the pair's flow state to emerge but they are "working as communication". Likewise there is an assumption here that meetings don't create flow states or that they don't contribute to "work as communication". Not all engineering is writing code and there should be some amount of back-pressure for writing the right code not just writing any code.
However I do agree with a general mentality of do > say which I believe this article is trying to allude to.
I definitely didn't mean to imply in the article that meetings or sync communication in general does not help contribute to flow state. My point of view is that these sessions you do synchronously are also a big part of what makes flow possible, because after them doing the work becomes easier, more clear and flow is more possible. But they are very much necessary to plan, strategize and discuss as you well put it. Also to ensure the right code is written. Although on that note I also feel that all meetings and discussions should have a codified result, especially when it comes to align with engineering principles, coding style guides, and things like that align people in the way they work.
I will need to revise the article to ensure I am clear about that point, thanks for the feedback!
Yes, but if a conversation happened in a channel you don’t have access to…
Only once in the last decade have I worked at a place where everyone was disciplined about threads in the right channels. More often, conversations take place across a few channels which makes “re synthesizing” the slack results… hard
> Meetings are a last resort. Favor asynchronous communication first.
Yes, the sender is responsible, but the context always matters. The receiver has to be familiar with the sender, trust them, etc. I've seen first how "less meetings" can be applied to a fault. And the team members with average or below comm skills suffered, as did the rest of the team.
An entire team simultaneously in flow is a wonderful ideal, but the reality is that's very rare (read: often a waste of energy). Accept the friction, monitor what works and what doesn't, and operate around thst