Skip to main content

How remote work can work for sysadmins

A look at the benefits and pitfalls of remote sysadmin work and how to make it work for everyone, including managers and the organization itself.
Image
Working from home.

Work From Home (WFH) is an ideal situation for many workers these days, including sysadmins. There are many reasons that WFH is a sought-after perk that, while it may not be a deal-breaker, can reduce the desirability of a particular job. I have had several jobs that allowed me varying levels of freedom to work from home and I have been very happy to do so, but not everyone views WFH as the great opportunity it was to me.

So let’s look at working from home and how doing so can work well or poorly for all of us. By this statement, I mean all in the sense of working for sysadmins as well as our managers and the organizations we work for.

Defining WFH

Before we go any further let’s define what work from home really means.

Back in the day, my parents would bring home a briefcase full of papers to read and comment on, and which they took back to the office the next day. I did this too, for a few years. Once computers morphed into laptops and PCs that could be connected from home or a coffee shop, the documents and files moved onto the computers we carried around with us, but not all could connect to the internet.

In today’s world, we can access any server or cloud located anywhere in the world, from anywhere in the world where we can access the internet. Yes, this does include our homes, but by definition, WFH can apply to anywhere with an internet connection. I have worked remotely from a condo on the beach and from an airport lounge. I have worked in coffee shops, airplanes, trains, my own home, hotel rooms, conference rooms, and more, whether connected or using local copies of my documents.

So WFH really means working remotely. When working remotely in this connected world, we can work from anywhere that has an internet connection, whether that be from home in North Carolina, a cafe, a hotel, a river cruise ship in Europe, or an airplane.

So from here, I am changing the language in this article away from WFH to Remote Work (RW), just because that is the fact. In a technology-based world where internet connections are common in most places, the difference between home and hotel is irrelevant to the work I am doing.

Organizational policy

Most organizations have some sort of policy about remote work.

In many cases, the policy is a simple “no.” In others it ranges from the unofficial version, “you can’t do it unless we need you to at 2 am,” to an official version of, “Fridays (or another selected day) are remote work days,” to the laissez-faire, “we don’t care where you work as long as the job gets done, and you occasionally call in to the weekly staff teleconference.”

Some organizations are so geographically widespread that physical meetings are nearly impossible on any basis at all. In these cases, it is plainly expected that everybody will work from wherever they are. Many open source communities are like this: Volunteers from every part of the globe who work from wherever they are and who nonetheless collaborate effectively.

In another option, some organizations don’t bother with cubicles. They allow everyone to work remotely and provide open spaces sometimes called landing zones at their physical location. These landing zones usually consist of a small desk, power outlets, and wireless connectivity. Anyone who is physically in the office on any given day can use a landing zone for as long as necessary. Other organizations use rented office spaces for meetings, but these spaces don’t make sense for remote workers who cannot physically attend.

My experience

I have had many different jobs and a number of opportunities to work remotely. The restrictions and results varied widely and you will probably recognize some of these situations.

The good

One modern and progressive technology organization I worked for was amazing. This place had a very liberal remote work policy. We could work one full day from home each week. The hours were so flexible that some of us did not come into the office until noon or even 3pm while others came in early and left early. I used to start at 6:30am to miss most of the morning traffic entering Research Triangle Park (RTP) and leave at 3pm so I could miss the evening traffic on the way home. In itself, this saved over an hour of driving time each day, so the early hours were well worth it. That flexibility was important to me and to many of my colleagues.

So long as one’s work was finished on time and we showed up at team meetings in person, we were pretty much free to come and go at will.

This organization also provided us with laptops and software VPN services that allowed working from anywhere with an internet connection. On those few occasions when I needed to perform some task that I could not set up as an at job or a cron job, I could log in and take care of business whenever and wherever.

The bad

One organization I worked for was fine with some aspects of remote work but quite regressive in others. In this job, I was not provided a laptop, but I did have SSH access to the network from my home.

I could check on the servers when I woke in the morning and perform maintenance in the evenings. If I was sick or contagious enough to stay home, I could work remotely if I felt good enough to do that. However, the basic requirement to be on site and at my desk was there, and remote work as something normal was forbidden by policy. Mostly this remote access for fixing 2 am disasters.

Essentially any remote work that was officially allowed benefitted the organization and not the sysadmins and other workers. However, the decent managers would allow us enough flexibility to work remotely until a morning doctor or dentist appointment, and then head into the office after. But this was far from a given as it was explicitly not allowed by policy.

The ugly

I worked at one fossilized organization that was the most horrible workplace I have ever experienced. This organization was—and probably still is—a fantastic example of the traditional team methodology taken to its ugly extreme. I remained there for about a year. The worst part for me was that working there also entailed a horrible daily commute of 110 miles round trip.

