Virtual offices are not remote-friendly workplaces(mycodingtales.com)
mycodingtales.com
Virtual offices are not remote-friendly workplaces
https://mycodingtales.com/stop-pretending-your-company-is-remote/
108 コメント
I think a remote office is one where folks are remote. An asynchronous work place is one where work is done (IMO) efficiently. They aren’t the same - you can do asynchronous work in offices, some of the most effective global companies did this for decades already and when they went remote it was a smooth transition because, yes, remote works best when done asynchronously. But so does in office work.
I disagree with the premise. Remote workplace and asynchronous workplace are two different things. Perhaps they’re on a scale.
Remote work is not having to spend two hours every day commuting. Remote companies hire more broadly because they’re not limited to a single very specific geographic zone (while they may just limit themselves to time zones instead, regardless of the city/state/country).
To say this is not "remote" is a strange moving of the goal posts. It sounds like this person might work at a dysfunctional company, or they might actually be looking for an asynchronous company/team.
Edit: the great irony/timing of this is I’m currently mid flight meeting all my colleagues for the first time…
Remote work is not having to spend two hours every day commuting. Remote companies hire more broadly because they’re not limited to a single very specific geographic zone (while they may just limit themselves to time zones instead, regardless of the city/state/country).
To say this is not "remote" is a strange moving of the goal posts. It sounds like this person might work at a dysfunctional company, or they might actually be looking for an asynchronous company/team.
Edit: the great irony/timing of this is I’m currently mid flight meeting all my colleagues for the first time…
They don't even need to be on the same axis (although probably not really orthogonal in practice).
Async on-site work is entirely possible -- if you're working in a high-security place, or where the physical infrastructure is the point, or where you're building some physical object, it might make sense that work can only be done on site, but scheduling might be entirely up to you. Similarly remote but synchronous is easy to understand (calls, etc.). Another dimension is probably consistent vs. variable on both of those dimensions over time -- my ideal job is sync remote, sync in person, async in-person, and async remote at different times.
Async on-site work is entirely possible -- if you're working in a high-security place, or where the physical infrastructure is the point, or where you're building some physical object, it might make sense that work can only be done on site, but scheduling might be entirely up to you. Similarly remote but synchronous is easy to understand (calls, etc.). Another dimension is probably consistent vs. variable on both of those dimensions over time -- my ideal job is sync remote, sync in person, async in-person, and async remote at different times.
A remote first company almost has to encourage asynchronous workplace. Because expecting to have synchronous communication is just not very efficient. If everyone is in the office, you can observe if a person is busy, turn your chair and ask "do you have a sec", knock on their door, or walk into their cubical and interrupt their workflow.
But when everyone's working from home, you have less visibility on other people's availability. When you send a message to a person on slack, that person is likely doing something else, they may be working on something different, eating a meal, or even sleeping in another timezone. As a result, you should not expect people to always be ready to have a synchronous conversation with you.
To keep communication efficient in a remote workplace, you have to consider all these facts. People says "how are you" on slack to me everyday, not because they really care about how I am doing, nor do they love wasting time waiting for my response to that, but .simply because mentally, when they type messages in slack, their brain is still thinking about mimicking a face-to-face synchronous conversation. They only realize this is a problem after they are exposed on the recipient side frequently enough.
But when everyone's working from home, you have less visibility on other people's availability. When you send a message to a person on slack, that person is likely doing something else, they may be working on something different, eating a meal, or even sleeping in another timezone. As a result, you should not expect people to always be ready to have a synchronous conversation with you.
To keep communication efficient in a remote workplace, you have to consider all these facts. People says "how are you" on slack to me everyday, not because they really care about how I am doing, nor do they love wasting time waiting for my response to that, but .simply because mentally, when they type messages in slack, their brain is still thinking about mimicking a face-to-face synchronous conversation. They only realize this is a problem after they are exposed on the recipient side frequently enough.
Others pointed out the same. I agree with that too. But colloquially I've only ever seen the term "remote" being used, which is why I chose it.
I'd love to be able to search for jobs with the keyword "async" instead!
I'd love to be able to search for jobs with the keyword "async" instead!
>Remote work is not having to spend two hours every day commuting
Choosing a home and workplace that are reasonable in relation to each other is not having to spend two hours every day commuting. Voting for local politicans who will do reasonable housing and transportation planning and instead of suburban sprawl, is not having to spend two hours every day commuting.
Choosing a home and workplace that are reasonable in relation to each other is not having to spend two hours every day commuting. Voting for local politicans who will do reasonable housing and transportation planning and instead of suburban sprawl, is not having to spend two hours every day commuting.
Things change: you can plan and build the perfect city for today needs, it can be built and be that perfect for a bit of time, but can't evolve so sooner or later the disaster happen.
USA/CA suburbs does not work because they are residential-only and you generally need to commute, Rivieras does work far better IF they are not that dense, but in general there is nothing that keep working without changes eternally and as density grow changes became harder and harder. So it does not matter if you feel an USA failed sub-urb or an EU failed dense city or a too dense Riviera: they equally might work for a certain timeframe, than an "innocent & small" evolution at a time and things became ugly, perhaps in different ways, but with equal outcome.
No politicians can solve that, people's can't solve that because they can't always reach agreements.
That's for instance one of the reasons why we start saying since a decade at least that the "really sustainable transportation of the future" can only be by air and where possible by open water: you can change routes depending on needs, while you can't change much rails and roads, at least not with sustainable costs. That's why very few say that urbs aren't sustainable because they are effective for a certain timeframe than needs changes and they can't adapt etc.
Efficiency, resilience and sustainability are not much different than the CAP theorem, you can't have all, you have to choose just two. Seeing Darwin works personally I prefer the last two at the expense of the first one.
USA/CA suburbs does not work because they are residential-only and you generally need to commute, Rivieras does work far better IF they are not that dense, but in general there is nothing that keep working without changes eternally and as density grow changes became harder and harder. So it does not matter if you feel an USA failed sub-urb or an EU failed dense city or a too dense Riviera: they equally might work for a certain timeframe, than an "innocent & small" evolution at a time and things became ugly, perhaps in different ways, but with equal outcome.
No politicians can solve that, people's can't solve that because they can't always reach agreements.
That's for instance one of the reasons why we start saying since a decade at least that the "really sustainable transportation of the future" can only be by air and where possible by open water: you can change routes depending on needs, while you can't change much rails and roads, at least not with sustainable costs. That's why very few say that urbs aren't sustainable because they are effective for a certain timeframe than needs changes and they can't adapt etc.
Efficiency, resilience and sustainability are not much different than the CAP theorem, you can't have all, you have to choose just two. Seeing Darwin works personally I prefer the last two at the expense of the first one.
Sure, live where you want. That’s the point.
"Remote is about getting things done asynchronously."
Not necessarily. Consider a call center or help desk, or any form of customer service done remotely. Asynchronous and remote are different.
Not necessarily. Consider a call center or help desk, or any form of customer service done remotely. Asynchronous and remote are different.
Or software engineers. I've been working remotely for about 12 years with teams spread around the globe. In the decade or so before that I worked in various offices with coworkers scattered around the globe.
Async issues related to timezones or personal preferences are in no way unique to remote working.
Remote working is about location, not about time.
Over this past couple of decades, the only times that I have felt the need to announce my absence from the keyboard are when it is something out of the ordinary and unexpected. I never announce to the world that I am eating lunch, nor do I feel obligated to respond to IMs or other interruptions during any time that shows busy or out-of-office on my calendar.
Just like when I was in the office, if I need to step away from an active conversation for a few minutes for whatever reason, I'll let people know I need to step away and the estimated time of my return.
Async issues related to timezones or personal preferences are in no way unique to remote working.
Remote working is about location, not about time.
Over this past couple of decades, the only times that I have felt the need to announce my absence from the keyboard are when it is something out of the ordinary and unexpected. I never announce to the world that I am eating lunch, nor do I feel obligated to respond to IMs or other interruptions during any time that shows busy or out-of-office on my calendar.
Just like when I was in the office, if I need to step away from an active conversation for a few minutes for whatever reason, I'll let people know I need to step away and the estimated time of my return.
True. Someone else pointed out that some call it async work instead.
I've never heard companies say they're async though, only remote. The two seem to be conflated most of the time.
I've never heard companies say they're async though, only remote. The two seem to be conflated most of the time.
Most companies are just not async. That’s really hard to do I think!
It's the difference between using mostly meetings (real or virtual), IM and phone calls versus using mostly email. If you use mostly email for your comms it is perfectly possible to be both remote and async.
Most large companies are some combination of async and sync. If you have offices in the US and offices in Europe--much less Asia--you may have some hopefully not too inconvenient real-time calls. But you'll probably do a lot of things asynchronously. (And even within an office or within a country, a lot of people travel, have customer meetings, etc. so they're often just not immediately available.
I think OPs point is that that is not remote work -- it is officeless work. They are trying to make a distinction between the two.
Right, but development this is correct; if you're remote and require sync, you're not actually getting things done. Meetings are not the desired outcome; deployed, working code is. Communication is necessary, but not the output, and so to be effective you have to find ways to make that communication asynchronous wherever possible. It's fine to still have the -output- be synchronous (i.e., pairing), but don't confuse the default synchronous tasks (meetings) without output.
Anyway, all of that is a red herring; don't just tell me you're remote, tell me if you're prioritizing asynchronous work or not. The places trying to recreate the office, just now remote, are not places I want to work at.
Anyway, all of that is a red herring; don't just tell me you're remote, tell me if you're prioritizing asynchronous work or not. The places trying to recreate the office, just now remote, are not places I want to work at.
> Meetings are not the desired outcome; deployed, working code is
Maybe if all you want to do is code. I get the sentiment. If you're working on a product, getting input from team members and stopping bad ideas from making their way to the hands of the "don't bother me with meetings, I only want to code" person is important.
Maybe if all you want to do is code. I get the sentiment. If you're working on a product, getting input from team members and stopping bad ideas from making their way to the hands of the "don't bother me with meetings, I only want to code" person is important.
You seem to have completely ignored my "Communication is necessary, but not the output". Put another way, meetings are the 'how', not the 'what'. The how is not a deliverable, and so can be changed so long as the 'what' stays the same. You can get input, collaborate, etc, in other ways that are not synchronous.
We've all had that "this meeting could have been an email" experience. Make it an email. Start re-evaluating every meeting; any sort of unidirectional informational meeting can be offloaded onto a doc or recorded presentation just as efficiently. Bidirectional decisional meetings can often be done more effectively by writing up a problem statement, the various options, and a 'due' date for input. Allow people to read over it, comment, propose new suggestions, etc, then at that due date, hold a vote (can be done sync or async). Voila, a decision is reached that allowed for greater amounts of discussion, and was arrived at as democratically or 'loudest voice in the room' (if only a select few people's votes count) as you care to have it, rather than whatever organically happens in your meetings. Etc. In my experience what I'm left with are the meetings where it's the 'personal connection' that matters; these are things like the occasional AMA/Town Hall style meetings, and 1-on-1s. 90% of my pre-COVID meetings turned out not to need to be meetings.
We've all had that "this meeting could have been an email" experience. Make it an email. Start re-evaluating every meeting; any sort of unidirectional informational meeting can be offloaded onto a doc or recorded presentation just as efficiently. Bidirectional decisional meetings can often be done more effectively by writing up a problem statement, the various options, and a 'due' date for input. Allow people to read over it, comment, propose new suggestions, etc, then at that due date, hold a vote (can be done sync or async). Voila, a decision is reached that allowed for greater amounts of discussion, and was arrived at as democratically or 'loudest voice in the room' (if only a select few people's votes count) as you care to have it, rather than whatever organically happens in your meetings. Etc. In my experience what I'm left with are the meetings where it's the 'personal connection' that matters; these are things like the occasional AMA/Town Hall style meetings, and 1-on-1s. 90% of my pre-COVID meetings turned out not to need to be meetings.
I didn't ignore anything. The product is the output. Code is not the output. Your code is as much the output as communication is. Users don't care if you spent your time coding or in a meeting. They care if the product fulfills their needs. A meeting that stops a terrible redesign contributes as much the output as the heads down programmer who would have implemented it. Now I would hate to be in meetings all day, don't get me wrong. But I disagree that code is the output specifically for a product.
I have worked at software companies where meetings were indeed the desired outcome, even if no one said that part out loud.
Yeah, I have too. Oftentimes for business stakeholders and leadership, that is the case, as it helps justify their existence ("I was so busy!"). Which presents, unfortunately, opportunities for useless devs to glom on; sit in meetings, do no work, collect a paycheck.
The same old argument is really all that's in play here. "I want to spend most of my time doing the technical task that I'm skilled at, and not dealing with other people".
Developers add value in so many more ways that heads down concentrating on code. A senior engineer should spend the least amount of time coding compared to everything else they do during the day. If they don't, do you really need a senior engineer? How much of a 4 hour coding session is something you needed specific expertise in and how much is mindlessly typing the syntax with a big of logic peppered in?
If your tasks can all be done truly asynchronously without blocking someone else, they probably aren't very exciting or special. Having worked for many years in both office 9-5s and global async teams, async teams are incredibly frustrating to organize if the work requires any collaboration. In a perfect world sure your 4pm is my 8am and we can work there, but factor in real life, people leaving early, coming in late, and it becomes incredibly annoying to deal with in practice. It takes much more management overhead, and you truly have to ask if the benefit you get from having engineers async is really worth that extra overhead. I would argue in most markets it just isn't. I would take a 20% worse engineering staff all working together than the alternative of a better staff split into different time zones. This is coming from someone who lives in Iceland and has had to work async for the bulk of my projects in the last few years. I found the lack of human contact and collaboration so boring that I took a big paycut to work with people again every day.
Developers add value in so many more ways that heads down concentrating on code. A senior engineer should spend the least amount of time coding compared to everything else they do during the day. If they don't, do you really need a senior engineer? How much of a 4 hour coding session is something you needed specific expertise in and how much is mindlessly typing the syntax with a big of logic peppered in?
If your tasks can all be done truly asynchronously without blocking someone else, they probably aren't very exciting or special. Having worked for many years in both office 9-5s and global async teams, async teams are incredibly frustrating to organize if the work requires any collaboration. In a perfect world sure your 4pm is my 8am and we can work there, but factor in real life, people leaving early, coming in late, and it becomes incredibly annoying to deal with in practice. It takes much more management overhead, and you truly have to ask if the benefit you get from having engineers async is really worth that extra overhead. I would argue in most markets it just isn't. I would take a 20% worse engineering staff all working together than the alternative of a better staff split into different time zones. This is coming from someone who lives in Iceland and has had to work async for the bulk of my projects in the last few years. I found the lack of human contact and collaboration so boring that I took a big paycut to work with people again every day.
>A senior engineer should spend the least amount of time coding compared to everything else they do during the day. If they don't, do you really need a senior engineer? How much of a 4 hour coding session is something you needed specific expertise in and how much is mindlessly typing the syntax with a big of logic peppered in?
What else are they supposed to be doing? If requirements are fleshed out then all you can do is get started. The bigger the change, the more you'll have to be concerned about architecture and implementation details. I think sitting down and thinking about the problem before you code is necessary for any dev, but I'm here to write the solution at the end of the day.
>If your tasks can all be done truly asynchronously without blocking someone else, they probably aren't very exciting or special.
My company right now is about 15 people, 5 of which are engineering (including myself). When your team is that small, you don't have room for too many specialists. We're all capable individuals that can do the work without waiting for anyone. I'll get a ticket asking for a new web page, a new backend endpoint, DB updates, Et Cetera and it's the expectation that I do this all by myself. If there's something out of my wheelhouse, I can lean on my team but this is the exception and not the rule (and can still be done async). I don't know what special looks like for you but I can list the contributions I've made and the impact it has for our bottom line. In two months I reduced AWS spend by $5k/month, added payment enforcement logic netting us tens of thousands within the first week of its release, and seamlessly added a Huggingface NLP model into our AWS infra (our DevOps guy doesn't even know ML, he just treats the Sagemaker instance like any other resource). That's pretty impressive to me.
What else are they supposed to be doing? If requirements are fleshed out then all you can do is get started. The bigger the change, the more you'll have to be concerned about architecture and implementation details. I think sitting down and thinking about the problem before you code is necessary for any dev, but I'm here to write the solution at the end of the day.
>If your tasks can all be done truly asynchronously without blocking someone else, they probably aren't very exciting or special.
My company right now is about 15 people, 5 of which are engineering (including myself). When your team is that small, you don't have room for too many specialists. We're all capable individuals that can do the work without waiting for anyone. I'll get a ticket asking for a new web page, a new backend endpoint, DB updates, Et Cetera and it's the expectation that I do this all by myself. If there's something out of my wheelhouse, I can lean on my team but this is the exception and not the rule (and can still be done async). I don't know what special looks like for you but I can list the contributions I've made and the impact it has for our bottom line. In two months I reduced AWS spend by $5k/month, added payment enforcement logic netting us tens of thousands within the first week of its release, and seamlessly added a Huggingface NLP model into our AWS infra (our DevOps guy doesn't even know ML, he just treats the Sagemaker instance like any other resource). That's pretty impressive to me.
> My company right now is about 15 people, 5 of which are engineering (including myself)
The problem with posting any comment on here, is I have to always preface everything with "Generally speaking" I assume it's implied, but yes - you will always have cases where something isn't true. Tiny companies is one for sure, but tiny companies with 5 engineers, well collaboration isn't as much of an issue.
Most of us work at bigger companies than that (I would argue even on HN). I too have lived in the world where I was DBA, front end designer, API designer, infrastructure, and even contract negotiation, and that's a whole other ball of wax. It's also not what the original post is really talking about in my opinion. Companies like yours are not the ones trying to do in office work remotely, and those are the types of companies I am talking about.
On a side note your job sounds either fun or stressful as hell to me. I can't decide. I hope you're enjoying it and being paid well :)
The problem with posting any comment on here, is I have to always preface everything with "Generally speaking" I assume it's implied, but yes - you will always have cases where something isn't true. Tiny companies is one for sure, but tiny companies with 5 engineers, well collaboration isn't as much of an issue.
Most of us work at bigger companies than that (I would argue even on HN). I too have lived in the world where I was DBA, front end designer, API designer, infrastructure, and even contract negotiation, and that's a whole other ball of wax. It's also not what the original post is really talking about in my opinion. Companies like yours are not the ones trying to do in office work remotely, and those are the types of companies I am talking about.
On a side note your job sounds either fun or stressful as hell to me. I can't decide. I hope you're enjoying it and being paid well :)
It's my first startup, but so good so far. I chose one that was older (8+ years) and had a fun stack (Clojure). Doesn't pay as well as FAANG but I get some cool lottery tickets (RSU) out of it.
A senior engineer is someone you can point in the general direction of a business problem. They rarely get requirements, and never fleshed out. Their job is to understand the problem in consultation with stakeholders, guide a team through execution, and maybe but not always write or debug some critical parts.
As a senior engineer, if I told my manager in a performance review that I mostly worked alone on tickets with well defined requirements, I’d be on PIP immediately and probably fired a month later.
As a senior engineer, if I told my manager in a performance review that I mostly worked alone on tickets with well defined requirements, I’d be on PIP immediately and probably fired a month later.
>A senior engineer is someone you can point in the general direction of a business problem. They rarely get requirements, and never fleshed out. Their job is to understand the problem in consultation with stakeholders, guide a team through execution, and maybe but not always write or debug some critical parts.
That sounds more like a manager or architect than an engineer. Engineers should take a proactive role in discovery and talking with business to figure out the best place to create value (that's a once a month meeting for us), but at the end of the day it's up to the PO to translate business needs into product development. Either way, I doubt you need 4+ hours a day to flesh out the technical requirements. When I worked at bigger companies, I'd spend only roughly 4 hours coding a day too. It's not because the problems were harder, but because there were blockers at every corner due to siloing and overly complicated business processes. I'd spend days in meetings and escalation emails just to get a networking rule exception.
>As a senior engineer, if I told my manager in a performance review that I mostly worked alone on tickets with well defined requirements, I’d be on PIP immediately and probably fired a month later.
Then you're a sucker. Engineers are supposed to write code. Even at the bigger companies, all senior engineers (and I mean 15+ experience) wrote code most of the time and did everything in their power to avoid meetings and other disruptions. That's how I learned about the "Law of Two Feet". Business expects you to coordinate between stakeholders and the rest of the engineering team. What's next? Should you manage the team's budget as well? Make long-term product roadmaps? Get yourself a promotion!
That sounds more like a manager or architect than an engineer. Engineers should take a proactive role in discovery and talking with business to figure out the best place to create value (that's a once a month meeting for us), but at the end of the day it's up to the PO to translate business needs into product development. Either way, I doubt you need 4+ hours a day to flesh out the technical requirements. When I worked at bigger companies, I'd spend only roughly 4 hours coding a day too. It's not because the problems were harder, but because there were blockers at every corner due to siloing and overly complicated business processes. I'd spend days in meetings and escalation emails just to get a networking rule exception.
>As a senior engineer, if I told my manager in a performance review that I mostly worked alone on tickets with well defined requirements, I’d be on PIP immediately and probably fired a month later.
Then you're a sucker. Engineers are supposed to write code. Even at the bigger companies, all senior engineers (and I mean 15+ experience) wrote code most of the time and did everything in their power to avoid meetings and other disruptions. That's how I learned about the "Law of Two Feet". Business expects you to coordinate between stakeholders and the rest of the engineering team. What's next? Should you manage the team's budget as well? Make long-term product roadmaps? Get yourself a promotion!
Managers are responsible for careers: hiring, development, satisfaction, promotion, visibility, and so on. Senior ICs (L5+) are responsible for the work. They own their products and domains, including architecture and long-term roadmaps, and are ultimately accountable for its impact. I did get myself that promotion... it was called Senior Engineer.
We have people who do JIRA tickets specified and prioritized for them ahead of time by others. They are called Engineer I and Engineer II. They don't get paid nearly as much or have the autonomy and recognition that senior engineers do. Most of them are biding their time waiting for managers to finally find projects they can drive instead of help with, so that they can finally demonstrate senior competencies and get the title themselves.
We have people who do JIRA tickets specified and prioritized for them ahead of time by others. They are called Engineer I and Engineer II. They don't get paid nearly as much or have the autonomy and recognition that senior engineers do. Most of them are biding their time waiting for managers to finally find projects they can drive instead of help with, so that they can finally demonstrate senior competencies and get the title themselves.
I guess it's just a difference of nomenclature theb. FAANG (especially Amazon and Microsoft) are just so big that the stratification creates a lot of roles to facilitate the org. Even at my old company (~5500 staff), our managers only owned one product but I guess your RM would have an entire portfolio.
> Remote is about getting things done asynchronously. Is it perfect for every type of work? Of course not. But should we default to copying the inefficient processes of physical offices because you’re used to “talking it out”? No!
This is _exactly_ how I feel, where, and I've tried and failed before to express this to colleagues pre-pandemic, when I was already part time remote. Instead of demanding people be at a desk where you can walk over and interrupt them to 'throw some ideas around', make the effort to write your idea down and share it asynchronously, and others can thoughtfully reply and collaborate.
Comes down to people's brains working differently than you and I expect, where thinking only gets done if their mouth is moving and sound is coming out. These are the people that the in person offices and meetings and shoulder taps are built for, at the expense of those who can manage a coherent thought in silence, and are able to outline a problem or a question using the written word.
One is not better or worse necessarily, but being more independent in preparing communication of ideas should be something that all can work towards. It's just more flexible and "async" and adapts well to "remote".
A rough analogy might be packet switching - if you have to be in the same room with someone and only share data in real time, as opposed to being able to prepare data ahead of time and transmit it over the wire... Which of these is more robust and adaptable to changing network conditions?
This is _exactly_ how I feel, where, and I've tried and failed before to express this to colleagues pre-pandemic, when I was already part time remote. Instead of demanding people be at a desk where you can walk over and interrupt them to 'throw some ideas around', make the effort to write your idea down and share it asynchronously, and others can thoughtfully reply and collaborate.
Comes down to people's brains working differently than you and I expect, where thinking only gets done if their mouth is moving and sound is coming out. These are the people that the in person offices and meetings and shoulder taps are built for, at the expense of those who can manage a coherent thought in silence, and are able to outline a problem or a question using the written word.
One is not better or worse necessarily, but being more independent in preparing communication of ideas should be something that all can work towards. It's just more flexible and "async" and adapts well to "remote".
A rough analogy might be packet switching - if you have to be in the same room with someone and only share data in real time, as opposed to being able to prepare data ahead of time and transmit it over the wire... Which of these is more robust and adaptable to changing network conditions?
It's a shame, I was hoping for actual insight, but all I got was complaints.
There are absolutely challenging anti-patterns in the remote work world, but I have yet to see actual concrete suggestions for how to deal with them. No, "nohello.com" is not an actually useful suggestion (ignoring the fact that I fundamentally disagree with the premise). Just complaining about ad hoc meetings doesn't solve for the occasional need for quick discussions that, in a textual medium, would drag out or lead to misunderstandings.
"Be more asynchronous" denies the reality that some work is synchronous. If I need something from you, I have to wait until you give me what I need. Development is a team sport, despite what the stereotypes would have you believe.
I'd love to see how "remote native" companies are doing this, but according to the author, they just devolve to this state, too.
There are absolutely challenging anti-patterns in the remote work world, but I have yet to see actual concrete suggestions for how to deal with them. No, "nohello.com" is not an actually useful suggestion (ignoring the fact that I fundamentally disagree with the premise). Just complaining about ad hoc meetings doesn't solve for the occasional need for quick discussions that, in a textual medium, would drag out or lead to misunderstandings.
"Be more asynchronous" denies the reality that some work is synchronous. If I need something from you, I have to wait until you give me what I need. Development is a team sport, despite what the stereotypes would have you believe.
I'd love to see how "remote native" companies are doing this, but according to the author, they just devolve to this state, too.
>"Be more asynchronous" denies the reality that some work is synchronous. Development is a team sport, despite what the stereotypes would have you believe.
"Be more asynchronous" is advocated to swing the pendulum, see what sticks and see what doesn't. It's not meant to be "throw the baby out with the bathwater", which most seem to kneejerk to.
Right now, the problem is a lack of evidence on a long term (1-2 generations), with a status quo unwilling to try anything despite a promising two year event. You don't make conclusions without evidence.
>If I need something from you, I have to wait until you give me what I need.
The far majority of cases, you'd have another task to work on before syncing up because most coworkers don't appreciate being disturbed when they are working on something important either. Now replace syncing up with sending them a message, and they respond at their disposal.
Either way someone is going to lose out on their individual work and it depends entirely on the context who's going to lose out more, and which choice would have helped the team get more work done.
>Development is a team sport, despite what the stereotypes would have you believe.
Which doesn't at all say anything about "sync vs async". Surely we don't have to point at the dozens of "tap on your shoulder manager" anecdotes to showcase being in person, in the office, allows for just as much solipsism.
"Be more asynchronous" is advocated to swing the pendulum, see what sticks and see what doesn't. It's not meant to be "throw the baby out with the bathwater", which most seem to kneejerk to.
Right now, the problem is a lack of evidence on a long term (1-2 generations), with a status quo unwilling to try anything despite a promising two year event. You don't make conclusions without evidence.
>If I need something from you, I have to wait until you give me what I need.
The far majority of cases, you'd have another task to work on before syncing up because most coworkers don't appreciate being disturbed when they are working on something important either. Now replace syncing up with sending them a message, and they respond at their disposal.
Either way someone is going to lose out on their individual work and it depends entirely on the context who's going to lose out more, and which choice would have helped the team get more work done.
>Development is a team sport, despite what the stereotypes would have you believe.
Which doesn't at all say anything about "sync vs async". Surely we don't have to point at the dozens of "tap on your shoulder manager" anecdotes to showcase being in person, in the office, allows for just as much solipsism.
> Right now, the problem is a lack of evidence on a long term (1-2 generations)
I'm very curious where you got this idea because it certainly doesn't reflect reality.
As others have pointed out, working across multiple timezones/geographies has requires asynchronous work for decades, now, and anyone who does it will tell you have enormously painful it can be.
> The far majority of cases, you'd have another task to work on before syncing up
If you're a developer, you must know what it's like to be heads down in the middle of something extremely mentally taxing, only to find you need an answer to a question or something, and that context switching to something else in the meantime becomes an enormous cognitive burden vs getting a quick answer and being able to continue on-task.
Humans don't multitask. It's a myth. Every context switch requires at least 20-30 minutes of ramp-up time on anything requiring any real thought. "Just be more asynchronous" is predicated on a faulty idea of how the human brain works.
I'm very curious where you got this idea because it certainly doesn't reflect reality.
As others have pointed out, working across multiple timezones/geographies has requires asynchronous work for decades, now, and anyone who does it will tell you have enormously painful it can be.
> The far majority of cases, you'd have another task to work on before syncing up
If you're a developer, you must know what it's like to be heads down in the middle of something extremely mentally taxing, only to find you need an answer to a question or something, and that context switching to something else in the meantime becomes an enormous cognitive burden vs getting a quick answer and being able to continue on-task.
Humans don't multitask. It's a myth. Every context switch requires at least 20-30 minutes of ramp-up time on anything requiring any real thought. "Just be more asynchronous" is predicated on a faulty idea of how the human brain works.
>You must know what it's like to be heads down in the middle of something extremely mentally taxing, only to find you need an answer to a question or something, and that context switching to something else in the meantime becomes an enormous cognitive burden.
So why is it okay if you have a need of someone else to force it on them? You can make the exact same argument pulling someone out of their flow to support you keeping yours.
>Humans don't multitask.
It's not multitasking. It's a context switch made out of necessity to keep yourself doing something. If it turns out your teammate responds early and you have to restart on the old task and ultimately you lose time, yes, that sucks. But what else are you going to do? Again, you're either taxing yourself, taxing someone else, or twiddling your thumbs to avoid the tax in hopes it ends up being the most profitable choice.
It's because I'm a developer I know exactly how annoying it is to be in either situation, both as the one who needs to help others, and as the one who needs help from others.
>I'm very curious where you got this idea because it certainly doesn't reflect reality.
We only had a single pandemic lasting 2 years with some evidence suggesting some subpopulation would do better asynchronous, remote or both. That's a far cry from running a larger experiment over the course of 20 years in an environment you're not forced to almost fully isolate yourself otherwise. If you're claiming there is large scale evidence proving sync is obviously and clearly better than async, in an environment which at least attempts to accommodate async, by all means, present it.
So why is it okay if you have a need of someone else to force it on them? You can make the exact same argument pulling someone out of their flow to support you keeping yours.
>Humans don't multitask.
It's not multitasking. It's a context switch made out of necessity to keep yourself doing something. If it turns out your teammate responds early and you have to restart on the old task and ultimately you lose time, yes, that sucks. But what else are you going to do? Again, you're either taxing yourself, taxing someone else, or twiddling your thumbs to avoid the tax in hopes it ends up being the most profitable choice.
It's because I'm a developer I know exactly how annoying it is to be in either situation, both as the one who needs to help others, and as the one who needs help from others.
>I'm very curious where you got this idea because it certainly doesn't reflect reality.
We only had a single pandemic lasting 2 years with some evidence suggesting some subpopulation would do better asynchronous, remote or both. That's a far cry from running a larger experiment over the course of 20 years in an environment you're not forced to almost fully isolate yourself otherwise. If you're claiming there is large scale evidence proving sync is obviously and clearly better than async, in an environment which at least attempts to accommodate async, by all means, present it.
> So why is it okay if you have a need of someone else to force it on them
That's your straw man, not mine.
My point is that some work is essentially synchronous and "be more asynchronous" is not an actual solution because it doesn't reflect how humans actually work.
Remember: I'm not the one making affirmative claims about what people should be doing. Rather, I'm poking holes in the claims other people are making.
> It's not multitasking. It's a context switch
I... don't know what to do with this obvious internal contradiction.
> If you're claiming there is large scale evidence proving sync is obviously and clearly better than async, in an environment which at least attempts to accommodate async, by all means, present it.
I did. It's called 30 years of outsourcing. You're choosing to ignore that point, though why that is you've not made clear. Instead you're insisting I provide evidence to counter your unsupported claim, which isn't the best way to argue in good faith.
That's your straw man, not mine.
My point is that some work is essentially synchronous and "be more asynchronous" is not an actual solution because it doesn't reflect how humans actually work.
Remember: I'm not the one making affirmative claims about what people should be doing. Rather, I'm poking holes in the claims other people are making.
> It's not multitasking. It's a context switch
I... don't know what to do with this obvious internal contradiction.
> If you're claiming there is large scale evidence proving sync is obviously and clearly better than async, in an environment which at least attempts to accommodate async, by all means, present it.
I did. It's called 30 years of outsourcing. You're choosing to ignore that point, though why that is you've not made clear. Instead you're insisting I provide evidence to counter your unsupported claim, which isn't the best way to argue in good faith.
>My point is that some work is essentially synchronous and "be more asynchronous" is not an actual solution because it doesn't reflect how humans actually work.
Which is why I'm not criticizing your other example of "dragging out or leading to misunderstandings", which is fair criticism of async and speaks favorably of synchronous communication (even if its just pinging messages at a rapid pace back and forth). However, I don't agree with a blanket statement such as "that's not how humans work". Enough people do work better largely asynchronous. What's more, people throw examples of "this can be solved synchronously!" when in reality, you're incurring costs no matter what solution you're going for. If we're arguing "that's now how humans work", humans weren't made to go from manually intensive labor 2-3 generations ago to sitting in the office 8 hours a day either, but here we are.
>I did.
Looking back, all I find is this:
>As others have pointed out, working across multiple timezones/geographies has requires asynchronous work for decades, now, and anyone who does it will tell you have enormously painful it can be.
That's evidence asynchronous has challenges. Not that sync is flat-out better, let alone in what situations. Not a single comment in this thread links to any source as of the time of writing, it's just a bunch of people with experience and without debating anecdotes and rationalities with one another, on both sides of the spectrum. If anything, that proves how much evidence we lack to make a definite statement from either side.
I'm not arguing async doesn't have problems. I'm arguing different people work in different situations, rather than the one-size-fits-all mentality some individuals try to push through. Worse, because so many are denied experience or even strong evidence, people going "this doesn't work so no" feels infantilizing, leading to confusion and animosity down the road. It wasn't too many months ago we started questioning the need to be in office because commuting sucks, high rents suck, open offices sucks and individuals have different needs, and now it's met with a blanket "back to the office y'all" without clear transparency regarding production gains/losses.
The "one true way of working" has changed more often in the last three decades than most of our species' existence. I think there's room to criticize what is and isn't fixed.
Which is why I'm not criticizing your other example of "dragging out or leading to misunderstandings", which is fair criticism of async and speaks favorably of synchronous communication (even if its just pinging messages at a rapid pace back and forth). However, I don't agree with a blanket statement such as "that's not how humans work". Enough people do work better largely asynchronous. What's more, people throw examples of "this can be solved synchronously!" when in reality, you're incurring costs no matter what solution you're going for. If we're arguing "that's now how humans work", humans weren't made to go from manually intensive labor 2-3 generations ago to sitting in the office 8 hours a day either, but here we are.
>I did.
Looking back, all I find is this:
>As others have pointed out, working across multiple timezones/geographies has requires asynchronous work for decades, now, and anyone who does it will tell you have enormously painful it can be.
That's evidence asynchronous has challenges. Not that sync is flat-out better, let alone in what situations. Not a single comment in this thread links to any source as of the time of writing, it's just a bunch of people with experience and without debating anecdotes and rationalities with one another, on both sides of the spectrum. If anything, that proves how much evidence we lack to make a definite statement from either side.
I'm not arguing async doesn't have problems. I'm arguing different people work in different situations, rather than the one-size-fits-all mentality some individuals try to push through. Worse, because so many are denied experience or even strong evidence, people going "this doesn't work so no" feels infantilizing, leading to confusion and animosity down the road. It wasn't too many months ago we started questioning the need to be in office because commuting sucks, high rents suck, open offices sucks and individuals have different needs, and now it's met with a blanket "back to the office y'all" without clear transparency regarding production gains/losses.
The "one true way of working" has changed more often in the last three decades than most of our species' existence. I think there's room to criticize what is and isn't fixed.
I think that as the author matures, they’ll come to the realisation that software engineering is 20% coding and 80% working out who needs to code what where when. And that is much easier with synchronous communication.
If ICs spend only 20% of their time in coding then there must be in an unproductive team and company.
Product owners and managers could easily move tickets and fill excels and notion pages asynchronously.
I really don’t see any important reason for synchronous work other than something has caught fire live.
If I were to use the 80/20 rule here - at least for startups - I'd say it's the opposite. Only a very inefficient company would have 20% coding time.
I imagine the scales start turning the other way as companies grow, which is exactly why big companies move slowly.
What you're describing is work that is riddled with red-tape. Some of it might be necessary, but 80% is a bit too high.
I imagine the scales start turning the other way as companies grow, which is exactly why big companies move slowly.
What you're describing is work that is riddled with red-tape. Some of it might be necessary, but 80% is a bit too high.
I’ve been doing remote async for five years now. Nothing beats that lifestyle for me. I think it’s only natural to work that way. No alarms, only natural rhythms. Code when it works for you, tackle problems, respond to messages when it suits you best. What’s the point of remote work if everyone’s online at the same time? I don’t see the point as a developer. Business-wise, maybe—if you don’t have everything dumped into txt.
Can you provide some details on the industry and team, and how you found them? This seems to be somewhat rare so I'm curious how to find such roles myself.
I’ve been doing this as a contractor. I started in my home country, where $50/h is a lot—established relationships over time with people who value solid developers and hate handholding as much as I do. Over time progressed and tripled my rate and now do maintenance work primarily and combine personal business projects. I sacrificed corp. Life and lots of money but gained a lot of flexibility and traveled a lot. As a non-US work authorized person, it wasn’t much of an option anyway.
I’d say this: if you’re outside of the US, the best companies for this approach are in the Nordics. If you are US-based, the number of companies who fit this profile are non-tech founders who look for an all-in-one developer who can move the needle and establish everything until there are more funds or traction. Stakeholders have to value the quality of life more than anything esle.
I’d say this: if you’re outside of the US, the best companies for this approach are in the Nordics. If you are US-based, the number of companies who fit this profile are non-tech founders who look for an all-in-one developer who can move the needle and establish everything until there are more funds or traction. Stakeholders have to value the quality of life more than anything esle.
Pieter levels (remoteok.io) has been writing about this for a while. He calls it "async work" https://levels.io/async/
While I'm a fan of the idea. I'm not sure everything can be accomplished asynchronously. Or maybe it just requires more planning up front to make sure peoples do not have a lot of inter-dependencies.
While I'm a fan of the idea. I'm not sure everything can be accomplished asynchronously. Or maybe it just requires more planning up front to make sure peoples do not have a lot of inter-dependencies.
Just getting rid of inconsiderate pings would be a start. Valuing your time over others is a shockingly common cultural failing. I've come to expect it from managers that don't know how important uninterrupted focus time is to developers, but increasingly developers have been doing it too. Without checking documentation. Without the willingness to wait in the channel for the product they need support for. No, they're blocked NOW and they need a response NOW. Better pull the entire team out of their work.
Huge downside of working in platform teams, and sadly not the only reason you develop an adversarial relationship with "feature teams".
I want a company where pings are reserved for fires, and everything else is handled either at fixed syncronization points (e.g. a batch of code reviews) or whenever someone is out of the zone anyhow.
Huge downside of working in platform teams, and sadly not the only reason you develop an adversarial relationship with "feature teams".
I want a company where pings are reserved for fires, and everything else is handled either at fixed syncronization points (e.g. a batch of code reviews) or whenever someone is out of the zone anyhow.
I like the specific term of async work. Haven't seen companies use it in the wild yet.
I definitely agree that not everything can be done async, but the reality is that most companies don't even try. They just default to sync workflows without the office.
It takes some effort for sure, but I think the benefits are enormous.
I definitely agree that not everything can be done async, but the reality is that most companies don't even try. They just default to sync workflows without the office.
It takes some effort for sure, but I think the benefits are enormous.
> managers and co-workers starting every message with “hello, how are you doing?” and waiting for a response
https://www.nohello.com
https://www.nohello.com
I’ve worked in mostly remote companies with heavy use of emails and chat on and off for many years, and this has never been a concern for me. I can’t even remember thinking about it once. It seems quite petty.
Frankly the much bigger problem is global time zones and limited overlap restricting the time available for synchronous discussions.
Frankly the much bigger problem is global time zones and limited overlap restricting the time available for synchronous discussions.
Here's why it's annoying: You're now taking my attention while I have to wait for you to actually type your question. If you just sent me your question, I can read it, answer it, and get back to what I was doing. But by saying hi first, now I can't go back to what I was doing because I know your question is coming in a minute or so, which isn't enough time to do anything else, but you've already broken my concentration because I had to check your initial message.
There are many layers to this if you think about it. They may try to save effort by only typing the question in case you are there. But also, it's a way to avoid you not answering. I mean, they may (perhaps subconsciously) fear that you will read the question and decide to procrastinate on answering it because it looks too hard somehow. Instead, if they get you on the hook in synchronous communication, it will be harder for you to "snooze" on the question. I mean you can explicitly tell them you'll take a look later but you can't pretend that you haven't read it yet. Or some may use it as an excuse to pause working.
That plus a lot of other mind games. In a way it's a power game, whose time is more valued, who gets to demand attention right now etc., who has more flexibility and convenience...
Also, sometimes when people are confused, they sort of emotionally panic and just need someone beside them, to hold their hand and comfort them virtually. Then if you don't respond, they somehow do manage to solve their problem on their own anyway. But it felt simpler to just interrupt your work and ask you instead of thinking or searching in the internal docs etc.
That plus a lot of other mind games. In a way it's a power game, whose time is more valued, who gets to demand attention right now etc., who has more flexibility and convenience...
Also, sometimes when people are confused, they sort of emotionally panic and just need someone beside them, to hold their hand and comfort them virtually. Then if you don't respond, they somehow do manage to solve their problem on their own anyway. But it felt simpler to just interrupt your work and ask you instead of thinking or searching in the internal docs etc.
Heh, yeah I typically just don't respond to the initial "hi" slack. After a few minutes at most, they always follow up with the actual question.
[deleted]
I think for the example given on the page, given it seems to be a quick question, it's easy for it to seem a bit petty (and I might agree). The hard part for me is by responding, I have no idea if I'm walking into a 2hr debugging session or a 30s question.
'Maybe' and 'it depends', are good intermediate remarks while painting the picture about the real question at hand.
I agree 100% with the sentiment of nohello.com. I used to have it has my status message. I've also gone long periods where I just won't respond when someone hello or hi's me. I've since realized that I was just being difficult and now I just type hey back and it makes life a lot easier.
The strategy I've adopted is to first be polite by writing "hey" back [0] and then helping them with whatever they were asking. But THEN I end the conversation with a link to nohello.com to politely ask them to just directly ask next time. That's not being difficult but has the potential to improve things over time.
[0] If I'm in a bad mood I reflect the exact sentence back, meeting "hi" with "hi" and "Hey how are you?" with "Hey how are you?", but still, it's a reply..
[0] If I'm in a bad mood I reflect the exact sentence back, meeting "hi" with "hi" and "Hey how are you?" with "Hey how are you?", but still, it's a reply..
They are just lazy to type their question, in case you don't happen to be there right now. So if you don't respond quickly, then they save the work of having to formulate the question.
Typical scenario though is that then they move on ask somewhere else. So they have to type it out anyway. If you don't reply, they can copy-and-paste the question to somebody else.
Or they put up with having to put in a little effort to figure it out themselves or look up the info in the internal documentation.
Oh, that's a nicely formatted alternative. I often like to change my messenger status to a URL like this. It's slowly making an impact.
In the "which one of them do you like" domain... https://no-hello.com
Though there's also https://nohello.club
Though there's also https://nohello.club
[deleted]
One of the advisors in the 100% remote company I just started in recommended me to read into Nozbe. It's an app for project management but that's not what I want to highlight.
The company has been working on effective asynchronous processes since their beginnings (over 10 years ago) and they've written an open source book about it called "No office". They also have a podcast and a blog and I'm looking into them for reference as I build a proposal on how to optimize communication logistics and information management inside the company.
The company has been working on effective asynchronous processes since their beginnings (over 10 years ago) and they've written an open source book about it called "No office". They also have a podcast and a blog and I'm looking into them for reference as I build a proposal on how to optimize communication logistics and information management inside the company.
I'm not convinced we've seen what "should" be with the pandemic. We've done a thing for a few years, that's not a lot of time.
I think it takes a lot longer to see what works about a thing, what doesn't, for each company, even individuals, and in the long run how they play out on an individual basis.
I guess we can come up with all sorts of very strict rules about what is "remote" ... but that will just mean everyone has to declare they're some sort of hybrid and I'm not sure we've gotten anywhere / know anything about it... kinda back to square one as far as the author is concerned.
I think it takes a lot longer to see what works about a thing, what doesn't, for each company, even individuals, and in the long run how they play out on an individual basis.
I guess we can come up with all sorts of very strict rules about what is "remote" ... but that will just mean everyone has to declare they're some sort of hybrid and I'm not sure we've gotten anywhere / know anything about it... kinda back to square one as far as the author is concerned.
Not only that, we were forced to do it for the past two years. Does this "thing" truly have any merit? We don't know because companies did not have an alternative. We have nothing to compare it to.
After the first year of the pandemic I deleted all work apps off my phone — just remove the ability for Slack/Teams, GCal, Lattice, Figma, etc. to constantly badger you.
People will call if it’s actually urgent. But gotta protect/prioritize yourself in this new faux-remote reality.
People will call if it’s actually urgent. But gotta protect/prioritize yourself in this new faux-remote reality.
I've waffled on this a bit. I joined a new company about a year ago, and swore to myself I'd keep work email, slack, etc. off my phone. I eventually caved because my boss expected a certain amount of "presence", and being able to check in and respond from my phone meant I could enjoy my coffee in the morning, run errands, take a walk, or do whatever else without being chained to my laptop.
A better middle-ground might be to have a separate phone, so it's only with me if it has to be. Starting a new job with this setup soon, we'll see how it goes.
A better middle-ground might be to have a separate phone, so it's only with me if it has to be. Starting a new job with this setup soon, we'll see how it goes.
I think it's a matter of trust and boundaries with work. I love having work email and IM on my phone; but everyone I work with respects work/life boundaries.
It's especially useful at the moment, because I'm in a small company and we do devops.
If I start getting a barrage of work-related IMs after-hours, first I'll point out to the offender that I expect them to respect boundaries. Then I'll try to configure quiet hours. Finally I'll remove the apps.
It's especially useful at the moment, because I'm in a small company and we do devops.
If I start getting a barrage of work-related IMs after-hours, first I'll point out to the offender that I expect them to respect boundaries. Then I'll try to configure quiet hours. Finally I'll remove the apps.
The incumbent crop of senior ICs and managers got there on verbal rather than written communication. I don’t think they will lead an enthusiastic transition to a working arrangement that exposes their sometimes below-average writing and reading comprehension skills.
Remote, distributed, asynchronous - they're not all synonymous. Remote is simply that, far apart, so I think it's fair to say that if a company primarily employs people who work from wherever they may be, then I'm fine with them wearing the "remote" badge. There is absolutely nothing in the word "remote" that implies synchronicity or otherwise, everything else is just a matter of opinion, or taste, or what's practical and works.
Do most people really want this world where you rarely interact directly with another human? Every time I try it for a few days, I start feeling depressed.
Where this "you want an async work environment? You must not want communication at all!" narrative is coming from is beyond me. There is more beyond the office to communicate with.
Yeah that's true, I think the async world is probably one that works for many.
For me, "working to live" doesn't resonate. I miss is the camaraderie and feeling of going to battle with people I like. For me, building something, and competing to win is what gives me the most meaning in life. I love my family, but there's something in me that wants to give more to the world. It's not for everyone and of course it's not the only way to live. But that's what feels right for me, and I miss it.
For me, "working to live" doesn't resonate. I miss is the camaraderie and feeling of going to battle with people I like. For me, building something, and competing to win is what gives me the most meaning in life. I love my family, but there's something in me that wants to give more to the world. It's not for everyone and of course it's not the only way to live. But that's what feels right for me, and I miss it.
> where you rarely interact directly with another human
I hardly call that async / remote work at all! Quite the contrary, remote work and async work define themselves by how interaction with other people happen.
Most importantly: The issues TFA discuss also are important for face-to-face work. A manager who constantly interrupts, and wastes time by allowing too many meetings, is ineffective. It doesn't matter if the interruptions are a tap on the shoulder or an IM; and it doesn't matter if the meeting is face-to-face or via Zoom.
In order for remote / async to work, there needs to be a clear recognition that effective office work requires time management. The time management skills that keep meetings effective and provide for uninterrupted concentration are the same, both for face-to-face and virtual workplaces.
I hardly call that async / remote work at all! Quite the contrary, remote work and async work define themselves by how interaction with other people happen.
Most importantly: The issues TFA discuss also are important for face-to-face work. A manager who constantly interrupts, and wastes time by allowing too many meetings, is ineffective. It doesn't matter if the interruptions are a tap on the shoulder or an IM; and it doesn't matter if the meeting is face-to-face or via Zoom.
In order for remote / async to work, there needs to be a clear recognition that effective office work requires time management. The time management skills that keep meetings effective and provide for uninterrupted concentration are the same, both for face-to-face and virtual workplaces.
I agree with you. Remote optimizes for one set of things, using a model that works great in a low-trust environment like open source. And you can probably get pretty good results with it. And I find Zoom calls far more fatiguing than in-person meetings.
Remote work doesn't remove the need or ability to interact with other humans on your team.
I like this world where I'm not drained by daily commute and strict hours so I can enjoy my relatives on the evening instead of feeling tired and avoiding going out during the week.
I wouldn't say office-less and async are at odds. It's more like that we now have 2 axes:
- Has or doesn't have physical office;
- Has or doesn't have culture of getting things done with less back-and-forth.
If you look at it like this then you have 4 different combinations -- that translate to 4 different types of companies.
- Has or doesn't have physical office;
- Has or doesn't have culture of getting things done with less back-and-forth.
If you look at it like this then you have 4 different combinations -- that translate to 4 different types of companies.
I had been working 50-75% of the time remote since 2001, and full time remote since 2008 except for occasional travel for short onsite customer visits. Communication with project leaders and managers was usually just the right amount. The best was a short email or chat message asking to schedule a one-one voice call or voice group meeting with or without customers. I hardly even thought about how it could be different. Then in 2017, there was a shift of project handlers who would only call with direct questions or a request to join an in-progress group voice meeting. It was very disrupting to my flow, and was such a quick change, that I could not even politely describe to leadership the problem. I burnt-out quickly and quit.
>managers and co-workers starting every message with “hello, how are you doing?” and waiting for a response
I simply stopped responding to "Hello" Slacks. Eventually they'll either type in what they need or give up and go bother someone else.
I simply stopped responding to "Hello" Slacks. Eventually they'll either type in what they need or give up and go bother someone else.
While I agree with others that remote does not necessarily imply asynchronous, there's a nugget I do agree with from the author's POV:
Video calling, chat tools and screensharing alone aren't really a great infrastructure for 'remote-friendly' organizations; maybe it's a bit of pedantry on play but since we're unpacking the differences between "remote" and "asynchronous" organizations, I wonder if it's worth breaking out the dichotomy of "remote-friendly" and merely "remote-capable"?
I don't have an answer to that, just sort of thinking vicariously through my keyboard
Video calling, chat tools and screensharing alone aren't really a great infrastructure for 'remote-friendly' organizations; maybe it's a bit of pedantry on play but since we're unpacking the differences between "remote" and "asynchronous" organizations, I wonder if it's worth breaking out the dichotomy of "remote-friendly" and merely "remote-capable"?
I don't have an answer to that, just sort of thinking vicariously through my keyboard
As a remote-only employee for more than a decade now, I can say that I don't have a problem with "core hours," like 10am - 2pm for your time zone.
I understand that sometimes we need to get together internally and with clients. What I cannot stand is the premise of this article: locking me into a cage that I pay for where I have to be available at a moment's notice.
I've quit two jobs that made me do that. I'm sure they learned their lesson . . . ;)
I understand that sometimes we need to get together internally and with clients. What I cannot stand is the premise of this article: locking me into a cage that I pay for where I have to be available at a moment's notice.
I've quit two jobs that made me do that. I'm sure they learned their lesson . . . ;)
I like core hours in theory, especially if the window is that small (in practice I've seen it more like 10-4).
What should the window be when the team is split across timezones like PST & EST, with a 3 hour difference? Either someone is online very early, or very late.
What should the window be when the team is split across timezones like PST & EST, with a 3 hour difference? Either someone is online very early, or very late.
Hum... I totally disagree with the author... Remote work does not means asynchronous work: a call center operator can perfectly work from remote but need to be operational at specific point in time for specific timeframe to ensure enough communication lines are covered on the call center side. Remote surveillance is not different. Banking and insurance remote work might be partially asynchronous but some again need specific timeframe to receive customers contacts who happen to be in specific places under specific time etc.
Surely remote work does not means mimicking physical office like metaverse virtual rooms for conferences, does not need VDI against a central "networked desktops farm" but that's a totally different thing than asynchronicity.
Also asynchronicity is not a remote only thing, for instance some research works demanding certain labs/instruments so not done remotely might be asynchronous in the sense that some researchers just book their use seeing colleagues usage without specific time constraints.
Remote work means being able to work regardless of geographical location, that typically means WFH but not only WFH, for instance certain on(remote)fields jobs are actually remote and definitively not from home nor even from an office.
A "fully remote" company means a company that only have a formal siege as laws mandate but no physical offices, that hire and work normally regardless of employee location typically but not necessary from their own homes. It's a company where you can send a CV via mail, have a call via VoIP, get hired via internet+mail as needed by local laws, start working with stuff you get by some shipping services at home (for instance) etc. But that does not means asynchronously nor "by targets".
Surely remote work does not means mimicking physical office like metaverse virtual rooms for conferences, does not need VDI against a central "networked desktops farm" but that's a totally different thing than asynchronicity.
Also asynchronicity is not a remote only thing, for instance some research works demanding certain labs/instruments so not done remotely might be asynchronous in the sense that some researchers just book their use seeing colleagues usage without specific time constraints.
Remote work means being able to work regardless of geographical location, that typically means WFH but not only WFH, for instance certain on(remote)fields jobs are actually remote and definitively not from home nor even from an office.
A "fully remote" company means a company that only have a formal siege as laws mandate but no physical offices, that hire and work normally regardless of employee location typically but not necessary from their own homes. It's a company where you can send a CV via mail, have a call via VoIP, get hired via internet+mail as needed by local laws, start working with stuff you get by some shipping services at home (for instance) etc. But that does not means asynchronously nor "by targets".
I probably should have made it clear on the article that I'm talking about software development and not every possible type of work.
When you scope it to software, remote does imply async work at varying degrees. One of the reasons I call it a farce is because they boast the "flexible work hours!" then in reality you have to be there for 20h+ of meetings in a week.
When you scope it to software, remote does imply async work at varying degrees. One of the reasons I call it a farce is because they boast the "flexible work hours!" then in reality you have to be there for 20h+ of meetings in a week.
Ok, that change completely :-)
Software development in most cases can be done both by target and asynchronously, still need IMVHO a bit of talking in the team but yep, not like many companies do...
Software development in most cases can be done both by target and asynchronously, still need IMVHO a bit of talking in the team but yep, not like many companies do...
> If what I wrote so far resonated with you, and especially if you can influence this, please stop this farce and start truly supporting remote work.
It's not a farce, it's something else and you don't have to like it. Pick a good term and try to get it to stick, and then look for companies that don't use that term.
It's not a farce, it's something else and you don't have to like it. Pick a good term and try to get it to stick, and then look for companies that don't use that term.
I have to disagree with this because that's not what I've seen in the wild.
If everyone made a clear distinction between remote and async, I'd agree with you 100%. But the term "remote" is in my view intentionally conflated with async most of the time.
Companies will advertise themselves as remote, remote friendly, remote first, etc and then have a culture of completely synchronous work. That's why I called it a farce.
If everyone made a clear distinction between remote and async, I'd agree with you 100%. But the term "remote" is in my view intentionally conflated with async most of the time.
Companies will advertise themselves as remote, remote friendly, remote first, etc and then have a culture of completely synchronous work. That's why I called it a farce.
> in my view
> intentionally conflated
I don't think you should have an opinion that people are misrepresenting something maliciously without being able to back it up.
Your interpretation of the term "remote-friendly" is not the common interpretation. They don't need to change how they work. You don't have to work at those places. If you're confusing about what the terms mean _in practice_, talk to people who work at different places and look at job postings and try to infer from usage what the terms mean.
A Google search for "what is a remote friendly job" can also be helpful.
I strongly disagree with the jump from "I'm confused about what a term means" to "People should change what they do to match what I understand they say they do". I don't think you did that intentionally, as it's a common mistake when people are surprised by a term's meaning, but it's still a wrong reaction.
I don't think you should have an opinion that people are misrepresenting something maliciously without being able to back it up.
Your interpretation of the term "remote-friendly" is not the common interpretation. They don't need to change how they work. You don't have to work at those places. If you're confusing about what the terms mean _in practice_, talk to people who work at different places and look at job postings and try to infer from usage what the terms mean.
A Google search for "what is a remote friendly job" can also be helpful.
I strongly disagree with the jump from "I'm confused about what a term means" to "People should change what they do to match what I understand they say they do". I don't think you did that intentionally, as it's a common mistake when people are surprised by a term's meaning, but it's still a wrong reaction.
>Your interpretation of the term "remote-friendly" is not the common interpretation.
Maybe on a general level that's not the common interpretation, but in software that's a different story.
You don't expect to join a remote-friendly company for software development and then have to work in a strict time regiment with meetings as one of the default means of communication, for example. Async is implied - at varying degrees - when you apply for a remote-friendly company.
> You don't have to work at those places.
You'll have a hard time finding a job opening where they say "we actually work as a typical office, just remotely". You can probably get that answered when interviewing, but that's not a guarantee by any means.
I've joined multiple companies that were "remote-friendly" and boasted all the flexibility of async work, only to find out it's not quite real.
Could I be unlucky and everyone else has a different experience? Sure. Is it likely though?
Maybe on a general level that's not the common interpretation, but in software that's a different story.
You don't expect to join a remote-friendly company for software development and then have to work in a strict time regiment with meetings as one of the default means of communication, for example. Async is implied - at varying degrees - when you apply for a remote-friendly company.
> You don't have to work at those places.
You'll have a hard time finding a job opening where they say "we actually work as a typical office, just remotely". You can probably get that answered when interviewing, but that's not a guarantee by any means.
I've joined multiple companies that were "remote-friendly" and boasted all the flexibility of async work, only to find out it's not quite real.
Could I be unlucky and everyone else has a different experience? Sure. Is it likely though?
I work in a small team; less than ten people. We are distributed over Europe and Asia, which I consider remote.
I do love the synchronous calls with the designer when we are finetuning some pieces of front-end though. Or debugging some database issues over the phone with another dev. I very much like the location-agnosticness of my work, but I would not want to go without some real time communication every now and again.
Maybe I'm reading too much in the post - I also don't like to be constantly bothered over Slack - but how I read it the author would strive to get rid of such interactions entirely. I found there is value in a balance between async and sync workflow even when a team is remote in the physical definition, so I don't think remote should be read as async.
I do love the synchronous calls with the designer when we are finetuning some pieces of front-end though. Or debugging some database issues over the phone with another dev. I very much like the location-agnosticness of my work, but I would not want to go without some real time communication every now and again.
Maybe I'm reading too much in the post - I also don't like to be constantly bothered over Slack - but how I read it the author would strive to get rid of such interactions entirely. I found there is value in a balance between async and sync workflow even when a team is remote in the physical definition, so I don't think remote should be read as async.
Ok, so we all know and understand the benefits of async work for the employees. Given that good developers are dufficult to get (for below-FAANG compensation), it makes sense to consider offering this as a benefit.
But the big hairy mammoth in the room is that the company needs to put a lot of effort into making sure everyone does their part. A single person who is taking advantage of the benefits (slacking off) will quickly bring down productivity of the whole team. "They are not working much, why should I?" In the end it is easier to lead people that you see live.
I would be grateful for any hints on how to better organize work to make sure productivity stays high, if anyone has experience with this.
But the big hairy mammoth in the room is that the company needs to put a lot of effort into making sure everyone does their part. A single person who is taking advantage of the benefits (slacking off) will quickly bring down productivity of the whole team. "They are not working much, why should I?" In the end it is easier to lead people that you see live.
I would be grateful for any hints on how to better organize work to make sure productivity stays high, if anyone has experience with this.
>A single person who is taking advantage of the benefits (slacking off) will quickly bring down productivity of the whole team
People are already doing this on-site. Whatever metrics you're using to prevent this kind of behavior should be largely independent from sync/async. There are also individual reasons why one would slack either sync or async. You give an async example. Plenty of school kids know the example of the projects where half the group doesn't do anything, even when they are together.
People are already doing this on-site. Whatever metrics you're using to prevent this kind of behavior should be largely independent from sync/async. There are also individual reasons why one would slack either sync or async. You give an async example. Plenty of school kids know the example of the projects where half the group doesn't do anything, even when they are together.
Good point. I guess it is the same as onsite... Team lead needs to know who is working on what and make sure that output velocity makes sense, or determine what the reason for poor performance is and try to fix it.
[deleted]
When I moved from a remote dev job at an insurance company (~5500 employees) to a startup (~20), I was amazed with how much more async the environment was. There are no core hours, everything is a thread unless an urgent need arises, and we're hardly on a zoom call outside standup.
What I've noticed is that I really do have more time to just do work. I end up releasing 3x a week instead of twice a month. I think it's still good to have refinement meetings and set time with the PO/Manager about vision and priority, but this idea that you need to spend even 10% of your time in synchronous discussions with your team is ridiculous.
What I've noticed is that I really do have more time to just do work. I end up releasing 3x a week instead of twice a month. I think it's still good to have refinement meetings and set time with the PO/Manager about vision and priority, but this idea that you need to spend even 10% of your time in synchronous discussions with your team is ridiculous.
"They are office-less companies but they are not remote-friendly."
It's going to be a long, long time before most companies are remote-friendly. That is a skill that will run short of demand for a long time to come. I spoke with 30 entrepreneurs and tried to survey the current scene, what work can be done from home, and what work managers prefer to have done at the office. For anyone interested:
http://www.smashcompany.com/business/what-work-can-be-done-f...
It's going to be a long, long time before most companies are remote-friendly. That is a skill that will run short of demand for a long time to come. I spoke with 30 entrepreneurs and tried to survey the current scene, what work can be done from home, and what work managers prefer to have done at the office. For anyone interested:
http://www.smashcompany.com/business/what-work-can-be-done-f...
[deleted]
I begrudgingly agree with many of the comments here saying remote/not and a/sync are orthogonal, and that most software work requires a lot of synchronicity.
If someone really wants to work in software as asynchronously as possible, where could they find such work? What sorts of companies, industries, roles are most amenable to primarily asynchronous work?
If someone really wants to work in software as asynchronously as possible, where could they find such work? What sorts of companies, industries, roles are most amenable to primarily asynchronous work?
I worked remote with companies all over the world.
The more synchronous work they required, the worse the work environment was.
The more synchronous work they required, the worse the work environment was.
Yes, companies with office cultures that change and become office-less won't change culture. They'll just adjust to the new engagement rules. I don't think there is a point trying to convince anyone to try doing it differently. These organisational behaviours are set in stone.
The majority of the value of remote work is the convenience of no longer having to sit in a seat pretending to smile for eight solid hours. Remote work focuses attention on more productive tasks. Virtual offices reinstitute the original problem of biasing appearances over merit.
so back when i used to spend an hour or more reading and responding to email every morning i was closer to this definition of "remote" even though i was sitting in an office.
Why don’t we create an even more extreme take: remote work is only truly remote if you communicate through git commit messages. The only thing that matters is the result of your work and anything higher level is simply corporate fluff.
[deleted]