On Working Remotely

Analysis paralysis? You talk first about coding, then about analysis paralysis. That is not possible. When you program, you already have specifications. If not, then you make them. So you cannot have analysis paralysis while programming, because if you program, you have specs. If you don’t have specs, you don’t program.

Jeff, you may have inadvertently stumbled upon a big secret:

Everything you described there applies 100% directly to traditional offices too. Every. Single. Point.

“The minimum remote team size is two”

Nah. If you’ve got a decent work ethic, you can go it on your own. I’ve been working 2 development jobs from home for over 3 years now, both of which are on a development team of 1. Works just fine for me.

We’ve been doing this at Wildbit for almost 10 years. It’s been a lot of trial and error and the tools are much better now, but overall it always comes down to two things:

  1. Each person must be a natural contributor
  2. The team as a whole shares the same goals and are aligned.

It’s not any different from a team in an office, but the issues amplify and are harder to figure out. A problem team member might not become apparent until things start to get bad. I’ve become pretty good at reading emotions over IM in the past several years :slight_smile:

I wrote a post about this on Vitamin a while back:
http://carsonified.com/blog/business/building-and-managing-virtual-teams/

We tend to take retreats once or twice a year. It helps nail down strategy and just hang out and have fun as a team, something that really lacks from a virtual team. You can only mess around in Campfire so much. Usually after each retreat the team is on fire with productivity and ideas.

Really great post. It’s nice to see that more and more teams are thinking this way.

My mother has been working like this as a medical writer and editor back to the days when she had to mail floppy disks back and forth to people to move files around (we were the first ones with Internet in our area, for obvious reasons). She long ago told everyone she didn’t travel for work, or not without them dumping an obscene amount of money on her. My father worked with her as a typesetter, and also as an engineer, also from home. As a result, I grew up thinking that this was the normal way to work, and I still regard offices and hours are kind of odd.

I too think working from home is the future of all businesses that can be made to work remotely. Besides, the obvious features like being able to tap into talent, lack of office overhead etc. etc, there is a fundamental economic benefit if remote working became accepted more widely. By, shifting people away from major cities back to cheaper country or smaller cities areas, people can live a better quality of life without having to spend huge amounts on mortgages etc. It is a choice which people should have. I have explored this aspect of remote working in the following post, if people are interested:

http://technocures.blogspot.com/2009/08/how-to-use-space-time-continuum-to.html

Don’t you even dare saying anything about “really global” when your hiring statement for StackExchange contains the requirement “Permanent legal right to work in the US”.


Pavel Shved, 10k SO user.

Jeff, you said

Newbie programmers, or competent programmers who are phoning it in, are absolutely not going to have the moxie necessary to get things done remotely – at least, not without a pointy haired manager, or grumpy old team lead, breathing down their neck. Don’t even think about working remotely with anyone who doesn’t freakin’ bleed ones and zeros, and has a proven track record of getting things done.

(I added bolding.)

I think this is pretty scary advice to be giving, especially from your pulpit, which is not a small one. Have you tried remote development with newbie coders? Have you tried it with enough newbies to feel you’ve gotten a good sample? If you haven’t, then where do you get the experience to add so much emphasis to this point?

I haven’t seriously tried it either - in fact I’m a newbie coder at best (since my actual experience is more of the sysadmin kind). But I have a suspicion that I’d be at least an OK newbie coder to have on a remote dev team, as long as other sufficient motivations existed. Which is to say that I have dicked around with hobby things, and they tend to move forward in fits and jerks. But that’s because motivation is spotty, not because capability is lacking.

I could be wrong, but I suspect that with the right newbie coder, remote dev would work alright. I suspect what you are saying here is that you have the luxury of working with great coders and since you have it, you’re going to take advantage of it. And yup, if a person has that luxury, why would they voluntarily give it up? But to suggest that a person without that luxury should simply fold tents and give up is, I think, not such a good thing to do.

I’‘m just sayin’!

Can you hire me? I am very good :wink:

We (Sauce Labs) found out that Skype don’t scale well for meetings with a lot of people (that’s how we do the daily standup). We’ve switched to TeamSpeak and never looked back.

We do some of the pair programming using Skype and it’s screen sharing, works well.

I’m a developer based in New Zealand, and have been working remotely for a US based company for a few years now (Embarcadero Technologies, www.embarcadero.com). I would consider Skype to be our most valuable tool without a doubt. We have an ongoing team chat window always open, and make regular voice calls to combat the ASCII fatigue you mention.

I don’t know if you necessarily have to be the type of programmer that bleeds 1s and 0s to make this work, but you definitely need to be self-motivated, and know when to ask your team for help if you hit a stumbling block.

I’ve worked from my home in MI for Mozilla in CA for a little over 2 years now, and it’s been great.