In this organization—which shall remain nameless—the PHBs (pointy-haired bosses) had created very narrow, very tall silos to contain everything. There were multiple teams: the Unix/Linux team, the Windows team, the mainframe team, the application team, the network team, the hardware team, the DNS team, the rack team, the cable team, the power team, and the data center team. Pretty much any team you can think of.

And the procedures were mind-boggling. For example, one of my projects was to install Linux on several servers for use in various aspects of the organization’s web site. Except for installing the operating system, we could not touch the server. We were not even allowed to enter the server room. Ever. So we had to install Linux in a staging lab, and after many weeks of requests to various silos, the servers were moved to the server room across the street and we never touched them physically again. The data center team would do whatever work required physical access to the servers. Overall it could take from four to six months to slog through this process to get a single server installed and operational.

Although the servers were in the building next door, the sysadmins had remote access via SSH. So we were already working remotely while only a few yards from the computers. Yet we were not allowed to work remotely from another building much closer to home that would have reduced our two hours per day round-trip commute to less than 30 minutes. We could not work from home unless the org wanted some work done at 2 am or in an emergency.

We were even not allowed to leave our “remote” cubicles next door to the servers until exactly 5 pm, quitting time and not one second before—and, yes, they did check up on us. The reasoning was that there might be an emergency. Although the nature of any emergency that would require us to work 55 yards from the computers that could not have been performed from 55 miles eludes me.

I could go on about many more ways in which this place was a functional disaster, but I think you get the idea. Their alleged teams were just political fiefdoms, protected by impenetrable silos. The point being that remote is remote, even if it is only a few yards distant and that some PHBs are incapable of discerning that fact.

And now…

This short list of my own experiences would not be complete without a discussion of my experiences as a self-employed consultant, and more recently as an author.

For a few years at scattered times in my career, I worked as a consultant, having organized as an LLC. Other than times when I was truly needed at a client’s site, all of my work was done from my home office. Although the client was the boss when they were paying me, the contracts they signed allowed me to work from wherever I wanted.

And now, I write many articles for Opensource.com and now for Enable Sysadmin.  In this new role, I find myself working from home most of the time. Although I have friends and contacts at Opensource.com, and we have a weekly teleconference, there is no compulsion to attend. Those of us who write and fill the roles of Community Moderators are not necessarily employees, we are volunteers. So as volunteers, there is no financial or other job-related impetus to join these conversations. And yet I do when at all possible because I like to share ideas and with other contributors to a project I care about.

Others’ experiences

I placed inquiries about RW on some social media sites, aiming them at sysadmins and others who might work remotely. Most of the results were positive and offer some interesting insights:

B. Son emails this comment: “Nice for company to offer that as a benefit, but it is possible that the employees can misuse that. But if a company hires the self-motivating employees, then the company can trust that the remote working option can work well positively.” Son went on to say that at a previous place of employment, “the company’s department tried to test out how remote working option is good or not before rolling-in to the teams. So, one day, our team consisting for 30 or more hit [a local bakery and cafe with WiFi] and decided to work there together for one day. Here are some problems I noticed: 1.) We did not anticipate or plan out that the wifi connection there is so bad. 2.) Even though we are supposed to come there at 9:00 a.m., many people showed late, etc. 3.) The space was so crammed, and I doubted that much work has been accomplished.”

C. Hermansen responds: “I used to think I could not work from home. Then in 2006-07 we moved to France for a year and the only place I had to work in was the family room. So I did, and guess what! I actually enjoyed it. What I came to realize was that I spent so much time in the office on the phone talking to colleagues in other offices that there wasn’t much reason to be there, except for the 1/2 hour bicycle commute each way. I have mostly worked from home since 2012, except for occasional trips to the office which is these days in Santiago Chile.”

S. Nesbitt responds with the fact that most of his employers, “discouraged or just plain didn’t allow working from home,” and went on to say, “The few times I have worked from home, there have been good and not-so-good points. The lack of workplace distractions was a bonus – I … actually got a lot more done in less time. Avoiding the commute and all of its hassles removed a bit of stress from the day. On the not-so-good side, you can feel isolated. Email and messaging apps aren’t viable substitutes for face-to-face interactions. If you work with a good team, you’re missing some or all of the dynamic that occurs when the team is together.”

M. Bursell says, “I’ve worked from home for much of the past 10+ years. There’s a discipline to it, and it doesn’t work for everybody, nor for every job, but it works for me.”

One person who responded says, “The in-home distractions are real, whether it is just goofing off, housework, or family. Even worse when you have kids, AND your spouse has to work too. Because someone needs to take care of the kids, it invariably is the person at home.”

As you can see, people have a range of experiences with remote work. Not all of them are good.

Widely accepted

Sometimes called telecommuting, remote work has become very common in today’s connected world. The U.S. Department of Labor’s Bureau of Labor Statistics reported in 2017 that 23% of workers performed “…some or all of their work from home.”

