Receive daily articles & headlines each day in your inbox with your free ERE Daily Subscription.

Not logged in. [log in or register]

Remote Control: How to Attract Technical Talent With a Work-From-Anywhere Policy

by Sep 24, 2013, 6:19 am ET

For technical recruiters, the hardest part of the job is often maintaining a full pipeline of quality candidates. We’ve all heard the advice: Use the power of referrals, be considerate when messaging passive candidates, and seek out developers among online and offline community groups. But in a market where the largest tech companies need to fill more than 2,000 developer positions a year, it takes more than active outreach to meet your annual recruitment goals.

457411If you’re stretching to fill dozens of openings, it may be time to adapt your strategy so that you attract candidates just as much as you reach out to them. There are lots of ways to do this when recruiting — show developers that your company provides the things they care about the most at work, make your job ads less about what you need and more about what they get, and make them feel part of your team from Day 1 of the application process. But a really effective way to get more interest quickly is to offer remote work opportunities. This doesn’t mean letting your developers work from home for a few days a week or outsourcing your entire team to Southeast Asia. It just means letting them live wherever they want and work from there every day.

Let’s get this out of the way: Remote work may have gotten a bad rap at certain companies, but most developers don’t look at it as an excuse to be lazy. At Stack Exchange, we’ve stressed remote work as important from Day 1, and as our VP of Engineering David Fullerton has pointed out, it remains essential to our culture today.

We’ve found that most of our remote developers actually work longer hours than our in-office team because it’s easier for them to get in a groove, stay focused, and they don’t need to leave the house to do their job. This level of interest is even more pronounced by taking a look at the performance of our job board: Listings that offer remote work receive an average of 3-6 times as many applicants as jobs that don’t. In other words, if you don’t offer this option, you may lose out on good developers who can’t make a physical move for your company. You may also risk losing current employees when their personal situations require them to move.

It might be easier to initiate a work-from-home policy at a smaller company, or even at a newer company. But in an environment where less than 3 percent of developers are unemployed, it’s a shift that many even larger organizations may need to consider to sustain growth among their R&D teams.

If you’re a larger organization without any remote infrastructure in place, open it up to remote work with baby steps. Based on all that we’ve learned, here are six action items that any organization can take to move toward a remote workforce and ultimately maximize your hiring strategy to attract more top talent.

  1.  Start with a small team. Remote work isn’t for everyone, and it won’t always fit perfectly within the typical 9-5 workday, especially when time zone differences come into play. Because of these challenges, introduce remote work with a small team. Look for a subset of 5-10 developers who already work on a more independent project, meaning that their in-person absence wouldn’t drastically impact as many other departments. And don’t send everyone off into the trenches at once — start with a couple of work-from-home days each week so the team still has a chance to hash things out in person while they get used to the shift.
  2. Hire a technical manager who’s familiar with remote working teams. As with any new initiative, you’ll need a leader to step up and own the processes and establish precedents for everyone on the remote team. This individual will be responsible for managing each member and ensure that everyone receives enough communication and context to do their jobs. Keep in mind that “working remotely” doesn’t mean “being antisocial.” You’ll need to actively make everyone feel not only part of the team, but also part of the company as a whole. And just like in an office setting, you’ll soon recognize that certain people respond better to different communication styles — so whether it’s email, video chats, or phone calls, work with every developer in the way they prefer.
  3. Redefine your hiring criteria. When building your remote team, vet candidates based on whether or not they would be successful in that type of role. At Stack Exchange, we look for developers who are self-motivated and would be proactive in communicating with the rest of the team. They can’t be shy about reaching out to their colleagues. It’s easy to let a developer drift away or become “forgotten” when you no longer bump into them in the halls. As a team, identify the characteristics that would make a remote employee successful at your organization, and build this into your hiring process.
  4. Make sure everyone works as if they are remote. This is the most important element of all: If one person on your team works remotely, then everyone needs to start communicating online. It’s the only way to keep everyone included in the decision-making process. Even a friendly water-cooler chat or business lunch is rife with opportunities to inadvertently leave somebody out of the loop. Initially, it may feel strange to use online video conferencing with people who are sitting across the hall, but at the end of the day, these communication tactics create an all-inclusive environment where everyone’s opinion still matters.
  5. Define a common set of tools for the team to use. For the best collaboration and communication, get your whole team using the same set of tools. Although the exact processes and programs that work for one company won’t necessarily work for you, look for certain features when assembling your remote toolkits. For starters, adopt a program that like Google Hangouts or Skype for video conferencing; it’s the closest you’ll get to in-person face time. It’s also helpful to set up an online project management system — we use tools like Trello and Google Docs — to keep track of who’s doing what. We also suggest investing in a persistent chat system like Campfire or HipChat, which lets you keep a running stream of conversations that everyone can be a part of at once. Finally, you’ll need to identify a technology policy for remote workers that details things like the type of computer, speakers, video camera, or other devices they may need for an ideal setup.
  6. Integrate your remote policy with HR compliance regulations. Once you’ve developed a remote work policy that works for your company, you’ll need to ensure that it meets all of the standard compliance rules. Take into account the geographic location of a new remote worker so their salary remains competitive, regardless of whether they are in New York City or Boise, Idaho. If possible, select a benefit provider that has a wide network so even hires in remote locations will have adequate coverage. (This will also help you protect your company so that remote people can’t claim discrimination for not getting equal benefits of treatment.) Finally, consider offering additional benefits to remote employees, such as Internet or cell phone reimbursement to make up for the fact that they may not receive all of the benefits as an in-office employee.

 

image from bigstock

This article is provided for informational purposes only and is not intended to offer specific legal advice. You should consult your legal counsel regarding any threatened or pending litigation.

  • Keith Halperin

    Thanks, Bethany. Very sensible and practical. Why just have developers remote, though? There are large numbers of tasks that many non-developers do that can be done remotely, too. I think that it would make sense to analyze the work that needs to be done as to whether it can be done better remotely or F2F-there are some tasks which can’t be done effectively remotely, even with advanced tele-presence. I think we should start reversing expectations- there needs to be justification about why and when work needs to be done F2F, and the expectation is that if the work doesn’t involve direct customer contact or hands on manipulation of objects, then it can be done remotely. Besides the time and transportation savings, there’s another big advantage of having (largely) remote employees- if you don’t have them right next to you 40+ hrs week, the cultural fit is less important. While I concede that there are times when F2F collaboration is a plus, I really don’t think there’s evidence that it’s needed 40+ hrs/week. I think one of the main reasons there’s been reluctance to do this is that it’s hard for a manger to look bug and powerful in the eyes of her/his peers and superiors with a work force that can’t immediately be seen.

    Cheers,

    Keith “Has a Quick and Easy Commute” Halperin

  • Caroline Watson

    Absolutely Keith. It’s got to be THE model for future working. I experienced this whilst heading up a small team remote from central Head Office project support, and increasingly can see the benefits, from a cost perspective. Point 4 about communicating is critical. The remote team builds its own cultural values to a certain extent but I don’t see this as an issue. The issue is in your final sentence – how the traditional workplace seniors translate their roles and status.

  • Keith Halperin

    Thanks, Caroline. Perhaps that could be another belief that could be reversed:
    Instead of a manager with large numbers of F2F employees being powerful, s/he could be thought of as rather old-fashioned, technophobic, and insecure.

    Cheers,

    Keith