Should companies consider remote employees or stick to local employees? [closed]

Question

Elite developers can be 10x more productive than an average developer.

Clearly it's easier to find an elite developer around the whole world than in a company's backyard.

If a company is not located in a programming hot spot, should they consider hiring people who work from home?

Answer 1

I have worked as, and managed staff in both situations, and combinations of both. I've made the following observations:

• Junior staff do not work remotely. They require a good and personal working relationship with a mentor. I find my junior staff would rather wait for me to be available than to ask the rather senior (and good) remote developer anything.

• Ensure anyone you consider for working remotely is effective when self-guided and doesn't go off on tangents.

• Remote staff can get isolated really easily and not feel part of a team unless special effort is made to be inclusive of them. This isolation can lead to a misunderstanding of the specific business driver for a project, or to misinterpret events in a negative manner.

• Never get a contractor working remotely, unless they have the right incentive to perform.

• When working with a remote team member, make sure they get equitable access to resources, including source control, reference material, etc. Don't make them jump through hoops to get work done.

• Arrange those face to face meetings as often as practical. This encourages far better team collaboration as people are more comfortable with those they have met.

Answer 2

Maybe.

Your benefits are:

• Access to a wider pool of candidates (as you point out)
• Access to people who want to work at home

Your costs are:

• More difficult communication- you can't just pull someone into a free conference room.
• No guarantee of instant communication- if you're blocked and waiting for Joe Remote, you can't just go over to his desk and ask him what's up. If he's incommunicado, you're SOL.
• Not all developers work well remotely. Some need the structured environment to be productive.
• There's often no guarantee of matching schedules- eg, a work-from-home person might sleep in, or a person in another time-zone might be awake and working at different times than you.

Atwood had a decent article about it.

Edit, from Atwood's article:

The minimum remote team size is two. Always have a buddy, even if your buddy is on another continent halfway across the world.

Only grizzled veterans who absolutely love to code need apply for remote development positions. Mentoring of newbies or casual programmers simply doesn't work at all remotely.

To be effective, remote teams need full autonomy and a leader (PM, if you will) who has a strong vision and the power to fully execute on that vision.

Answer 3

Companies that don't know what they're doing should not have remote employees. The most incompetent manager will only feel like you are working hard if they can actually see you sitting at your computer doing a lot of typing. Also, sitting in useless meetings is one of the best indicators of strong communication and time managment.

When you have people who know what they are doing and are managed by those who know what they're doing, it really doesn't matter when, where, or how they work. They get what's needed done when it needs to be done.

I'm at a company that pays someone to do a direct deposit for payroll AND print out a faux paper check (actual pre-printed check paper), puts it in an envelope and sticks it in our mailboxes. I guess internal email is not secure enough and what would we do with all those checks?. I believe this edict came from the Department of Redundancy Department. If anyone were to work remotely, there would be the extra cost of postage which is a good reason not to let people work remotely - too expensive.

Answer 4

It's okay to have remote people if two things are true:

1. The people are senior enough and have a track record that means that you trust them to get things done without much supervision and to be proactive about asking for help or letting you know if they are stuck.
2. The "pulse" of your project is short enough (preferably daily) so that any problems with the arrangement will be identified quickly. I don't just mean someone saying they've done something in a status report or checking an item off a task list, but actual, demonstrable progress with a feature. There are of course lots of ways to do this, but the main trick is to split tasks into small enough chunks that can be done in a day or less, and validate that these tasks are being completed.

Answer 5

There are awesome technologies today that make it easy to act as a team without being seated close to each other.

IRC, Jabber or similar chat-type software makes it really easy to keep everyone in the team aware of each other, what they're doing, and feeling free to discuss issues immediately. I use IRC with freenode's groups often and it's like having one big group of developers at hand, acting like a giant collective brain. Apple's got a nice chat client build into Mac OS that also supports video conferencing, especially effective with their laptops.

Imagine how it would be if the company had their own internal chat server, with groups for departments, projects, and work-related interest groups. A developer could ask a question where it would be seen across the company, so another developer anywhere else could see it and answer. The office walls disappear, communication skyrockets and best-practices and code sharing can happen all on their own without someone wielding a big stick.

One of our load-test engineers works remotely about 1/3 of the year, sometimes from his home which is about 30 miles from our office, other times from out of state. He is as effective in the office as he is outside it because he keeps his chat software running, and calls in for our conference calls.

My coworkers on my team sit down the hall so I can't see or hear them. I don't know when they are in their cubes so I send them a chat message, and they respond as soon as possible. I do team programming with one of our engineers at another site. The same thing occurs; We ping each other regularly with questions and/or inane thoughts, and if we need to pick up the pace we'll share a screen and get on the phone. I can't tell if he's in the office or at home, and it doesn't matter. We work the same either way.

Our QA department is split between two different cities in different states, our engineers are spread across our city at about four different locations, but it's difficult to tell because we use our phones and chat regularly. We're all working remotely from each other in reality, so what's the difference? The difference is the corporate mindset.

There are a lot of big advantages to working remotely, and mostly it takes a change in mindset for the employer to try and find out that employees respond positively to it.

Answer 6

I think it also depends on what you want them to do.

If they're contributing to the architecture and overall design of the software, then it could be a problem.

If they're receiving detailed specs and churning out methods, then not so much.

Edit: To clarify, I'm trying to say that if the work can be isolated, then it's fine to give to a remote employee. If, however, it needs detailed discussion and architectural design meetings, then that's very hard to do from different countries.