How Employers Sabotage Remote Workers
Tags: codequality, productivity, career, webdev
Published: 2020-12-12 02:51:58

I recently wrote an article about the perils of remote work.  In that article, I talked about how remote work can be disappointing - for _all_ parties involved.  I didn't want that article to point a finger in any particular direction, because remote jobs (like all jobs) are _relationships_.  And when relationships go bad, it's rarely the sole fault of one party.

In this article, I'm going to explore some of the _many_ ways that employers/managers can sabotage the success of remote employees.  I've seen these issues crop up in multiple companies.  And in most cases, I find the issues to be rather irreversible.  In other words, if an employer is engaging in some (or all) of the following practices, then it's probably pointless (or outright _harmful_) to assume you can do anything to correct the issues.
<br/><br/>


![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/lepc5dctpisjmq1kvayx.jpg)
## Onsite Culture
Most companies, _especially_ those with significant histories under their belts, have an overt _onsite_ culture.  Most-or-all of their employers work onsite.  Most-or-all of their leadership team works onsite.  They have a thriving water-cooler scene.  They encourage "management by walking around".  

I've learned from painful experience that, even if you find yourself in a conversation with an "onsite" company about a potential remote role, you might be setting yourself up for failure.  You may be able to talk an "onsite" company into letting you work remotely, but this often comes with explicit and implied caveats.  

"Onsite" companies rarely promote remote workers.  Nor are they likely to overtly recognize the efforts of remote employees.  They will often leave remote workers out of crucial conversations.  You may find that a critical meeting was held yesterday, during normal business hours, at a time when you were totally free to join the conversation - and yet, you only hear about it after-the-fact because the principals ended up ducking into a conference room and holding an impromptu face-to-face session.
<br/><br/>


![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/dprtngloxvhiktk9f1gd.jpg)
## Tethering
My online profiles now make it clear that I'm really only interested in considering _remote_ positions.  I only bother talking to recruiters if it's clear that they have an interesting _remote_ position to fill.  But even when they promise that the potential position is "fully" remote, there's another **_HUGE_** caveat that I've learned to avoid:
<br/>

> _Beware the "remote" job that's offered by a company located in your hometown!_

<br/>What difference should that make??  After all, if the job is a "remote" position, then it shouldn't much matter where _you_ are located, and it shouldn't much matter where your _employer_ is located.  _Right???_

Well, umm...

I've seen multiple scenarios where the "remote" worker, that everyone knows is located somewhere not-too-far from the corporate office, will subsequently get leaned on _to come into the office_.  They might drag you in for occasional meetings.  They might try to redefine your role as being remote... _on certain days of the week_.  They might assume that you're always available for a face-to-face whenever they see fit.

I've only found one solid solution to this: **Don't accept "remote" work for a company in your hometown.**  Just... _don't_.

When the company is in, say, Dallas, and everyone onsite _knows_ that you live-and-work in, say, Seattle, they're _far_ less likely to think that they can invoke your presence just by scheduling an in-person meeting.  When they know that an in-person meeting implies plane tickets and meals and hotels and travel time, they're not typically inclined to assume that you can be onsite whenever they desire.  But when they know that you're _right here, in their same city_, well... it gets a lot more difficult to keep them from taking liberties with your onsite availability.
<br/><br/>


![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/xjgp7ngnzyaobbs7cceq.jpg)
## Disjointed Communication Toolkits
Does the company have an "official" chat client?  If so, do the employees regularly _use_ it??  Does they have an "official" video conferencing solution?  If so, do the employees regularly _use_ it??

Look, it's easy to list the myriad ways in which chat can be an outright impediment to our work.  But when I'm working remotely, it's pretty dang important to me that the company has some kinda unified chat solution.  And that the employees actually, you know... _log into it_ from time-to-time.  And maybe even... _answer messages on it_ occasionally.  There's nothing worse than being stuck on a critical problem, trying to ping people over chat, and the message sits there unanswered - _for hours_.

How about video conferencing?  When the onsite folks have an onsite meeting, do they routinely connect, _via **video**_, to the remote team members?  Because it really stinks when there's a face-to-face meeting with everyone else - and you're stuck on audio conference.  It also stinks when some people in your company wanna use Google Meet, and others wanna use Zoom, and others wanna use Skype video chat, and others wanna use...

These tools can be "nice to have" when you're working onsite.  They can be downright critical when you (and/or others) are working remotely.  Be _very_ careful about working remotely for any company that can't be bothered to standardize on such tools and educate their employees on how to use them.
<br/><br/>


![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/hoxykhuc8ynhahmifth8.jpeg)
## Productivity Blindness
When a company has remote workers, they quite often have a primary fear:
<br/>

> How do we know exactly _what_ these remote workers are doing?

<br/>In the worst cases, the company's angst can more accurately (and more cynically) be voiced as:
<br/>

> How do we know _if_ these remote workers are doing anything?

