Years ago my boss asked if I could use a remote support developer in Europe for off-hours support of a critical system that processed data throughout the day. He said that they had a sharp technical resource there who had normal working hours right in our support blind spot and that the candidate was interested in helping out. I froze as the downsides flooded my mind:
- He didn’t know our system at all.
- I would never meet him.
- We didn’t have much documentation of our systems. All our knowledge transfer was done in person using heavy sarcasm and obscure hand waving.
- We didn’t have a good ticket tracking system or history of service incidents we could point him at for self-study.
- I wasn’t sure how I could judge whether or not he was helping or hurting.
- I was afraid that instead of getting woken up in the middle of the night to solve a problem I would be woken up in the middle of the night to talk to him and explain the context because of the above problems.
All my objections were about how we weren’t ready to support him, monitor him, and grow him sitting where we sat as an immature support team. All my objections were things that we needed to change anyway and that he would serve as a canary and catalyst for these things to actually change. We would be a better team by moving towards being able to support him.
With the developer job market being what it is (i.e. a little nuts) some companies are offering work from home as an attractive add-on option – “Work from home Fridays”, “We support remote workers”, “Flexible schedule”. This is being done as an after-thought and is not part of the core culture.
The difference between a company that can support a remote worker and one that cannot is not a small difference in perks: it is a chromosome-level difference. Companies that truly support remote workers win against those that don’t.
Having now myself been the remote person on the other side over the last 2+ years I’ve found a large range of differences between those that truly support remote work and those that just talk about it. Think of it as the difference between a watch being water-resistant [you can wash your hands with it on] and diving-level waterproof [you can operate it underwater].
The reasoning is pretty simple: in order for a remote employee to succeed a company has to have clear communication, a standard process, and a clear focus on results above other secondary concerns.
A company has to provide the following:
- A pipeline of work that is ready to actually be worked upon (It is packaged with its context and links to how to find out information for any questions)
- Clear expectations for results and the ability to track how things are progressing.
- Clear communication channels: this might include some permanence and search-ability for work already done but also includes some form of ~democratic decision-making that includes those that includes more people than can fit in a conference room.
- A teaching culture that includes helpful coworkers ready to answer questions and help out remote workers if there are gaps of context.
- A Results-Only-Work-Environment (ROWE) culture that allows workers to get as much done as they are able, and processes feedback from those workers about obstacles they encounter.
All of those things are good for the company supporting remote work even without a remote workforce – they create less friction around communication and infrastructure and make results the top priority. In the end a company that focuses on primary complexity will beat those that are optimized for other things.