6 ms·
> quick, synchronous audio/video communication between teammates ..."kill it with fire" or other equivalent meme is the proper response to this, no matter how
by nnq 7y ago
> quick, synchronous audio/video communication between teammates
..."kill it with fire" or other equivalent meme is the proper response to this, no matter how wonderfully it is executed.
Really, what everyone needs is more asynchronous communication and less attention draining and less interruptions! This can only help very small teams of extroverts with very-very-similar personalities work, it brings HELL for everyone else! And creates a homogenous bubble by locking people with different personalities out of the loop because they can't stand being in it.
We should put more time into bringing to the future ASYNCHRONOUS communication tools that WORK FINE, like email, comments in project-management-systems (eg. in Trello, Asana etc.)... we need more and better of these! (And without compromising them by adding push-notification and crap that makes them synchronous and attention grabbing.)
- kfoley 7y agoI think there's a place for synchronous communication as long as it's followed up by sufficient asynchronous communication such that people aren't left out. Sometimes it's a lot faster/easier to be able to get on a 5-10 minute call to discuss something and be able to look at it together instead of sending messages back and forth for a week trying to get a point across / understand someone else's point.
- state_less 7y agoNot sure if this startup is only doing 1-to-1 or it's 1-to-n, but if they start allowing 1-to-n, they'll likely run into problems. A walkie-talkie system will likely fail for larger group sizes (e.g. >8) or more due to cross talk that will build up on a common channel. In the marine environment where ‘walkie-talkies’ are still in use, folks have worked around the problem by monitoring the common channel, 16, for interruption and then negotiate a switch to a less common channel to complete the conversation. In the long run, maritime folks will likely switch to TCP/IP to address, route and communicate more efficiently rather than the walkie-talkie system. This sort of thing crops up in the office when a scrum master says to take it 'offline' in a standup, or when an open office gets big enough to have a din of conversations all going on at once.
- lukethomas 7y agoTotally agree - I wrote a rebuttal to the concept of "virtual office" tools for distributed teams a few minutes ago: https://www.friday.app/remote-work-virtual-office https://www.friday.app/remote-work-virtual-office
- dsaffy 7y agoThis is a really thoughtful response! FWIW, we believe the future involves both sync and async tools. Friday seems like it could be helpful on the async side.
- gregmac 7y agoWe also need more awareness of when to use async vs sync, and what tools are what. Some people treat email and chat like sync communication, getting annoyed if there isn't a response within a short time. Ever have someone walk up or use chat to ask "did you get my email (that I just sent 5 minutes ago)?" Async is great for initiating conversations or going back and forth a couple times. Go much more than that, and sync often (though not always) becomes easier and faster. An example of an ideal flow to me: Person A (12:34): hey, I'm trying to implement this new API call, but the parameters we came up with kind of conflict making it more complex than we thought Person B (12:52): Hmm, maybe there's a way we can simplify those. Have time within the next hour to meet/conf/video chat on it? A (12:55): just about to grab lunch, how about 1:30? B (12:56): ok A (1:26): alright, back, ready anytime B (1:29): (initiates video chat) (At end of call): ok, let's run this past rest the of the team and give us a day or so to think about it, and see if anyone has objections or we think of other implications. I'll send an email summarizing.
- lukethomas 7y agoIf anyone wants to dig into when to use sync vs. async, I strongly recommend learning about "grounding" when communicating: https://en.wikipedia.org/wiki/Grounding_in_communication#Grounding_in_machine-mediated_communication https://en.wikipedia.org/wiki/Grounding_in_communication#Gro...
- IanCal 7y agoI'm not an extrovert and I'd like this for people asking me questions. Want to disturb me for 2 minutes and ruin my concentration losing me half an hour? If it's going to save you your afternoon - just do it. If you're probably going to send me a message on slack or call me there anyway I'd find this a lot less annoying. My goal should never be to get through the most work myself it's to move the company forwards. Having someone wait until tomorrow to get their job done because I haven't manually gone and checked my emails is a waste of company time. Each to their own, and I don't think everyone would want to use something like this, but don't assume that it's only small teams and very similar extroverts that could benefit.
- SamuelAdams 7y agoI'm with you on this. I don't understand the HN mentality of "100% performance at all working hours". Many employers do not need you to be highly performant all the time, but they do need you to be available all the time. I'm also reading the Phoenix Project [1], and there's a worker Brent who knows every system well and can fix any issue. However, he is supposed to be working on the big company project (think like an ERP system). However, he can't get that work done because everyone and their brother keeps asking for a "quick" five minutes of his time, several times a day. All in all, he is not able to get his assigned tasks done because he's so busy with other interruptions. If that happens then yes, talk to your direct report and come up with a better solution. But you shouldn't need to block out every interruption ever. There are times when it is warranted. [1]: https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262592 https://www.amazon.com/Phoenix-Project-DevOps-Helping-Busine...
- Zenst 7y agoInstant messaging allows you to set status and busy messages - alas the interface isn't organic as changing it would also disturb your flow. Also the ability to control actions based upon what status you set is not granular or controllable enough. For example - if busy - only allow some people to send video mail message or IM for later perusal or if some people contact allow them thru if call more than twice, three times.....or if Director - instantly. Equally, to set a response time so if somebody in group A calls, make sure you call them back within an hour, two hours....10 mins etc. Details and control like that. But back to changing that status, that is the important aspect that needs addressing as currently it in itself distracts from your workflow and having some setup that allows easier access. So if your in say vi, editing a system file - it sets you as busy, if your reading the news - your available, if you're reading email - your semi-busy and some people get thru, some don't. So a system that detects when your busy, and sets your status would be the biggest improvement in work communications and in effect what we are reproducing is the personal assistant. An intelligence that screens your communications and handles what and when things get to interrupt you. That is for me the area in most need of some revitalisation.
- cs02rm0 7y agoThe remote working place I'm at has a policy of starting with video calls, then voice if video isn't available, down to IM, then email. I'm not an extrovert at all, but I quite like it. We are a relatively small dev team - maybe 5/6 people within a company of 30 or so who we talk to less. It's generally faster to communicate like that, with the benefit that you get to know the people you work with a little. Just clicking on an individual's face and being able to talk to them without acceptance does feel like a step too far to me though. That said, some years ago now, a colleague and I were saying it might be useful to have a teamspeak-style voice room where anyone in the team could join/leave at will but it meant you could push-to-talk to the room if you wanted to. The idea being that people could share their frustrations easily so the team could help them out rather than have them feeling alone and unable to hit the dial button to ask for help from a specific individual. And you could always leave. We never got around to setting that up though.
- CathedralBorrow 7y agoI'll never tire of these responses to use case stories that essentially state: "This is wrong because it doesn't work for me. Really, what everyone needs is more of what works for me."
- pts_ 7y agoThese Use Cases are literally pushing what works for them.
- CathedralBorrow 7y agoThere has to be a meaningful difference between "Here's something that works for us and might work for you" and "That's wrong, what everyone needs is this thing here"
- laurex 7y agoCurious, have you looked for solutions that work this way? (Disclosure: I am a researcher for a tool that works this way, but is aimed at a different market).