Great now how do I convince my team this is a good idea, overcoming super ingrained and traditional working concepts?
One step at a time. And if that doesn't work, then you find another team ;)
Working asynchronously
41–50 of 110 posts
Re: Working asynchronously
#42I would love to, but my coworkers expect me to be synchronous. They do async, but I'm always supposed to be sync with five nines availability. Looks like it's time to go job-hunting again, but I hate job interviews. Dammit.
At the end of the day your mental health is worth a lot more than a few interviews ;)
Interviewing generally has a significantly negative impact on your mental health... but at least it's temporary.
Re: Working asynchronously
#43I 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 just use existing tool X to solve this problem?"
Communication is hard. Engineers use buzzwords. Product uses buzzwords. Companies use buzzwords. Combine all these and you get a soup of overloaded terms e.g. "service," "connect," "access," "resource," "platform" that have a wide range of potential meanings.
Re: Working asynchronously
#44I think it’s armful to the idea of remote work that it’s being equated with async work.
Async work is but a tool, a methodology, remote is a way of life/work. I advocated async work when working office-based as well, the same principles still apply.
Re: Working asynchronously
#45I'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…
Better to figure that out in a 15-minute sync up than to get a pager duty alert from a Blocker level ticket that your "service is broken"
Re: Working asynchronously
#46I'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 always hated "15 minutes of real-time conversation", not because of being an introvert or anything, but because it's fuzzy, nobody remembers what it was exactly said, and usually ends up with people wasting each others time (like Diltert-style meetings)."
I'd say the solution is to attack those problems directly.
There are some things that just work poorly asynchronously. I find heavy-duty explanations of something, where you need the highly-interactive back-and-forth is necessary, and honestly, even just trying to type something is wasting minutes vs. saying it, is a common use case for me. Getting 4 half-distracted managers who are lobbing emails at each other into a quick conference to resolve the matter is sometimes a really good idea, too, because the "lobbing emails at each other" is a political minefield. A lot of potential for hurt feelings and miscommunication that can be avoided just getting everyone in live voice chat, with their full attention, for even just 5 minutes sometimes.
Re: Working asynchronously
#47This 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 stop reading there. Only people who can say “upward revenue stream dynamics” with a straight face will read on.
A single logical sentence has more value than a page full of poorly written false claims and regurgitated platitudes.
Re: Working asynchronously
#48I would love to, but my coworkers expect me to be synchronous. They do async, but I'm always supposed to be sync with five nines availability. Looks like it's time to go job-hunting again, but I hate job interviews. Dammit.
>I would love to, but my coworkers expect me to be synchronous. They do async, but I'm always supposed to be sync with five nines availability.
Looks like it's time to go job-hunting again, but I hate job interviews. Dammit.
I hate interviewing too, but don't let that stop you! Learning to be great at things we avoid/dislike improves us as human beings. It is important to be happy with the work we do.
Re: Working asynchronously
#49There 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 issue I take with articles like this is that they think of humans as robots. That walk in, or sit in front of their computer at 9, type for 8 and then go home/stop working.
But let's be honest here, If you can keep highly focused for more than 4 hours a day you are a superhuman. I know keeping this in mind doesn't take anything away from the article. Yes we should focus more on Async productivity, but work our work is definitely not single threaded. We are humans, If I hear my teammate 2 desks over signing for the 3rd time I can do 2 things. Ignore it, not getting out of my flow. Or stand up, talk to him/her and see whats up. Maybe it's only a complain about Entity Framework migrations being a b or perhaps just tired, and gets annoying by small things because something happened last night and its time to vent a bit.
recently I've started listening to this podcast https://hurryslowly.co/ . Although I do not identify with everything discussed, I do think there is source of truth in a few episodes. It just makes me consider, are we optimizing the right things first?
I really wonder, if all this no meetings, no distractions is really the key to making us more effective at our jobs. You can't really measure it, does the hour in a meeting really makes you an hour less productive? Is it more like 15 min? Or did the distraction actually helped instead of bashing your head against the wall for over on hour trying to figure out the solution?
I wonder the same about all those gosu vim/emacs users, it sure looks fancy dancing with your fingers doing edits. But where does the real work happen? Is is the amount of lines written or the amount of quality information processed in my mind about the solution I'm looking for?
In the end..
- Be human - Try to have clear borders about distractions in your team - Turn all slack notifications off - Don't have meetings that could have been an email. - Don't send emails about stuff that could have been a meeting
I'm really curious about working in a distributed team though, sadly I didn't really had the chance yet. I think working remote has it own con's and pro's.
I do applause the auther for thinking about this, I think reflecting on how to work better is always a good idea. But It could also easily be a recipe for a burnout.
Re: Working asynchronously
#50I 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…
You might be right but you also dont seem to be making room for the possibility of improving, learning, and making it easier to write those docs. You dont need to have a blank piece of paper and average engineers shouldnt need to guess how to fill in a memo.