The main things I’ve found useful are basically what you call out here: synchronous constant communication over many channels (eg. IM, IRC, VoIP, email to some degree); asynchronous comm with lots of recordkeeping and documentation; and a lot of self-motivation and initiative.

That last point is really the crucial thing for a newbie or a junior developer - some can do it, while some need lots of guidance and mentoring up front. If you have a history of getting things done without a lot of micromanagement, you might be ready for remote work.

If you don’t have such a history, you could be ready but it would take a lot of faith from an employer to rely on you. This is where things like writing a book or contributing to an OSS project in your free time can help prove your ability to work remotely.

Also, getting the team physically together about once a quarter is worth the travel for the value of the in-person touch-points. Try to make it a mini-conference, give lightning talks to each other and leave time for hallway conversations. Have a bar night or drive go-carts.

One more thing: I’d be curious to see how coders with World of Warcraft raiding experience would do. When you need to huddle around a project sprint occasionally, it can have a lot in common with a TeamSpeak / Ventrilo session to take down a boss. The main thing would be whether a WoW player could get away from the game and transfer the habits to billable work. I’m sure Joi Ito would have something to say about this. :slight_smile:

Unfortunately, it’s considerably harder for part of an existing F2F team to work remotely. Most difficult part is weaning off habit of having ad hoc discussions and making decisions in the hallway which leaves remote workers unaware and out of decision making process.

The best situation for working remotely is “everyone, from the start”, like StackOverflow. The next best is, of course, “Rambo vs. Red Army”.

I must be one those guys who hate meetings even more than you do. :slight_smile: One thing which I found very useful to keep a team of remote people (let say 10 members) in sync without regular meetings: create a dedicated channel on something like www.jaiku.com per team or per big chunk of work and ask each member of the team to post once/twice a day what #1) they were/are/will be working on and #2) how well/bad it is going and #3) how they feel about it. And forbid posts of anything not related to these “status updates”. I was really surprised how easy it was to adopt and how practical it is. For multiple teams I guess you do need some weekly reports which are not that fine grained.

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.

This is a good reason why sites that provide remote developers (oDesk etc.) don’t provide quality work. Most of the people I’ve tried are either newbies or casual programmers.

If remote development is the future there are a few issues:

  • Unfortunately putting together a team of veterans has a cost associated to it.
  • Good quality new developers often have clever or innovative ideas. If you are just code monkeys then this is fine, if you want ideas then you may be narrowing your options.
  • Where would new developers go to cut their teeth? Veterans were newbies at one point. Heaven forbid we send them to one of those remote only marketplace sites to learn how to write decent code.

Thanks for another great article.

Doesn’t this fly directly in the face of Joel’s repeated statements that the SO/SE team being build from the VC funding will be in NYC only (other that don’t-call-us-we’ll-call-you)?

I do agree though - I’ve worked semi-remotely and as part of a distributed team and it really is difficult to maintain the discipline. One thing that makes it harder is if you have a co-located group and then other people spread around the place - the co-located group naturally forgets to include the others. When everyone’s distributed I imagine that’s less of a problem.

Ben,

I was thinking about that the WHOLE time I reading this article. Joel posted that they need to hire people but they absolutely, without a friggin’ doubt have to be in NYC and (presumably) work at the FogCreek offices.

But, yet, here’s Jeff saying he wants to build a totally virtual team. Say wha now?

Hey Jeff, this is great information and comes at perfect timing for me. I’m moving from Los Angeles in a month back to my home state in a small town because I want to be near family and miss the country living (Quality of life). I moved to LA 7 years ago to start my business and gain some well needed development experience on some teams. Now that my business is growing I’m looking to grow my team and I know the talent I would need will not be near the town I’ll be living in. Remote teams are the way to go. I’m glad that I’m not the only one out there thinking this! It is the way of the future!

Thanks for the information and I’ll be applying things from your post and also some from the comments.

It would be great for you to do a follow-up on what you do for your team members. Like paying for internet, providing hardware and software, etc.

Thanks

Thanks for sharing your thoughts on this.

As someone who has been working remotely for the past 3 months i can say that it works if the people involved want it to work. I have been doing scrum, with 2 week sprints and daily standup meetings via Skype, plus any required planning/retrospective meetings also via VOIP and it just works.

Whenever i need to talk to a colleague i do it via email, IM, or Skype, depending on the severity/level of understanding of the issue and so far it has been pretty much the same as being there, apart from missing the work-environment-typically-awesome sarcastic jokes, that is :slight_smile:

The greatest challenge, IMHO, is to find people who can make the system work :slight_smile:

I’m currently working remotely, with a team of people that are fluent and think in different languages, and so to communicate my thoughts to specific person I usually use specific language. I don’t think it’s taken into account here. Using IRC-like things like Campfire in such group, or Google Groups, or writing memos wouldn’t be of much use, unless it’s done for every language group separately. Yet it all seems to work well for us with one-to-one communication.