Skip to content

Remote Developers

Dear Reader,

This conversation takes place via email at least once a week for me

Headhunter: “I am looking for the best PHP programmer available. Do you know anyone?”
Me: “Yes, I know someone right now who is looking around and is awesome; however, they are not looking to relocate. Are you willing to consider a remote worker?”
Headhunter: “no.”
Me: “Sorry, your loss.”


If you are truly looking for the best PHP developers out there and you won’t consider a remote worker, you aren’t serious about finding the best; you simply want the most convenient.

Even in this economy, the best already have a job. More than just a job however, they have a lifestyle and expectations that wherever they work, they will maintain that lifestyle. They enjoy their work/life balance and they are not interested in uprooting their family. If you want to attract these people, you have to be willing to understand that desire and cater to it. This is the world we live in. Nobody wants to spend an hour or more a day commuting when they could just as easily spend that time with their family. They want to enjoy their family but they also want to build your application; developers actually want to practice their craft.

If you agree to this arrangement though, what do you get in return? You get a productive developer. Isn’t that really what you were looking for in the first place? Someone who can get in there and get the job done; a motivated programmer who can hit the ground running and build the application you or your upper management want.

Here is a checklist to help you. When you can check off all of these items, you are ready to manage remote teams.

  • Lead by working from a remote location at least once a week.
  • Research the remote working tools you want your developers to use and made sure that everyone has them or has access to them.
  • Champion remote working for your developers to upper management, even when they are tired of hearing about it.
  • Prepare a report for upper management once a quarter that details fiscal saving on office space, utilities, etc vs. the connectivity allowance you give each remote worker.

For those developers that enjoy the lifestyle, remote developers are happy developers. Yes, they require some extra attention on your part but happy developers make for productive teams. Isn’t your job as a manager to squeeze all of the productivity out of your team that you can? Then what are you waiting for? Kick them out of the office!

Until Next Time,
(l)(k)(bunny)
=C=

