Stay on Top of Enterprise Technology Trends
Get updates impacting your industry from our GigaOm Research Community
Remote work may yet become the default mode of doing business for many, but we aren’t there yet, which is why it’s understandable if businesses are unwilling to embrace the model sight unseen. You may be feeling pressure from employees to give remote working a try, but as with any major business decision, it’s always best to go with a trial run before you put real money on the line.
Start Small and Occasional
Keep your distributed team small and not entirely off-site when you’re first trying out remote working. Choose a pool of employees that you know can handle extra work, and won’t have a problem with working extra to make up for lost time in case you find a distributed work environment runs counter to your company’s culture or the nature of your work.
Don’t necessarily create your team using only employees who’ve expressed interest in working remotely in the past, and don’t only choose teammates who have a proven history of working well together. Doing so might encourage a success for your trial, but it won’t reflect the real experience of a wider remote working program, which may or may not be exclusively volunteer-based or consist of individuals with a known ability to succeed when working together.
Mare sure remote work isn’t all your team does right away. Add a day or fund remote work during weekends or off-hours. This will ensure you don’t jeopardize your day-to-day business while employees get acclimatized to the new work situation.
Use a bring-your-own-tools (BYOT) model for equipping staff to work remotely; provide an equipment stipend and allow workers to choose their own equipment. This is a good idea for a number of reasons:
- Decreases learning time for new or unfamiliar tools.
- Decreases cost (in some cases).
- It seems to boost worker morale in companies where bring-your-own-smartphone and computer programs are already being tried. This might be because users aren’t struggling with devices they’re not comfortable using, or just because they feel like they have more control when they can pick their own equipment.
Use this policy for software, too, to an extent. Often workers will have a better idea of what software works in certain situations than IT departments or company management. Granted, there will be some software that has to be mandated by the company (although remember to stay platform-agnostic where possible) but for everything else, it’s better to allow team members to make their own choices, for the same reasons mentioned above.
Remember that this is an exploratory project, with the aim of determining whether adopting a wider program will be successful. To that end, make sure you and your test team document as much as is possible. That means keeping detailed records and producing reports.
Producing this documentation will obviously be a time-consuming process no matter what, but you can help streamline the actual work required by your trial team members by automating as much as of it as possible. Consider using time and activity loggers on work-specific hardware, and prepare easy-to-understand and complete reporting forms for commonly occurring events, like email interactions, use of collaborative software and IM conversations.
Begin and End
Lastly, remember that if you really want to gather useful data, you should have a firm beginning and ending date in mind for your remote work test project. You don’t necessarily have to share this with team members (they may behave differently if the project has a set time period) but you should avoid the temptation to let it continue on as a permanent fixture without a break. Even if it’s working, an end date will provide the opportunity to step back, take a look at what happened, and accurately reflect on why it succeeded so that you can replicate that success with other distributed teams going forward.