I'm not going to repost my long list of research on co-located vs remote work again right now - but for those who are interested go see http://news.ycombinator.com/item?id=5145358
And I would love to see pointers to research rather than anecdote on how remote teams are better than co-located ones in a team room (all other things being equal).
All other things are not necessarily equal, even if co-located teams did perform better people with the required skills might not be willing to relocate.
All of my startup experience has told me using seasons for launch dates is a bad idea regardless of practicality. Especially when you're a proven startup with something to lose.
Half of my team works remotely, but one of the problems we have been struggling with is - how do you mentor junior programmers?
It is not about technology or programming language, but some of the words that a person with > 7 years experience uses can throw off a new programmer. And people ask less questions when working remotely.
I work remotely, but I also work from an office. I simply rented an apartment close to home.
Personally I can't work from home because I need to make a strict separation to keep my sanity and I'm also the father of a 3-year old boy whom I can't disappoint every time he asks me to play with him.
Working remotely doesn't mean working from home. It depends on your preferences, but if you've got several people working remotely at a company, at least one senior is going to be working from a place where he could invite others to join him (like his own office, or a coffee shop, or something).
So how we do it right now: if the junior is from my country, I invite him to work with me for 2-3 months, to bring him up to speed. After that he can do whatever he wants.
Take this with a grain of salt though, as we are a small company and I don't really have much experience on this.
I've mentored junior programmers (e.g, some of my guys/coworkers are still in school studying Comp Sci despite my attempts to get them to drop out), and it doesn't have to be done in person. As long as there is good motivation and discipline and trust remote working can work perfectly well over Skype. Code reviews done through Skype will be incredibly resourceful.
However, if there is lack of trust or discipline, this will not work. But then again, if you are having this problem you should really reconsider whom you hire! I hire my guys as interns, and I can quickly figure out who I want and who I'll wish the best of luck after the internship is over (my internships are just really long interviews): the ones who can figure things out themselves, the ones who go through an issue tracker and look for new things to do, the ones who will constantly ask things on Skype. You can't mentor self-sufficiency!
Bottom line: the people you want to hire aren't going to be needing constant babysitting. Those people will do it themselves.
Everyone is much happier because people work where they want to work. We still have 1 day a week where we all meet up in person (granted, that's still optional, but everyone shows up for camaraderie, and I bribe them with lunch). I work from many places, on my own time--and so does everyone else. As long as their output is roughly meeting the mean productivity of everyone else, it will work.
Here's another thought: when you bring someone on board, get them to work on a fun project. For example, I have my guys build apps with Twilio that book tables at OpenTable automatically using mechanize. Some fun apps will get them to learn a framework and language very quickly.
When I was younger, I was mentored almost exclusively by the very knowledgeable people on Freenode IRC. It's not only possible, but it's much better to do this remotely.
I've found that when people receive criticism remotely, it tends to escalate into "I feel this way because I read this: <insert link here>". Then a debate proceeds about the merits of one approach or another. When people receive criticism IRL, it's much more common to be defensive, because the references are not immediately available and there's a desire to resolve the disparity immediately.
I google everything (at least, when I'm outside of the office), and if I have two minutes to google anything before responding, the quality of my discourse will always be higher.
I used to be in the office all the time. What ended up happening was that I ended up becoming a tutor and they weren't gaining the skills of an experienced programmer. The best thing you can do is force them to look up things. It's probably even a good idea that all questions go through Skype or email because you can answer them on your own schedule; meanwhile, you force them to work for the answers.
For example, I had to teach a fresh Comp Sci kid how to link to a C library several times. He had no idea how compilers or linkers worked aside from his school programming assignments. I taught him how to do this in VS and GCC Makefiles at least 3 times, and he still didn't learn it because he could turn around and ask me. I've learned you only force someone to learn when you don't provide them answers. You do yourself and that person a disservice by spoon feeding solutions.
I've done remote pairing with juniors. I did it with with Skype. These days I'd probably use Google hangouts.
We were both using the old SubEthaEdit app that allowed two folk to simultaneously edit the same code. It's not something I've looked at recently so am not sure what the current equivalent of something like that would be.
Worked pretty well, but wasn't as effective as my experiences of pairing with juniors in meatspace (the loss of body language added a significant communication barrier).
Not quite the same, but I (still a junior programmer) have worked on a project with another junior programmer with a complimentary skill set. We've found great success in using a Google Hangout while we work. We can quickly share our screen to pair program and debug, and continue to chat/share ideas in an adhoc fashion.
The problem I still can't seem to adequately solve is remote teams working entirely in sync with local teams.
For example, I need to hire an additional 2-4 JavaScript or PHP developers, but most of our team is in Houston, TX, which is not really a hot spot for these.
I already have some remote workers, but their projects tend to live more in isolation until the PR needs to be discussed, while the local team constantly works together, on their own accord, through the whole process.
How can this gap be bridged where remote and local can cohesively share the same projects without the "latency?"
I've been working remotely from about 90mi outside of Austin (for folks in Austin, doing front-end work on top of PHP).
By being generally fast with email and generally quick/responsive I've gotten a lot of freelance work, so maybe it's just a general skills issue; it's not easy communicating certain things in email/phone/text/message and developing that as a skill takes a lot of work... it's totally subjective, but it feels that it's taken as much effort to learn when to reply to an email and when to sit on it for a half hour as it took when I first learned how to use jQuery.
IMO, this skill is made tougher to practice when the people I deal with are not also skilled at communicating; there is a lot of communication that I get remotely that takes a bit more decoding because whoever wrote it doesn't put a lot of thought into the communication.
I dunno what the good answer is; just saying "hire more experienced remote workers" sounds like a dumb answer...
No, that sounds a lot like exactly the right answer.
To promote remote working we need developers that can help and teach a company to handle remote work. Not people who will just whine about how companies suck because they don't offer remote work.
Remote working is a skill, on both sides. Most companies that would theoretically not be averse to remote workers don't have that skill and can't properly evaluate that skill in others, so the only alternative to a long period of trial and error is to hire developers with a proven track record.
Either that or wait for 37signal's book to come out...
It sounds like your process isn't handling them well, or you just aren't making them a real part of your team.
At my company, we have half our staff in Melbourne, Australia... and half spread out globally around many different time zones.
The remote workers are every bit a part of the team as the Melbourne workers.
I think adopting a more asynchronous workflow makes sense, both to include remote workers but also it can be very efficient (remove distractions).
A tool like Campfire to handle communication is really important too, anyone can log in and see what they missed and you don't need to be there at the same time to have a conversation.
Also, you need to trust them and give a lot of autonomy, it can't be managed in a traditional way.
I think the autonomy is where the problem likely stems from. Everyone handles their own tasks however they see fit, which leads to collaboration in the local office because of the ease in doing so.
Perhaps centralizing all communication in Campfire (or one of the recent "Show HN" posts) rather than our daily Skype call would help alleviate that...
I'd love to see this book achieve a wide reading, and by that I mean outside of the startup bubble. It's frustrating to see how averse some companies are to even the idea of remote work, let alone the reality of it. Anyway, I'll definitely be picking this one up when they release it.
I know this is techstartuplandia but I'll be pretty interested in this book because it probably has some interesting nuggets of wisdom for OpenSource projects and the like :)
I'll also be interested in application to the world of academia because I think working remotely could be more efficient in a lot of cases there as well. Granted there's office hours and lecture dates but I tend to pre-research better at home (very informal gut observation)
Edit:
Hope this is not going to be marketing for Campfire in disguise. But given the 37s background I don't think so.
What's wrong with testing the waters? I wish all writers would do the same. Writing a book is a huge undertaking and any insights you could gain beforehand are welcome.
That would be such a tight schedule...surely they would have something in draft form at least. If this was someone's fulltime job, maybe I could see it, but really there's no reason for them to "test the waters". That was done with their blog, and also HN where you see the topic come up quite often with lots of discussion.
37signals has 36 employees, less than ten of them is likely to be in the office at any one day. Working remotely is not an all or nothing proposition. You can have some people in an office, others remotely. But of course you knew that and was just trolling, so don't let me disturb you.
Without further explanation this is not relevant. There is no contradiction in simultaneously believing that it is worth it to provide one's in-office workers the best office money can buy and that to find enough excellent talent, one should accept that not all employees will live within easy commuting distance of the office.
Offices are not required, but are still useful for certain things which demand a physical location somewhere. Have or work at an awesome company with an awesome office as a home base but still be able to be nomadic or just live and work elsewhere for most of the time? That's awesome.
And I would love to see pointers to research rather than anecdote on how remote teams are better than co-located ones in a team room (all other things being equal).