Virtual offices are not remote-friendly workplaces
mycodingtales.com
mycodingtales.com
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…
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.
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.
I'd love to be able to search for jobs with the keyword "async" instead!
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.
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.
Not necessarily. Consider a call center or help desk, or any form of customer service done remotely. Asynchronous and remote are different.
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.
I've never heard companies say they're async though, only remote. The two seem to be conflated most of the time.
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.
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.
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.
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.
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.
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 :)
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.
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!
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.
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?
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" 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.
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.
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.
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.
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 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’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.
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.
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 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.
Frankly the much bigger problem is global time zones and limited overlap restricting the time available for synchronous discussions.
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.
[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..
Though there's also https://nohello.club
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 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.
People will call if it’s actually urgent. But gotta protect/prioritize yourself in this new faux-remote reality.
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.
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.
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.
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.
- 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 simply stopped responding to "Hello" Slacks. Eventually they'll either type in what they need or give up and go bother someone else.
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
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 . . . ;)
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.
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".
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.
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...
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.
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.
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.
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 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.
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.
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.
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.
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...
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?
The more synchronous work they required, the worse the work environment was.
> Incentivize written communication and by all means use synchronous meetings when necessary, but don’t default to it.