3 ms·
I think asynchronous communication (https://blog.doist.com/asynchronous-communication/ https://blog.doist.com/asynchronous-communication/) moves in the right di
by ahussain 5y ago
I think asynchronous communication (https://blog.doist.com/asynchronous-communication/ https://blog.doist.com/asynchronous-communication/) moves in the right direction on this.
99% of things are not urgent, and people should not be expected to be available instantaneously. But implementing that requires discipline on the part of the person sending the message.
- ShroudedNight 5y agoI get the sense that the real problem isn't so much synchronous communication but the need to get information or reconcile state with a specific person. If any team member was equally capable of providing input, each individual would only have to poll 1/n as often
- o5ira 5y agoInteresting, but a person who prefers to poll once a day in the morning, perhaps, gets nothing because there's someone else who prefers to poll at the end of the day. How do you allow them the flexibility to design their schedule?
- ShroudedNight 5y agoMy best guess would be a pre-arranged "on call" schedule where a shuffled set of blocks of time are reserved / allocated to each team member
- lowercase1 5y agoThis seems good but falls apart with.long approval chains (which are maybe the core issue). If I need library PR approved so I can make a service 1 PR so I can make a production release request so that I can deploy a one line change then it's hard to get things done with 4 hour ping time.
- adamweld 5y agoalso see: https://basecamp.com/guides/how-we-communicate https://basecamp.com/guides/how-we-communicate