Working Remote, Somewhere Between Bliss & Distress

Before I get into the details working somewhere between bliss and distress. it’s worth mentioning some motivations for working with a remote developer. Some markets are saturated and it’s difficult to find local talent. At times, teams are seeking to hire senior talent and looking for ways to make it more attractive for developers to make change. In some cases, a project is short term; and hiring a contractor or consultant is the best way to help a project take flight (we’ll build the airplane in the air). Other times, its more strategic, why invest capital in brick and mortar, in headquarters, when you can put cash into infrastructure and teams? For developers, the motivation may be to make up for lost time and stay closer to home; or, to make time for travel. There are a wide range of motivations why companies and their employees decide to work remotely.

I’ll start with a tale of… when it fails. Simply put… no one at the company is really convinced that they will benefit from the learning it takes to work with a remote team member. Or a remote developer has no real interest in being a team player. It’s more of a compromise… “This is a talented person, how could we pass him/her up?” Or, “We can figure out how to work with a remote employee. How hard can it be?” Alternatively, “We already work with contractors in this or that location, and that works fine.” It starts like so… “We’d like to extend you an offer that I think you can’t refuse, we are happy to work with you remotely and although we don’t have any employees who work 100% remote we’ve had success working with contractors. We can build on that.” Here is the error, an employee is not a contractor, there isn’t a fixed date as a finish line, nor is there motivation from the business to gain an expected outcome like there is with a consultancy. If the business thinks it’s ok to treat the remote employee like an offshore developer, it just won’t last. Not only will it fail fast, the work may not even matter. I worked at one company and for the first 3 months another developer basically threw away all the code I contributed toward browser compatibility (for their beta product). What a waste of effort and resources. In this scenario the business does not posses conviction about the value they gain from learning how to work with a distributed team, it’s more of an experiment. There’s no real skin in the game. When you recognize this, it’s time to make a change, do it gracefully and swiftly. For this (solo) remote developer on a team, the experience is dominantly characterized by distress. In this scenario, there is nothing healthy for either the business nor the “second class” employee, known as the remote developer on a team of in-house developers.

Please note that there is a huge difference between “working from home” as a privilege and “working remote” as a lifestyle. Because a team has a flexible schedule that does not mean it can maintain success with a distributed team. If one team member is distributed everyone needs to know how to collaborate or the work suffers. In-house team members blame the remote developer and don’t include the remote team member in discussions about the project, or design of the product, etc. Having a remote employee means finding a way to make that employee a “first class” employee vs. a “second class” one. The result of treating remote employees as first class is that the organization benefits from the investment in learning how to work with one or more remote team members.

There is another scenario when… it half works. Some in the company like the benefit of having remote workers; however, they see remote work as a privilege. Based on this perception they reserve some aspects of working together for only during in-person exchanges. This is closer to working with a flexible schedule than to removing remotely as a lifestyle. The business has made a compromise; for what ever reason, maybe desperation. It is normal to plan for remote workers to have some face time with the team. But in this case, the business sees work from home as a privilege and incapacitates potential learning and advantages gained by working with a distributed team. Many conversations are saved for in-person exchanges instead of embracing successful practices of distributed teams, e.g. asynchronous communications. The in-house staff find ways to insist on synchronous communications. Since that can rarely happen, communications are extremely limited. The result is mismatched expectations and failure to work effectively toward common goals. Working remotely requires solid communication on both ends; and partial effort, does not lead to success, you get out what you put in. Sooner or later in this scenario, the remote employee gets burned, or becomes the scapegoat.

