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-time conversation rather than 3 days of back-and-forth e-mails. If the team is willing to fall back to synchronous comms when necessary, then defaulting to async communication for the other 95% of communication can work.
In my experience, the biggest pitfall is when developers try to force 100% asynchronous communication at all costs, no matter how slow and inefficient it becomes for everyone else. All team members must be willing to recognize when synchronous communication is necessary and carve out 15 minutes to an hour a couple times a week for those important, synchronous conversations.
Efficient communication is everyone's responsibility, and asynchronous communication is only a win if it doesn't create unnecessary extra work for everyone else.
I think that there is a tragedy-of-the-commons issue here that some teams or organizations just aren't very good at tackling.
Everyone's time is a valuable resource. It's quick and easy to demand synced communication, but that depletes the time people can dedicate to longer tasks that should not be interrupted.
Now take the team's collective time. That's the commons, and poor work discipline drains that shared resource. It takes discipline to write procedures, policies, boring documentation, or to make sure that the authoritative source of truth for your project still reflects reality.
Those 3 days of back and forth emails, or the 15 minute working session, may need to exist for some situations. However I've found that people can work to reduce those 3 days to several hours as long as the answers to some questions are available in up to date documentation.
I have a couple of team members right now who don't want to write certain documentation, or don't feel they need to edit existing documentation to improve its legibility. The most often heard excuse has been "it only takes me 15 minutes on a call to do the task". Which may seem fine from that perspective. That person doesn't realize that they've spent multiple days worth of hours spending 15 minutes on something when if they had spent 2 hours writing the documentation, they'd be saving precious time and priceless context switching.
(I'm a new team lead. I'm enjoying it greatly, and find these sorts of inefficiencies both fascinating and revolting)
>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 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 much rather people knew how to communicate effectively on chat.
But people don't, so you get messages like:
"The service is broken!"
"[panicked] What do you mean? Is it down?"
"It doesn't show anything"
[still panicked] Really? Let me see... Hmm, I see it working properly, loaded the first page and everything. What do you see?"
"I don't see anything"
"[???] On the first page? On some specific panel? Have you entered something?"
"Entered? I clicked and got nothing"
... and after 20 more minutes you realize they are on the third tab of a particular page, which nobody ever uses, have entered some search term people seldom enter, and got no results there, and everything else is working fine...
"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.
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.
This has 100% been my experience as well. All too often it's seen as an all or nothing thing, and it's the parts where discussions should be handled on calls that give it a bad image.
How exactly would you identify such a situation when a real-time conversation is more productive? And do you think that everyone involved agrees in the same way on this?
It would be interesting to analyse such situations further, and maybe there are actually ways to resolve it in a more productive and efficient way which does not require real-time conversation.
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 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.
It really depends on the meeting. Meetings that revolve around basic information sharing (typically the recurring ones) like status updates or daily scrum can 100% be replaced with a written update. These are the meetings people hate.
A great meeting is when the right number of people discuss an ambiguous problem that requires a fast feedback loop (body language, tone, etc) in order to achieve the desired meeting outcome.
I'd also argue that poor documentation is a result of lack of structure (something asynchronous communication can provide much better vs. synchronous comm)
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?"
A lot of engineers hate documentation and meetings. It's their managers job to make sure they do the boring stuff that the organisation needs.
If a manager says "remember to do some meetings" at the start of the year then never follows up on ensuring those meetings are actually effective, those meetings might be a waste of time. If they say "remember to do some documentation" at the start of the year and never follows up the documentation will be a waste of time.
If managers are spending more time making meetings a big priority, maybe it's because unlike documentation they get to feel like a real leader because they are running effective meetings. Maybe managers just like meetings more than documentation. Maybe it's higher value to the organisation as a whole, but I doubt it.
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.
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.
I feel like there is an insight here about working by yourself, too, that I cannot quite put my finger on.
Even if there is no team, you don't want to self-interrupt your own work. Well, we know that hence we invest in internet blockers etc.
However, if you are interrupted, it is best if you recover quickly. That is to say, if you can set up your own work so that it is planned in bite size components, and you know exactly where to pick up, you are better off.
This is like making an outline, and keeping track of where you are in the outline, except at the level of detail you need (say 5 min increments). Or perhaps you have a short hand of tracking where you are during an interruption.
So, if someone says excuse me, you take 12 seconds to quickly note what you were about to do, and if you are about to self interrupt, you do something similar.
I've learned to take a lot of notes, make frequent checkpoints (e.g., git commits), and break things down into small pieces, just to deal with interruption--minute to minute (people asking me questions), day to day (fire drills, bugs), and week to week (constantly changing priorities).
I agree with this, but there's a pitfall. Lets say you want to get conversation done at either the start/end of day or both. This is efficient because then you can work interrupted throughout the day. However, when you're not available to answer every ping right away or your "online" status isn't green, then it puts you in a bad light because the managers think you aren't working and/or don't care/aren't a team player.
I find I do much better at coming back to solo/personal stuff if I use an issue tracker anyway, even in the early stages where I'm not so much managing bugs as chunking into bite-size pieces as you describe, so I always try to do that now.
It makes me less likely to leave the repo with some staged changes, some unstagrd changes, and no idea what I was doing when I come back to it - but even if that does happen it makes it easier to work out.
Not directly related to the post, but something I've been thinking about a lot:
My life satisfaction and work productivity increased significantly when I stopped working from home and began working 8-5 at an office. There were so many things I took for granted:
- Face-to-face interaction with co-workers.
- Casual conversations to break up the day.
- The rhythm of a commute.
- Not struggling to find a spot in a crowded coffee shop.
- The productivity boost of working alongside other people who are working.
- The consistency and routine of normal working hours.
- The ability to pair program, in person.
- The ability to be productive with my team even if the internet is slow (or out completely).
I worked from home for six years, and I don't think I'd ever go back. I'm not saying remote doesn't have its place, but I've found that I greatly prefer working in-person with other people.
> 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.
I spend several years managing an all-remote team that ranged from Perth WA to Seattle WA. We worked 90% pure asynchronously and 10% using video chat (or physical get-togethers from time to time). It was highly productive, and because it was all open source development any lack of productivity would have been obvious.
I now commute to an office where we all work asynchronously but are expected to appear to work synchronously, as is traditionally expected. It is less enjoyable, frequently subject to context switches (you need to synchronize with the dominant worker) and certainly no more productive -- although that's hard to tell since everything is secret and need-to-know.
I would say working asynchronously is better for intellectual workers. Most intellectual work places that claim to working syncronously are either working under an illusion or under a bad manager with a "my synchrony" attitude.
I work on a distributed team on an asynchronous video app (Marco Polo) which makes a lot of conversations easier (sharing bugs, non-urgent conversations, personal connection) but we still Zoom for many meetings. Asynch has virtues even for in person teams but it just isn't optimal for everything, especially discussions leading to decisions that can then be executed upon.
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.
I dunno, it's just clever company naming, like Meetup. I don't think it's stealing an identity. It's also a risk for the company, because the trademark isn't defensible. Google's legal team doesn't like the fact that people use to google as a verb. The extreme form of that would be Microsoft being able to say, "Now you can google better with Bing!"
Love that you feel so passionate about it! We are part of that community, and we're doing this so that more people can enjoy working remotely as well. It changed my life in many positive ways and there's nothing we want to take away from it, quite the opposite. We own the domain, we don't own something that is a way of life for which we have tremendous respect.
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.
Ya that is a good one, we did something similar with meetings only on M/T/W, and any outside of that had to be directly product-related and engineer only.
This sounds great, and in theory should work on a well integrated team of autonomous individuals. I guess as in most things, common sense is the key requirement to make this a reality. Alas, common sense isn't very common...
I find using an asynchronous-first chat platform like Zulip (as opposed to Slack) is crucial to my ability to work asynchronously. Without compartmentalization of topics into mutable sub-topics, it becomes a huge mental burden to log onto chat every day.
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:
This is essentially the same problem schedulers run into. It's a latency vs throughput trade off. The article is underlining that blocking is bad, & lots of tasks may receive cancellation signals
I've worked in low latency environments, but I prefer high throughput. The latter is more conducive to flow state. It also means people aren't relying on my consistency, where some days my brain turns on & some days it doesn't
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.
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.
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 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.
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.
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.
What you need is a form of moderation. An actual group of workers who's job is to collect data, validate a test case is reproducible, or at least that there's telemetry of a problem having happened. In edge cases they could at least collect some data and try to isolate where a problem might exist so that better tests / data collection can occur.
[+] [-] PragmaticPulp|6 years ago|reply
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. If the team is willing to fall back to synchronous comms when necessary, then defaulting to async communication for the other 95% of communication can work.
In my experience, the biggest pitfall is when developers try to force 100% asynchronous communication at all costs, no matter how slow and inefficient it becomes for everyone else. All team members must be willing to recognize when synchronous communication is necessary and carve out 15 minutes to an hour a couple times a week for those important, synchronous conversations.
Efficient communication is everyone's responsibility, and asynchronous communication is only a win if it doesn't create unnecessary extra work for everyone else.
[+] [-] bloopernova|6 years ago|reply
Everyone's time is a valuable resource. It's quick and easy to demand synced communication, but that depletes the time people can dedicate to longer tasks that should not be interrupted.
Now take the team's collective time. That's the commons, and poor work discipline drains that shared resource. It takes discipline to write procedures, policies, boring documentation, or to make sure that the authoritative source of truth for your project still reflects reality.
Those 3 days of back and forth emails, or the 15 minute working session, may need to exist for some situations. However I've found that people can work to reduce those 3 days to several hours as long as the answers to some questions are available in up to date documentation.
I have a couple of team members right now who don't want to write certain documentation, or don't feel they need to edit existing documentation to improve its legibility. The most often heard excuse has been "it only takes me 15 minutes on a call to do the task". Which may seem fine from that perspective. That person doesn't realize that they've spent multiple days worth of hours spending 15 minutes on something when if they had spent 2 hours writing the documentation, they'd be saving precious time and priceless context switching.
(I'm a new team lead. I'm enjoying it greatly, and find these sorts of inefficiencies both fascinating and revolting)
[+] [-] coldtea|6 years ago|reply
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 much rather people knew how to communicate effectively on chat.
But people don't, so you get messages like:
"The service is broken!"
"[panicked] What do you mean? Is it down?"
"It doesn't show anything"
[still panicked] Really? Let me see... Hmm, I see it working properly, loaded the first page and everything. What do you see?"
"I don't see anything"
"[???] On the first page? On some specific panel? Have you entered something?"
"Entered? I clicked and got nothing"
... and after 20 more minutes you realize they are on the third tab of a particular page, which nobody ever uses, have entered some search term people seldom enter, and got no results there, and everything else is working fine...
[+] [-] k__|6 years ago|reply
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.
[+] [-] marcelo_lebre|6 years ago|reply
[+] [-] lukethomas|6 years ago|reply
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
[+] [-] hanniabu|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] albertzeyer|6 years ago|reply
It would be interesting to analyse such situations further, and maybe there are actually ways to resolve it in a more productive and efficient way which does not require real-time conversation.
[+] [-] alexandercrohde|6 years ago|reply
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.
[+] [-] lukethomas|6 years ago|reply
A great meeting is when the right number of people discuss an ambiguous problem that requires a fast feedback loop (body language, tone, etc) in order to achieve the desired meeting outcome.
I'd also argue that poor documentation is a result of lack of structure (something asynchronous communication can provide much better vs. synchronous comm)
[+] [-] tonyarkles|6 years ago|reply
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?"
[+] [-] wisty|6 years ago|reply
If a manager says "remember to do some meetings" at the start of the year then never follows up on ensuring those meetings are actually effective, those meetings might be a waste of time. If they say "remember to do some documentation" at the start of the year and never follows up the documentation will be a waste of time.
If managers are spending more time making meetings a big priority, maybe it's because unlike documentation they get to feel like a real leader because they are running effective meetings. Maybe managers just like meetings more than documentation. Maybe it's higher value to the organisation as a whole, but I doubt it.
[+] [-] thinkingkong|6 years ago|reply
[+] [-] marcelo_lebre|6 years ago|reply
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.
[+] [-] eeZah7Ux|6 years ago|reply
Yes. Don't hire the average engineer.
[+] [-] omarhaneef|6 years ago|reply
Even if there is no team, you don't want to self-interrupt your own work. Well, we know that hence we invest in internet blockers etc.
However, if you are interrupted, it is best if you recover quickly. That is to say, if you can set up your own work so that it is planned in bite size components, and you know exactly where to pick up, you are better off.
This is like making an outline, and keeping track of where you are in the outline, except at the level of detail you need (say 5 min increments). Or perhaps you have a short hand of tracking where you are during an interruption.
So, if someone says excuse me, you take 12 seconds to quickly note what you were about to do, and if you are about to self interrupt, you do something similar.
[+] [-] epylar|6 years ago|reply
[+] [-] hanniabu|6 years ago|reply
[+] [-] OJFord|6 years ago|reply
It makes me less likely to leave the repo with some staged changes, some unstagrd changes, and no idea what I was doing when I come back to it - but even if that does happen it makes it easier to work out.
[+] [-] jahbrewski|6 years ago|reply
My life satisfaction and work productivity increased significantly when I stopped working from home and began working 8-5 at an office. There were so many things I took for granted:
I worked from home for six years, and I don't think I'd ever go back. I'm not saying remote doesn't have its place, but I've found that I greatly prefer working in-person with other people.[+] [-] gatherhunterer|6 years ago|reply
> 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.
[+] [-] bregma|6 years ago|reply
I now commute to an office where we all work asynchronously but are expected to appear to work synchronously, as is traditionally expected. It is less enjoyable, frequently subject to context switches (you need to synchronize with the dominant worker) and certainly no more productive -- although that's hard to tell since everything is secret and need-to-know.
I would say working asynchronously is better for intellectual workers. Most intellectual work places that claim to working syncronously are either working under an illusion or under a bad manager with a "my synchrony" attitude.
[+] [-] laurex|6 years ago|reply
[+] [-] benatkin|6 years ago|reply
[+] [-] xapata|6 years ago|reply
[+] [-] sergiotapia|6 years ago|reply
Do you feel the same about testingjavascript.com? It's just a lucky domain or they spent a lot of cash on it. Relax.
[+] [-] marcelo_lebre|6 years ago|reply
[+] [-] z3ugma|6 years ago|reply
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.
[+] [-] 0xffff2|6 years ago|reply
[+] [-] bwb|6 years ago|reply
[+] [-] mlashcorp|6 years ago|reply
[+] [-] nikisweeting|6 years ago|reply
[+] [-] cpeterso|6 years ago|reply
https://www.gayleallen.net/cm-127-steven-rogelberg-on-making...
[+] [-] __s|6 years ago|reply
I've worked in low latency environments, but I prefer high throughput. The latter is more conducive to flow state. It also means people aren't relying on my consistency, where some days my brain turns on & some days it doesn't
[+] [-] m0zg|6 years ago|reply
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.
[+] [-] konschubert|6 years ago|reply
[+] [-] marcelo_lebre|6 years ago|reply
[+] [-] davidw|6 years ago|reply
Their "async planning" bit doesn't mention context switching though, which is an important omission.
[+] [-] 3bodyProblem|6 years ago|reply
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.
[+] [-] marcelo_lebre|6 years ago|reply
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.
[+] [-] bwb|6 years ago|reply
It isn't perfect but we try to show how the meetings split apart your day and your capacity to do deep work.
[+] [-] komali2|6 years ago|reply
[+] [-] marcelo_lebre|6 years ago|reply
[+] [-] crtlaltdel|6 years ago|reply
[+] [-] mjevans|6 years ago|reply
[+] [-] the-dude|6 years ago|reply
[+] [-] jobvandervoort|6 years ago|reply