How Employers Sabotage Remote Workers

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.

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.

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:

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

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.

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.

Productivity Blindness

When a company has remote workers, they quite often have a primary fear:

How do we know exactly what these remote workers are doing?

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

How do we know if these remote workers are doing anything?

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:

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!

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.

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:

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

And to this basic question, I'd respond:

Don't.

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.