A third, and somewhat more honest approach is …trying to learn how to add remote workers to a local team. This happens when… some at the company realize there are benefits from learning how to change their current work patterns by the addition of remote workers. It is ok to not to have it all figured out – both onsite and offsite parties understand that the rewards are deferred – until there is a change that takes place, which makes it possible to reap the benefits from a new way of working together. This is still somewhat experimental; but for all parties, it affords growth and discovery of new patterns for success. The circumstances around when to begin this experiment may not matter as much as having skin in the game. Both employee and employer gain from this investment of time and labor toward expanding a team beyond their current geographic limitations. By hiring a remote employee who has experience in both succeeding and failing when growing a distributed team, the company can side-step some pitfalls of figuring this out for the first time. The in-house team and collaborators will need to learn new habits; and find ways to include others that are remote. Open communications and making time for in-person team events, e.g. a week in the office each quarter, a few lunch events or off-site activities can help provide course correction along the way. As long as everyone stays engaged in this effort, eventually the remote employee is just a normal employee who only comes in on occasion for social or strategic meetings.

The final scenario is… when it just works. This can be blissful for remote workers and company in-house staff as well. Many at the company have confidence in the reaping the benefits from working with remote workers. Stakeholders, in-house, and remote team members (whether located primarily on- or off-site) all have found a way to operate and communicate effectively and successfully. Location is not a factor which limits communication and collaboration. Teamwork is typically successful when someone in upper management / or in a position of leadership and influence fully embraces the practices that support working with a distributed team. When planing meetings, there is always an online meeting option, and call-in phone number as a back up plan. Teams use online tools to collaborate. One quote is, “if it didn’t happen online, it didn’t happen”. Artifacts necessary to communicate scope of work or specifications for features (or systems) are readily sharable using online tools. Communications are most often asynchronous, The chat rooms are used by both on- and off-site team members. Everyone is included in conversions and when not possible, those who were out of the loop are filled in with the necessary details to be successful within their team. This does not happen by accident, but instead by intention.

The choice between working with remote vs. in-house developers is not a business decision that makes or breaks a company. Though it does seem to be a question many ask, should we consider hiring remote developers? I would say that is not the right question at all. Business decisions that impact how well people succeed at working together or how quickly they fail at working together are comprised of a wider set of choices regarding how the business interfaces with it’s workforce. What do we gain from learning how to communicate and ship features for our product while working as a distributed team? That, is a much better question to ask.

Once a team embraces a distributed workforce, fully or partially remote with some or none on-site, there are valuable lessons to learn. Communication is important, it takes as least two. Foster communication and open collaboration; succeed and fail openly. Asynchronous communication is the way to encourage collaboration. Interruption is not. There is a time and place for synchronous communications; but that should be limited to when it’s altogether necessary and agreed upon by all parties. A good VOIP phone; or a plain old cell phone with a good service plan works fine. Slack has a decent call feature. Not every meeting needs to include video (or face-to-face) interactions. Just make sure you keep communication open and timely. Choose your tools for process and collaboration wisely; the tools should not be the subject of your pain points. For online meetings have a backup plan, perhaps the primary tool will be an online meeting and the backup may be a conference (call-in) phone number. Decide this in advance of the meeting start time. Chat apps work great; and help teams connect and collaborate. Reach out for help; pair program with team members. When working remotely, avoid isolation. Explore the surrounding areas, or travel. Rent a shared work space as needed. Keep yourself motivated. When working from home, be careful to plan your work hours and plan your life away from work too. Choose and communicate working hours. Draw a boundary for yourself between life and work. Be an effective communicator and set reasonable expectations. Avoid distractions, find a time management system that works for you, perhaps use the Pomodoro Technique®. Focus and flow facilitate great work, protect that. Show up and dress for work, wherever that is. Choosing where to work affords who has the privilege of inturruption. Working at home can mean that loved ones are close by; don’t shut them out, agree on a time to connect. And give them some hugs too.

One final suggestion is… know your limits. Sometimes an experiment fails, find a way to make lemonade from the pile of lemons you were sold. If working as a remote employee isn’t working, try contracting. If working as a fully distributed team is going bonkers, rent an office space and move toward flexible hours. Learn not only from your own mistakes but also from the mistakes of others. Perhaps hire contractors instead of employees when you decide to expand your team beyond the walls of your office. A consultant, worth her/his rate, will make the team they work with shine; by transferring her/his knowledge and experience as each opportunity presents itself. If you fail – don’t give up, try something new.