18 thoughts on “Remote Developers

  1. Just because you want someone in the office, doesn’t mean you are looking for the most convenient.

    Not being there with the team causes you to miss out on information that passes around almost subliminally, and can impact your overall effectiveness as part of the team.

    Yes, using tools like IRC can help with remote workers, but you can’t expect to have someone in the offices transcribe everything that occurs; you are by definition losing out on information flow.

    I’m not anti remote worker, I think that it makes sense for the right person in the right role and not everyone is capable of flourishing as a remote worker.

    Just my 2 cents.

  2. possibly even more important than when hiring is that when you employ such developers, you don’t single-sidedly change the agreement and require people to be in-office more than what was initially agreed upon. This is also important to keep in mind when hiring remote developers: don’t expect to hire someone to work remotely for a while and then work in-office or on-site more at a later point during the employment. Especially when this was not explicitly discussed before said employment.

  3. Hi @wez!

    I do not disagree with you, remote working is not for everyone, I would even go so far as to say it’s not for everyone who desires it. It takes a certain kind of individual to be able to flourish as a remote worker. However the problem I’ve run into more than a develoepr can’t handle it is that management won’t consider it. That’s the attitude I’m trying to adjust with this post.

    All of that having been said, if a team is a mixed team then no, I don’t expect someone to transcribe the things that go on in the office, I expect the manager to keep them from happening as much as possible.

    By way of example, when I was the Dir. of IT at ENA, we had 7 developers in the office and one remote developer in Va. Beach. Staff meetings were either held via IRC or via conference call with each person usually remaining at their desk. The irc chat room WAS the water cooler and I encouraged all discussion to take place there and not hanging around. I also discouraged drive-by meetings as they are both time wasters and usually excluded not only the remote developer from any decisions but anyone else that did not happen to be there.

    There will always be human interaction, within the office that can’t take place on-line and yes, the remote developer will miss out on some things. In my “Manager’s Guide to Telecommuting” talk though I stress that it is the managers job to keep as much of the team interaction as possible in channels open to all.

    The payoff is, as I’ve stated, the ability to hire the best of the best. Granted, that’s not a real problem for OmniTI or (I assume) Message Systems, however, you are the exception, not the rule. :)

    Thanks so much for the comment,
    =C=

  4. Ok,

    2 counter arguments that I would like your view on.

    1. Is it reversible? In other words when you say “if you’re not willing to employ remotely you’re not looking for the best”, can I say “if you are not willing to move, you are not looking for the best job?” The truth is probably somewhere in the middle, so I don’t agree to the adagio that remote work should always work and that companies should always consider it.

    2. Agile is increasingly popular as a development methodology, yet Agile states that developers should be in the same room as much as possible. Nothing beats the productivity Flow of developers that are in the same office working together closely on something great. There’s no communication tool that can replace that.

    I’d say that while in *most* situations remote workers are perfectly acceptible and, depending on the skills of the developer, will usually work, there are situations in which it wouldn’t, and in that case it’s better to consider a developer that is able to work on site over a remote developer that can’t.

    I’ve experienced both situations in the past. On the one hand, I’ve had perfectly capable developers fail as a remote worker because they lacked the discipline and self organization to work by themselves, and also I’ve seen mediocre developers grow into solid senior developers just by being close to other developers. On the other hand, I know a few of our remote developers that simply work even better when they are on their own and can work from their own comfortzone, and have perfect communication via remote communication tools.

    So I guess it’s not black or white. It’s grey, and that’s something that both employers and employees will figure out for themselves.

  5. I think that agile with remote teams can work fine – Jeff Sutherland seems to think so, but it seems you have to be even stricter with making sure you’re implementing Scrum or whatever system properly. I think the problem comes when you half-ass it. Rands had a good post a while back about people being ‘out of the pond’, and that’s the situation that it’s worst with. As long as the team and project was designed with remote workers in mind, I would expect there to be 0 difference in effectiveness. If it wasn’t, working remotely will be frustrating and less effective for everyone. Of course personal preference will come into it, but note the distinction can actually be multiple ways remote/on the road/on client site/in company offices, each combination of which needs slightly differently handling.

    As to Ivo’s first point – there are always more good jobs for the best people than there are best people for the good jobs, so in the end it’s the company that needs to do more when hiring. The value between a really good and a great job might be a bit for the employee (clients are a bit cooler, offices a bit nicer, whatever), but the difference between a really good and great employee can mean a fundamental improvement to how the company does things.

  6. In response to Ivo’s 2nd comment/question…we are seeing, as an outgrowth of remote working, a growth of community working…groups of developers working for different companies on different projects under different technologies getting together and working in a common space. This provides, in my opinion, richer opportunities for collaboration for the worker…and higher benefit for the company…as the company now as access to the collected knowledge represented in the group and exposure to new ideas, methodologies and intelligence.

    Remote workers don’t always sit in their basement or home office…more often they can be found in coffee shops and other public places…collaborating with people they would not have access to sitting in an office.

  7. Setting any recruiting criteria should always depend on the nature of the projects and the need of the employer. I think it’s secondary whether the worker can/want to work remotely.

    On the other hand employers often do not have a good reason for wanting a full on-site worker. Many projects work just fine with a on-site team kick-off week and the remaining time done remotely. It’s always a lot harder if time difference is a bigger than 4 hours.

    Information shared in the war room is priceless and a collocated team is always my first setting choice. But real world projects are all but ideal and often we have to be flexible to the second best choice to ensure the resources we need. If a candidate sticks her foot on the ground based on her life style and is not willing to work out a solution that works in the best interest of the company, just generally, I would think twice before hiring her.

  8. Some people /can’t/ relocate, for whatever reason. They might even want to, but it’s just not an option. I’m in this boat right now so I love this post.

    I’ve also found that in certain contexts, remote work is a requirement if you want to get anything done. At the moment I work as a hybrid IT-guy/developer. I simply can’t write code when I’m on site. It doesn’t happen.

    Management recently shuffled around and my new supervisor insisted that I start working primarily from home so that I could actually get some code written. It’s been excellent.

    Not to say that there aren’t challenges and it’s not for everyone, etc. But it’s been a big plus for me, on balance.

  9. Here are my opinions as an employer.

    I have helped to found three companies.

    At the first we allowed developers to work from home on short-term projects (5-10 days) where the tooling and the nature of the work was appropriate. This worked well.

    At the second company we all worked entirely remotely and had scheduled coordination meetings. I was a big proponent of remote working at the time. After doing this for several years my opinion was that the amount of miss-communication and miss-alignment caused by prolonged remoteness was counter-productive in the long term.

    At the third company we returned to having most developers working on-site most of the time. We also have several developers who work remotely full-time. Predictably the amount of miss-communication, wasted efforts, and frustration is significantly higher with the remote engineers than with the on-site ones.

    I agree that a really talented, self-motivated, and productive engineer can be a good hire where-ever they are – but this will be despite their remote location, not because of it. In addition given the choice between two engineers with similar skills I will take the local one over the remote one every time.

  10. I applaud your efforts to make it sound like remote developers enjoy their lifestyle because it affords them more time to spend with their families. But lets face it, it really just affords us more time to play XBox. :)

  11. Totally agree! I work for a company that frowns upon us working remotely even though we are over 50% more productive working remotely. It’s mostly non-techies managers who want to pick your brain all day in the office and cater to their every whim because their too lazy to type or pick up the phone. I wish I could find a job where they would let me work at home but it seems as though companies don’t trust you to get the work done. Makes no sense to me

  12. I work from home and now find I do more work than when I commuted. Like a lot of developers I need to ‘warm up’ in the morning. This means I don’t get going until mid-morning but then I work until 7 – 8pm and sometimes into the evening if I’m ‘in the zone’. I get to see my kids in the morning and put them to bed at night yet I do MORE work.

    As for working with my clients, I use tools like Skype, Acrobat Connect, Basecamp etc to maintain a very professional relationship.

    Also, I always get dressed for work in the morning and I make sure I have a clean, quiet office at home.

    The only downside is that I go a bit stir-crazy sometimes and have to go out at night on murderous violent rampages.

    That bit was a joke.

  13. @Ivo – I’ve worked in a distributed AGILE team and it worked. We’ve had scrum and planning meetings through internet teleconferencing…

    @cal – What about those that accept telecommuting BUT want you 100% ?
    Those that cannot accept that you might have a small business of your own ?

    Where do you think those fit in ?

  14. @radical

    I think we are confusing terms here. When I say Remote Worker, I still mean full-time employee, whatever that term may mean in your region. I’m ok with the company wanting 100% of my normal work hours.

    Thanks for the comment.
    =C=

  15. Pingback: Remote development – Happier staff | PHP and MySQL Development

Comments are closed.