<br/>This is a huge obstacle that keeps many companies from even considering remote work.  But it's also a huge frustration (for programmers), because the answer should be so dang _simple_!

In onsite situations, these worries are usually waylaid because you can simply walk by someone's desk and _see_ that they're working.  You may not know exactly _what_ they're working on.  You may not know whether they're working on it _productively_.  But even the worst manager can usually assess _whether_ a programmer is working - or just surfing the interwebs.

With remote work, this drive-by assessment isn't quite so easy, right?  Well... it _should_ be easy.  If you know what you're doing.

You see, if you're a programmer, your work is more "tangible" than that of other roles.  You're almost certainly working with some type of source control.  And, assuming that you're doing your job, you should be making _commits_ to that source control - if not every day, at least on a fairly-regular basis.  And yet there are still soooo many "onsite" companies who fret about _what_ their remote devs are working on - or _whether_ they're working at all!

Some will read this and protest:
<br/>

> But my manager isn't a programmer!  And my manager isn't in source control.  Or they're not comfortable perusing code commits.  So they still have no real idea what I'm doing!

<br/>This is a topic for an entirely separate article, but if your manager isn't even _in_ source control, then they shouldn't be your manager.  If they're in source control, but they don't know how to browse your commits, they shouldn't be your manager.

To be absolutely clear, I fully understand that dev managers needn't always be proficient coders themselves.  But I've seen sooooo many scenarios nowadays where the devs on a particular team all report to a PM or some other non-technical type who literally can't even _view_ the GitHub commits.  And I've come to feel, quite strongly, that this is a potential problem.

Imagine that you're a plumber on a construction site and you report to me, the foreman.  But there's a problem.  Even though I'm the "foreman", I actually know _nothing_ about plumbing.  In fact, I'm so ignorant of it that I can't even look at the jobsite and determine _whether_ any plumbing work was done today at all.  Does that make any dang sense to you???

In that scenario, every day, you come to work and you complete a bunch of plumbing tasks.  And the product of your work is plainly available for anyone to see - assuming that they _know_ what they're looking for.  But I _don't_ know what I'm looking for.  So every day, I need to keep asking you to explain what you've done.  Because I don't have the basic knowledge necessary to walk the jobsite and _inspect_ the work you've done.

Unfortunately, this scenario plays out all-too-often in remote coding environments.  I plunk away all day on the code.  At the end of the day, I commit my changes (even if I'm not done with the particular task at hand).  On many days, I may have committed _hundreds_ of lines of code.  Yet the next morning, my manager (the _Project_ Manager) has to ask me for a verbal recap of what I've done.  And if, for some reason, I'm not available for that status call for a few days in a row, the PM starts to wonder whether I've done any work at all - even though I've committed _piles_ of work to the branch!

I haven't seen this scenario cause too many problems in onsite gigs.  Because in onsite gigs, if anyone starts to get nervous about the effort being made, they just _walk by your desk_.  But too often, when you're remote, this scenario can lead to all sorts of bad feelings and misunderstandings if the team isn't well-constructed.
<br/><br/>


![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/q0kgytj5i30pj2oor0rs.jpg)
## How To Change Your Employer
Once you've learned to recognize all of these problems with employers of remote workers, you may be tempted to think:
<br/>

> OK, so... How do I go about correcting these problems with _my_ employer??

<br/>And to this basic question, I'd respond:
<br/>

> Don't.

<br/>That's right.  It's not a typo.  Just... don't.

If that sounds defeatist, please try to put this in context.  Most of the issues I've outlined above have deep roots in a company's _culture_.  If you're trying to change a _policy_, that's one thing.  But if you're trying to change the underlying _culture_, well... Good luck with that.

I truly believe that some (possibly, _most_) of today's company's are poorly-equipped to handle remote workers.  It's just not in their DNA.  And trying to drag them into remote work, kicking and screaming, will only result in you getting kicked and screamed at.

Think about it like this:

Imagine we're friends and I tell you that I've just started dating this amazing new person.  As I tell you more-and-more about my new love interest, it becomes painfully clear to you that there are some, umm... _problems_ with my budding relationship.  But when you try to point out these problems to me, I respond, "Ohh - that's all OK.  Because I'm going to _change_ them!"

I hope that I don't have to explain the flaw in that thinking.  But too often, we have this dream of remote work.  And we're so focused on the dream, that we'll try to force ourselves into a remote position - even when it's clear that the employer doesn't have the culture needed to properly support remote work.

In my experience, getting yourself into a solid remote gig isn't about bending an inherently-onsite company to your will.  It's about finding a company that's _already_ well-positioned to support a remote workforce.  

Is it possible that you might manage to fix a few _small_ issues that your current company has with remote work?  Sure.  I suppose.  But if your current company has an entrenched _culture_ of onsite-first work, then I seriously doubt whether you're going to find long-term, remote-work happiness through them.