There is a stigma attached to remote work.

“When I give your résumé to [our board member] to distribute to his network, don’t tell him up front that you’re looking for a remote position. He has a low opinion of remote teams. He doesn’t think you can succeed as a startup with a remote team. I actually agree with him.” — the CFO of my former remote company, on circulating my résumé after I was laid off.

I experienced the bias against remote work starting with my cohort at Hack Reactor. When I was discussing my job search experience with my colleagues, when I mentioned that I was leaning strongly towards accepting an offer with a remote company, the reactions almost always included follow -up questions about why I wanted to work remotely, and did I think that was the best choice? I noticed that I had internalized some of this attitude, even before actually talking much about it with my colleagues. I held a nagging feeling that I was perhaps going to miss out on something wholly important, yet undefinable. I found myself wondering what if everyone was right, what if I was really missing the boat by not putting myself into an office environment to maximize for mentoring, and career growth opportunities?

I still wonder where these negative views originate, being pervasive enough to have been mirrored by both my colleagues, and the CFO of a remote company!

So, what was my experience as a remote employee, managing sole ownership of our front end technologies for over 2 years?

Here are my observations and anecdotes about what remote life is actually like, presented as a set of comparisons around common lifestyle snippets between the original office and remote life:

Some facts about my remote team:

  • We shipped on-time, high-quality, tested software.
  • We functioned well as a team.
  • We supported each other and had good team chemistry.
  • When we needed to collaborate in real-time, we used screen sharing and video chat technology, or in some cases got together in our physical office.
  • We used agile/scrum methodologies for sprint tracking, including estimation and a ticket system.

So, given the fact that the product team was eventually laid off, what went wrong, and where did the problem with our remote team lie?

One theory that I have is that the product failed, not because of what the remote product team did or did not do, but because we executed on the product requirements we were asked to implement. Our product failed in the marketplace, not in the product team’s execution or delivery. Looking a little further back along the chain of events, the deal-breaking variance lay between our executive orders around product requirements, and the actual demands and trends of the market.

The next question that arises for me is: would we have done any better as a company in delivering a successful product, had we all worked together in an office? I can’t see how that would have had any effect on the broken part of our organizational efforts. Again, we were missing the concrete market feedback that comes from real user stories and product feedback. That involves research and methodology that falls outside of the purview of the engineering team.

Given everything that I’ve described above, it should be clear that I am biased towards remote culture, having found it an unexpectedly excellent match for my temperament and work style. Revisiting the inherent bias that was shared amongst my colleagues while we were all job searching, was there any merit? Have I felt like I’ve missed mentoring, or career growth opportunities because I accepted a roll with a remote team?

Actually, just the opposite. By not being surrounded by other engineers, and being solely responsible for everything related to JavaScript on our team, a powerful motivation for personal development arose. Since I was never able to tap someone on the shoulder for help, it forced me to engage in a lot of systematic thought and organization around workflow and problem-solving strategies. I quickly ramped up on my google-fu, and stack overflow/MDN research chops. I employed shortcuts such as using Dash for documentation reference, and text snippet creation for common sequences and text entry patterns. And what it did for my confidence is both immeasurable and invaluable. I developed a sense of security around being able to progress through difficult stages of growth, handle steep learning curves, and keep my head up even while harboring feelings of despair or “hitting the wall”. And the repetition of this experience has led to a stamina and determination that has been conducive to constant progress within the discipline of software engineering.

I would like to see remote culture continue to grow. In summary, my plea to companies that are in charge of setting up engineering teams:

“Let your coders write code”

LEAVE A REPLY

Please enter your comment!
Please enter your name here