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

61–70 of 110 posts

Re: Working asynchronously

#61

Post by bwb »

3bodyProblem wrote: post #49

There are basically only a few things I agree with in this article, the rest is so shortsighted and heavily tunnel-visioning about some ideal world. The thing I agree with, yes being distracted takes time, focus and productivity. I'm all for being more into more deep work etc. Also the part of people need to be proactive rings true of course. But I fail to see how something that evident really needs a graph. But the…

I do think you can try to measure it, and we are taking a stab at it with an app that analyzes your online calendar app, you can see an example report here: https://app.shepherd.com/personal-report/sample/pages/my-wor...

It isn't perfect but we try to show how the meetings split apart your day and your capacity to do deep work.

Re: Working asynchronously

#62

Post by thrower123 »

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…

This is one of those cases where a picture is worth a thousand words. It's amazing to me sometimes how many support requests I get where there is no information about what is wrong, no screenshots, no log files, not even a couple sentences about what they were trying to do and what they expected to happen.

Although it's almost worse when they send along a JPEG screenshot that has been downsampled >50%, so all the details are too blurred to make out.

It's especially frustrating when you're dealing with timezone shifts that make the average time to get a round-trip email reply from the other person take a dozen hours or more

Re: Working asynchronously

#63

Post by marcelo_lebre »

3bodyProblem wrote: post #49

There are basically only a few things I agree with in this article, the rest is so shortsighted and heavily tunnel-visioning about some ideal world. The thing I agree with, yes being distracted takes time, focus and productivity. I'm all for being more into more deep work etc. Also the part of people need to be proactive rings true of course. But I fail to see how something that evident really needs a graph. But the…

Everything we do professionally can be a recipe for burnout. We also have strong policies to prevent it but that's another topic altogether.

A "short-ish" article written in an afternoon has no hopes of being a tablet of truth, just some anecdotal examples and ideas I've experienced over the years.

I fundamentally agree with the "Be human..." part, that's all you need if common sense is common around your workplace. Unfortunately it often isn't and you need to offset the unbalance to find equilibrium.

Re: Working asynchronously

#64

Post by thrower123 »

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…

Agenda? Minutes? I've heard tell of such a thing, but I've yet to meet a manager that actually performs these arcane acts. I've gotten very used to walking into meetings with no more idea of what's going to happen than I can glean from the participants list and the subject on the calendar item...

Re: Working asynchronously

#65

Post by benatkin »

sergiotapia wrote: post #56
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.

It's not the domain name I have an issue with, it's the brand. Other domains about an abstract concept such as care.com and art.com have .com in their logo. Some, unfortunately, don't. I've seen tech companies take over other terms and I don't want it to happen to the term "remote".

As for testingjavascript.com, it isn't comparable. It's two words and a lot more specific than "remote".

Re: Working asynchronously

#66

Post by sergiotapia »

xxpor wrote: post #12
zrail wrote: post #8

Earlier quoted context omitted.

If only job interviews could be async!

Companies have actually done that, and it's worse: They're the "homework" interviews.

I'm hiring for our team. All of the feedback I've gotten from candidate was that it's fantastic because of the take home interview. No need to sweat and tremble over whiteboard questions.

Do you prefer those?

Re: Working asynchronously

#67

Post by lukethomas »

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-…

Here's a helpful rule of thumb for when to use synchronous communication:

Is the conversation ambiguous and is there a high likelihood that you will be misunderstood?

An obvious tell for this is when you go back-and-forth over Slack/chat for a few minutes and people still feel like they are on another page.

I strongly recommend checking out media richness theory. It presents a helpful way to think about what communication medium is most appropriate for a given scenario.

https://en.wikipedia.org/wiki/Media_richness_theory

Re: Working asynchronously

#68

Post by m0zg »

What I've discovered is your team needs to be fairly senior already for this to work at all. I once worked with a team where, shall we say, "talent" was extremely uneven, and it was pretty miserable. It was a very small team, only 3 people, and one of the 3 saw no issues with "synchronizing" threads with wait/sleep loops, paid no heed to coding standards, and just in general turned in shit code others had to waste their time to fix later. Worse yet, he was extremely defensive about any issues we brought up, to the point of not even hearing what we actually say. In his mind, any critique of his code was a personal attack and nothing else. Code reviews were multi-week affairs, leaving him extremely pissed off, and what got checked in was still below par compared to what the other 2 devs were producing.

If that person were in the same office, it'd be much easier to browbeat him into compliance and teach/mentor him. But he was halfway across the globe, so we suffered through it for ~6 months and then let him go, further reinforcing his belief he was being personally attacked. Not a good parting of ways.

Re: Working asynchronously

#69

Post by k__ »

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-…

"In my experience, the biggest pitfall is when developers try to force 100% asynchronous communication at all costs,"

In my experience, the biggest pitfall is when non-developers try to force 100% synchronous communication at all costs.

I always had the experience that there is a struggle to get people to accept async work because everyone thinks it's normal to call everyone all the time.

Re: Working asynchronously

#70

Post by cpeterso »

People hate meetings because they're in bad meetings. We spend so much time in meetings without giving them much thought to designing them. I highly recommend the book "The Surprising Science of Meetings: How You Can Lead Your Team to Peak Performance". It covers different types of meetings, including remote meetings and when not to have a meeting. This podcast interview with the author is a good introduction to the book:

https://www.gayleallen.net/cm-127-steven-rogelberg-on-making...

Post reply on HN