REMOTE.CO, founded in 2015, is one of many new companies that feature on-line boards that deal exclusively in jobs that allow or require remote work. At the time of this writing, REMOTE.CO lists hundreds of jobs in 17 categories. Red Hat was advertising a senior DevOps engineer position with remote work from pretty much anywhere in the western hemisphere. Many other well-known companies, and some not so well known, also have remote work jobs posted on this site.

REMOTE.CO has a blog post, 17 Stats About Remote Work in 2018, that I found interesting. Each of the listed statistics supports the position that remote work is beneficial to all. Not that I disagree with any of these items, but the web site of a company that depends on organizations and job seekers that are explicitly interested in remote work is unlikely to publish negative statistics.

I also found this opposing view during my research. Forbes published Survey: Remote Workers Are More Disengaged and More Likely to Quit, in which Dan Schawbel discusses the management view of why bringing remote workers back into the office was a win for one company. This change was based on the fact that many of their remote workers needed physical face time with peers, as mentioned in Nesbitt’s response.

Making it work

So with all of the preceding as background, the question is, “How do we make RW as effective as possible for both organizations and workers?”

I can guarantee that there is no single, easy answer. One large factor is the many different relationships between the entities involved. The varied traits of both the organizations and the workers are also important factors.

But it is clear that some things must be true for each side.

First and foremost, it is important for both sides in any remote work arrangement to be open about what they each want from the relationship. Organizations typically want specified work products while workers want a level of freedom and autonomy as well as some form of remuneration, usually money. These needs and expectations must be clearly and openly defined on both sides in advance of entering into a relationship of this nature.

Also, the expectations and any policies surrounding remote work must be clearly defined and documented by the organization and then provided to sysadmin job applicants before or during the interview.

The experiment at the cafe was clearly a failure in B. Son’s story due to lack of planning. Just stating, “Today we are going to work from <pick your favorite location> as a remote work experiment,” is not a real experiment. Aside from issues such as distractions and limited bandwidth, someone clearly gave in to pressure to allow remote work and attempted to create a situation as close to an office environment as possible. Come on—really? Remote work with everyone in the same remote location?

Any experiments should be carefully planned and executed. However the idea is not to determine whether remote work is a viable option—it has been well-established that it is. The objective in any experiment of this nature should be to learn how one makes RW a viable option for both workers and the organization. Taking this approach requires time and effort to create a workable solution with reasonable policies.

Of course, these experiments can be rendered irrelevant by the use of outdated efficiency methods such as measurements based upon 150-year-old time and motions studies that were designed for the early era of industrialization. These ancient methods have become KLOCs (Thousand Lines of Code) per day, and even more stupidly, keystrokes per time period. I discuss these destructive forms of measurement in Chapter 23 of my book, The Linux Philosophy for SysAdmins.

Besides setting expectations on both sides, there needs to be a level of trust. Regardless of the specific circumstances that lead to an RW arrangement, both sides must trust the other. The organization must trust that the work will be performed and completed on time. For some types of work, like coding, testing will follow to verify that the specifications have been met. For a sysadmin, the proof is in the continued smooth operation of the network, servers, and desktop hosts assigned. This evidence should certainly be supported by some form of written log kept by the sysadmin to describe the work performed—a best practice in any event.

As a sysadmin and a remote worker, it is important to understand our own personalities. Some of us require almost daily interaction with people while others thrive in solitude. I can work either way, as can many of us. If you need and thrive on regular interaction with your teammates, though, remote work is probably not the best choice for you.

Boundaries

I find that boundaries are necessary for us as sysadmins. It is very easy to fall into the habit of working many hours remotely and off the clock that don’t get included in staffing calculations. If those responsible for a department’s staffing requirements are unaware of the otherwise unrecorded—or at least unnoticed—work time, the department will never be properly staffed for the true amount of work it does.

It is also much too easy to spend the time we need in relaxation and being with our families, instead of working on things that can actually wait. It is important to take care of ourselves, and remote working at all hours just because we can is not healthy either physically or mentally either.

Remote worker boundaries can also include taking breaks during the day, and being available at specific working hours just as if you were working in an office.

Iterations

Working remotely can be used to provide occasional flexibility in supporting the sysadmin’s personal life while meeting their responsibilities to the organization. RW can also be used full-time as the only possible option that will entice great sysadmins to work for geographically remote organizations.

With all of the different organizational and personal needs and personalities, the key to having a successful remote work relationship lies in flexibility and honesty. If something is not working, admit it and then work together to isolate the cause and make changes to the arrangement. It may take several iterations to make remote work a success for all concerned but it can be well worth the effort.

Topics:   Sysadmin culture  
Author’s photo

David Both

David Both is an open source software and GNU/Linux advocate, trainer, writer, and speaker who lives in Raleigh, NC. He is a strong proponent of and evangelist for the "Linux Philosophy." David has been in the IT industry for over 50 years. More about me

Try Red Hat Enterprise Linux

Download it at no charge from the Red Hat Developer program.