Going Remote

I rediscovered I wrote this article after going through some old blog drafts last week. My co-workers encouraged me to post it so here it is.

Switching from a traditional in-office job to a remote job puts your habits and skills to the test.

Positive habits developed in a traditional office settings often have negative results in a remote setting.

  • "Just get it done"
  • "I want to see results"
  • "Can you help me sometime later today?"
  • "I'll grab you when I can"

Each of these things have been often encouraged by prior employers as ways to get ahead and be an effective team member. However since going remote five years ago, each of these habits has gone through a systematic process to undo them.

Just get it done

My fictional boss Stephen comes in with his morning coffee and on his way to his office says, "I have a project I need done, meet me in my office in five minutes." I grab my notebook and head into his office to find out more. The next thirty minutes are spent covering a new initiative that needs to be addressed by next week. If I am to do it right I know I better be thorough before stepping out of the meeting less I forget an important detail.

Starting out my career as a junior developer I yearned for the opportunity to do the 'fun pet projects' that my senior peers worked on. I'd pressure my boss with a 'why not me?' argument whenever the opportunity presented itself. It took me a few years to realize what made my co-workers 'pet project worthy' was they "just got it done" and as I result I learned to do the same.

This worked out great and I quickly was the one called on for the majority of projects. However, when I switched to a remote position I realized this approach is detrimental to my career.

Where is Justin? Let's go over to his desk.

There is a major difference between being in an office environment and a remote environment: PEOPLE CAN SEE YOU. I am aware I just stated the obvious here, but let that sink in for a minute.

The "just get it done" approach exchanges direct communication for observational communication. What I mean by this is instead of me nagging my boss for clarifications and additional requirements, we instead communicated progress by observing: staying late, being the first one in, and having working lunches. He knew, or more accurately he assumed, that every step of the way I was busting my ass to get the project done. He didn't come ask me, he judged by what he saw. This observational communication built a level of trust between us that was pivotal for the whole system to work.

Now I know that my boss seeing me in my seat doesn't mean that I'm going to make the deadline or that I'm not struggling, that is not the point. The fact of the matter is, this is how it worked. He was reading my body language and used that to reaffirm his assumptions. It is not ideal, but it's the reality.

Is Justin alive? He hasn't posted in chat.

In a remote environment body language goes out the window as it's not possible to see. Even when on video you often cannot trust it due to latency or other technical delays. This means all of the observational communication mechanisms we used in-office no longer function correctly. It is worth noting though that our habits can drive us to manifest observational results even in a remote environment.

What I mean by manifesting results is we look at organizational 'water-coolers' as a stand-in for the in-office desk. If I need a status update on a project I instinctively go look at my emails, chat rooms, and even Github repos for signs of life. This is my virtual way of searching the office for the person who isn't at their desk.

Regardless of environment, I can tell you from experience there is no better way to lose trust in someone when you need answers to something and they are no where to be found (regardless of environment)

Replacing "just get it done" with "notify and handle it"

Folks working in a remote environment have a shared responsibility to each other. They must "fill the void" left by the lack of behavioral and observational communication with written communication. This is why I suggest folks working in this setting replace the "just get it done" approach with a "notify and handle it" approach.

The adjustment that needs to be made for the "notify and handle it" approach is actively communicating out the events come up and handling them accordingly.

Notification

To clarify what I mean by an event, I am talking about anything of interest, planned or unplanned, setbacks and milestones. Actively communicating out these sorts of things builds trust all around. It instills a sense of trust that nothing is being missed or fallen through the cracks.

Handle it

The "just get it done" approach follows the idea that when you are assigned something you do whatever it takes to get it done. This part goes unchanged when remote. The difference is really in the notification step it's paired with. If something unexpected happens I will figure out my options and come up with a recommended solution to the issue. From there I'll quickly pop open my email and kick off an email to the invested parties:

Team, I ran into an unexpected issue with firewall rules one of our web nodes that will prevent us from using web sockets safely. I've looked at our options and suggest that we set up some boxes in a DMZ zone to bypass this issue and still maintaining security of the existing servers. - Please let me know if there is any issue with this approach or if you want more detail. I'd be happy to set something up.

I'd usually at this point give it an hour before I jumped on doing the solution just in case I misunderstood. Otherwise I'm off to implement what I mentioned above.

This isn't an exact science, it's understanding that when remote you must keep folks abreast as to what you're working on. Without it people begin to wonder if your stuck or heading off track. These quick emails serve as a reminder that you are neither of those things.