Going Remote, Staying Effective

Earlier this year, I embarked on an adventure to get closer to my family and transitioned from a management role in Silicon Valley to a remote software engineering role in a small town in Texas. The journey has been challenging and also very rewarding. Now, eight months after starting that process, things have finally settled to a point where I feel productive and can efficiently deal with the challenges as they come my way. Given that today is InDay at LinkedIn and that the theme is about Learning, I wanted to share some of the things that I have learned while transitioning.

As a software engineer on the Feed team (homepage), I have the opportunity to see some really unique challenges. From decreasing page load times though succinct code optimizations, resulting in improved member engagement and revenue, to catching potentially dangerous security flaws - being on such a high-profile team and building something for our over 450 million users globally is both an exciting opportunity and a challenging one. It also should be mentioned that the people I work beside are extremely talented, which helps!

Transitioning into a remote engineering role while still being able to have that sort of impact was not easy; some days, it's still not easy. But through discussions with my leaders and mentors and some learned lessons, I've reached a point where I recognize remote work is a viable avenue for those in need of it and, even at scale, it can be effectively accomplished.

Articulated, Continuous Communication

It became clear early on and through the advice of other remote employees at the company that I would need to be emphatic about communicating continuously and clearly. Luckily, my team had already established a strong cohesiveness in communication through the use of Slack. In the past, it was every chat client for itself in a large team of people who favored one experience over the other.

I can't say that I experienced a communication gap, in terms of having access to specific people; Slack solved that and scaled well. I can say though that this is one problem that I'm sure many others face and is absolutely vital to fix early on. Having [name_companyname@chatprovider] accounts is not a solution.

Chat clients aside, I still found that if I didn't reach out to people on my own volition to refresh that connection with them, it would dwindle. To compensate, I made it a point to regularly engage in conversations online, even if they weren't directly work-related. Sometimes a good dad joke goes a long way to catching the pulse of a colleague in the midst of a big project. For example, what do you call a dog that can do magic? An abracadabrador.

Also, as problems arose, I found that it was critical for me to phrase things clearly and include as much detail in messages as possible to avoid the back-and-forth volley for clarification. To do this, I now do much of my research upfront before I send off an email or open a chat thread. By well-forming my messages in advance and focusing on being concise, I'm able to cut down on the amount of time I spend and the confusion people have when solving problems over the wire.

Being Present

If you read up on tips for remote work, you'll find that one of the common recommendations is to be present in meetings and discussions. I found that my team was very receptive to adding Video Conferencing (VC) to any meetings we would have, including daily stand-ups. However, at times, meetings with other teams or individuals would come up that would require me to be self-disciplined enough to ask and possibly help coordinate a VC session.

That being said, I make it a point to try and be on time, if not early, to any VC meeting that I am a part of. Doing so allows me the opportunity to engage in casual conversations with others - an effective and simple way to keep those relationships fresh.

Being remote also made interviewing candidates a bit tricky. I was able to work with my management to adjust the type of interviews I received from a combination of phone and in-person to only phone interviews. Prior to each interview, I take about ten minutes to reach out to anyone joining me in the interview (co-workers) to introduce myself, explain my situation, and provide clear steps on how we can accomplish a successful interview. Once my co-worker is in the room, they will call me, we'll have a brief chat about questions and the candidate's background, and then we'll conference them in. In almost all cases, the candidate never knew I was remote.

I compensate for my lack of presence by increasing the detail in my feedback of the interview. Over the last few months, I have seen several emails come back to me and my managers about the improvement in quality of my feedback, which is awesome and shows that I'm moving in the right direction. I'm now striving to share that approach with those who join me in the interviews to make the process clearer for our hiring committees who review the feedback.

Technology Hindrances

In an enterprise environment, codebases aren't small. When those applications run on your computer, they tend to consume resources. When you run those applications through a VPN tunnel on a wireless connection, you set yourself up for a bog down of productivity, especially if the data stores, APIs, and other portions do not reside on your machine.

When I first started working remotely, I found that some applications took an inordinate amount of time to build and run. Coupled with the need to debug them and sift through logs, I found myself spending more time doing less. In a cathartic weekly discussion with my manager about these frustrations, I was offered a perspective that I had not considered before - this is an enterprise organization and we have to deal with problems that enterprises face. He advised me to focus on batching my changes, multitasking, and coming up with creative ways to not get blocked when something would hold me up. His advice was instrumental in changing the way I worked and has made the difference.

(Disclaimer - geek talk ahead)

<geek-talk>

To date, I have two machines - one that lives in an IT closet with other machines in the main office and my laptop here at home. I run most of my code on my machine in California and utilize technologies like SFTP and SCP to propagate file changes from my local machine in Texas to my workstation. The files are on my computer in front of me and, when I change one, it automatically gets uploaded to my machine at the office. Since that machine is not connecting with resources through a VPN tunnel, it can work more efficiently (that and it has twice the number of cores and four times the amount of RAM my laptop does). Still, this setup is not ideal for debugging server-side applications, meaning step-through debugging in an IDE is still a cumbersome if not impossible process.

Luckily, our transition of LinkedIn.com to a Single-Page Application (SPA) means that the bulk of the web work no longer lives on a "web server" but rather on the client. The result of this means that what goes across the wire is requests (data), not the entire webpage and assets. As such, my developer productivity has increased tremendously - another not-so-obvious benefit to tout about SPAs.

</geek-talk>

Deferring Judgement

Early on, one of the problems I faced while being tethered to my team through an internet connection was the lack of a certain emotional dimension to conversations. When people are face-to-face, communication provides much more information than through a chat client or email. You can typically understand the state of someone's emotions by the tone of their voice, their facial expressions, and body language. All of these traits are lost to text, which makes things like frustration or sarcasm much more difficult to interpret.

Likewise, I found that I had to get into the habit of not reading too much into delayed responses (or no response at all) or overlooked discussions. When I first transitioned, if someone didn't respond to me, I assumed they didn't want to respond to me. In all cases, however, it turned out they were just busy. I made it a point to send messages and then move on to other things. If a response didn't come back or if someone declined my invitation to talk, I chalked it up to them having other, more important things to do.

The imposter syndrome that is so rampant in the software engineering world and one I overcame with time, returned back in a different form and it took me recognizing that and learning to tame it for me to see things for what they really were.

Digging In Deeper

When I first starting discussions about going remote, one of my main concerns was career growth. You can find a number of articles that bring up this topic with phrases such as "out of sight, out of mind". I have found that it does take the right organization and talented management to recognize this. LinkedIn, in my opinion, is the poster child of the organization for working professionals. We not only dogfood our own product with passion but we strive to be the example organization that others can follow. I say this because, at first mention of this concern, I was reassured that remote work would not hinder my career growth. In fact, I was told that it might help due to an increase in productivity.

Being away has not slowed me down from continuing to dig deeper into the characteristics we embody as engineers at LinkedIn - Execution, Leadership, and Craftsmanship. I attend weekly one-on-one VC meetings with my managers, actively discuss areas of improvement for career growth, deliver tech talks and brown bag presentations through VC, and even speak locally in my hometown and abroad.

In conclusion, I do believe that being a successful remote employee depends both on the culture of the organization and their willingness to facilitate it as well as the employee's dedication to making sure its a success. I've learned a lot in the last few months and I look forward to learning more.