3 Comments

Summary:

Remote work may yet become the default mode of doing business for many, but we aren’t there yet. You may be feeling pressure from employees to allow remote working, but it’s best to go with a trial run before putting real money on the line.

remoteworkers

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.

BYOT

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.

Document Everything

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.

You’re subscribed! If you like, you can update your settings

Related research

Subscriber Content

Subscriber content comes from Gigaom Research, bridging the gap between breaking news and long-tail research. Visit any of our reports to learn more and subscribe.

You're subscribed! If you like, you can update your settings

Related stories

  1. The suggestion to avoid company-mandated tools is a really good one. As David Bland wrote in a recent article, tools can sometimes pose a significant barrier to the “gelling” of a distributed team.

  2. Deborah Fike Monday, March 21, 2011

    I agree with avdi that letting remote workers choose their own tools can help prove the concept out. I would also propose doing a “before and after” study with major stakeholders. Outline objectives and then show concrete results that got accomplished. A lot of time, top management doesn’t get to see what can be accomplished with these types of work environments, so proving that it can work right after a trial can help change minds throughout the organization.

  3. Purnima Padmanabhan Monday, March 21, 2011

    I agree that remote wok is becoming increasing popular. One of the key piece of the puzzle for remote work is to enable use of personal machines for accessing corporate information (a specialized form of BYOT called BYOC – Bring your own computer). Organizations can deliver BYOC today by creating a secure corporate virtual desktop and deliver it to an employee’s device, isolating the work are from employees’ personal applications and data. This model gives employees mobility and flexibility without liability and enables them to work securely anywhere, anytime. Some considerations for BYOC are outlined in the article: How to Safely Implement BYOC Programs – http://www.eweek.com/c/a/Virtualization/How-to-Safely-Implement-Bring-Your-Own-Computer-Programs/

    – Purnima Padmanabhan, VP of Products at MokaFive

Comments have been disabled for this post