Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Working asynchronously

blog.remote.com

Post reply on HN
Print view View original

51–60 of 110 posts

Re: Working asynchronously

#51

Post by manifestsilence »

coldtea wrote: post #38
PragmaticPulp wrote: post #9

I've managed multiple remote, asynchronous teams across multiple countries. When people work in opposite time zones, asynchronous communication is mandatory. When it works, it's a great experience. However, async communication isn't appropriate for every situation, as the article admits. Some times, the most efficient way forward is to schedule a call where all parties can work out the solution in 15 minutes of real-…

> When it works, it's a great experience. However, async communication isn't appropriate for every situation, as the article admits. Some times, the most efficient way forward is to schedule a call where all parties can work out the solution in 15 minutes of real-time conversation rather than 3 days of back-and-forth e-mails. I always hated "15 minutes of real-time conversation", not because of being an introvert or…

I think the chat in this example still basically counts as synchronous, and the issue is more to do with people being poor at organizing their ideas in text vs. spoken conversation.

Truly asynchronous communication would force them to put their whole thought down on paper at once and perhaps organize it better, or at least allow you to skim. But then of course, async is poor for time sensitive issues anyway.

Re: Working asynchronously

#52

Post by tonyarkles »

alexandercrohde wrote: post #43

I want to call BS on the statement "Most meetings can be replaced with documentation." Maybe in an ideal world, but no. Have you tried reading the documentation the average engineer makes? It's like a freshman essay -- lacking in cohesion, vision, context. It's usually completely unstandardized across teams. And 9 times out of 10 the most fundamental questions aren't answered by the documentation e.g. "Why don't we j…

This is tongue firmly in cheek, but I think it really drives home your "Communication is hard" point.

Have you tried reading the meeting agenda and minutes the average engineering manager makes? It's like a freshman essay -- lacking in cohesion, vision, context. It's usually completely unstandardized across teams.

And 9 times out of 10 the most fundamental questions aren't answered in the meetings e.g. "Why don't we just use existing tool X to solve this problem?"

Re: Working asynchronously

#53

Post by 0xffff2 »

z3ugma wrote: post #18

The way we've struck a balance at our company is to only allow meetings in the mornings. In the afternoon, everyone can be off Slack, heads-down, and programming or doing other deep work. This halves the number of timeslots that are available to have time stolen from you, but allows us to get the empathy and quick resolution that real-time communication enables.

I guess it's impossible to please everyone, but I would be miserable with this setup. I'm far more productive in the mornings and have managed to keep most of my meetings in the afternoon so they don't interfere with my productive time. Only allowing meetings in the mornings would probably cut my productivity in half or more.

Re: Working asynchronously

#54

Post by marcelo_lebre »

gatherhunterer wrote: post #47

This is managerial nonsense. > An even, swift and nimble pipeline produces exactly the right quantity of output for its requirements, and all its stages are balanced in terms of efficiency and speed. Resulting in no waste of time or resources. Aside from containing neither a subject nor a verb, this last sentence is an impossible claim. Anyone who intends to hold the author to the quality of their reasoning would sto…

I've been a manager of different teams for a while now and I must admit that every form of management or productivity strategy is nothing but written nonsense in good form - or common sense in fancy terms.

Re: Working asynchronously

#55

Post by xboxnolifes »

coldtea wrote: post #38
PragmaticPulp wrote: post #9

I've managed multiple remote, asynchronous teams across multiple countries. When people work in opposite time zones, asynchronous communication is mandatory. When it works, it's a great experience. However, async communication isn't appropriate for every situation, as the article admits. Some times, the most efficient way forward is to schedule a call where all parties can work out the solution in 15 minutes of real-…

> When it works, it's a great experience. However, async communication isn't appropriate for every situation, as the article admits. Some times, the most efficient way forward is to schedule a call where all parties can work out the solution in 15 minutes of real-time conversation rather than 3 days of back-and-forth e-mails. I always hated "15 minutes of real-time conversation", not because of being an introvert or…

> I'd much rather people knew how to communicate effectively on chat.

> But people don't, so you get messages like:

So what you're saying is that you don't actually mind the 15 minutes of real-time chat, what you mind is that some people don't know how to effectively communicate.

Re: Working asynchronously

#56

Post by sergiotapia »

benatkin wrote: post #31

I get the idea that remote.com is trying to trademark the term "remote". F that. The best way to stop that is to prevent remote.com from getting a lot of brand recognition. I don't care how much they want to contribute to the remote worker community - there's no way it will make up for stealing the identity that we have for ourselves.

Nah it's just a lucky domain name, nothing more.

Do you feel the same about testingjavascript.com? It's just a lucky domain or they spent a lot of cash on it. Relax.

Re: Working asynchronously

#57

Post by crtlaltdel »

imo think twice add a “bugs” channel to your slack/chat. it invariably gets used as a place to inject panicky statements, ask for status and features...just make sure whatever ticketing system you have is well understood by all stakeholders.

Re: Working asynchronously

#58

Post by alexandercrohde »

tonyarkles wrote: post #52
alexandercrohde wrote: post #43

I want to call BS on the statement "Most meetings can be replaced with documentation." Maybe in an ideal world, but no. Have you tried reading the documentation the average engineer makes? It's like a freshman essay -- lacking in cohesion, vision, context. It's usually completely unstandardized across teams. And 9 times out of 10 the most fundamental questions aren't answered by the documentation e.g. "Why don't we j…

This is tongue firmly in cheek, but I think it really drives home your "Communication is hard" point. Have you tried reading the meeting agenda and minutes the average engineering manager makes? It's like a freshman essay -- lacking in cohesion, vision, context. It's usually completely unstandardized across teams. And 9 times out of 10 the most fundamental questions aren't answered in the meetings e.g. "Why don't we…

Yeah, but the point is, I can ask all of those questions in the meeting if I'm there in person.

Re: Working asynchronously

#59

Post by marcelo_lebre »

alexandercrohde wrote: post #43

I want to call BS on the statement "Most meetings can be replaced with documentation." Maybe in an ideal world, but no. Have you tried reading the documentation the average engineer makes? It's like a freshman essay -- lacking in cohesion, vision, context. It's usually completely unstandardized across teams. And 9 times out of 10 the most fundamental questions aren't answered by the documentation e.g. "Why don't we j…

Ah ah! I did and I do. That's why well written documentation is more than a "good to have", it's as important as the code itself, same as good tests.

Communication is always a challenge and no big or small company has fully cracked it for sure. Average engineers - whatever that means - need training and meaningful tutoring. The team should aim at becoming better, not settle for whatever they have at the moment.

Post reply on HN