I want to get a conversation going on favorite tips for remote workers and remote teams. I’m inspired after rereading Jeff Atwood’s (aka codinghorror) article:
I’d say that much of what’s in that article is still 100% correct, and that there’s some newer technologies, such as Slack.com that should get mentioned.
To quote Jeff:
So, there are a few basic ground rules for remote development, at least as I’ve seen it work:
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.
The reason remote development worked for us, in retrospect, wasn’t just shared love of code. I picked developers who I knew – I had incontrovertible proof – were amazing programmers. I’m not saying they’re perfect, far from it, merely that they were top programmers by any metric you’d care to measure. That’s why they were able to work remotely. 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.
While Joel certainly had a lot of high level input into what Stack Overflow eventually became, I only talked to him once a week, at best (these calls were the genesis of our weekly podcast series). I had a strong, clear vision of what I wanted Stack Overflow to be, and how I wanted it to work. Whenever there was a question about functionality or implementation, my team was able to rally around me and collectively make decisions we liked, and that I personally felt were in tune with this vision. And if you know me at all, you know I’m not shy about saying no, either. We were able to build exactly what we wanted, exactly how we wanted.
Bottom line, we were on a mission from God. And we still are.
So, there are a few basic ground rules for remote development, at least as I’ve seen it work:
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.
And definitely ping me if the idea of working with my group (based in Hawaii, but remote is OK) appeals to you.
Remote versus Co-located Work by Martin Fowler: Interesting Paradox: “Most people are more productive when co-located” yet * Remote teams are often more productive
It’s worth quoting Martin Fowler’s conclusion:
As I hope is now obvious, there’s not enough good evidence to form any strong conclusions about the efficacy of remote working. But based on these shaky foundations, these are my key thoughts:
Never forget there are different distribution patterns for teams, not just a simple remote versus co-located dichotomy. The advantages, disadvantages, and effective techniques for multi-site teams will often differ from remote-first work.
Most groups of people will be more effective when working co-located due to the richer communications they have. But don’t let that make you forget that some people seem be more effective when in a remote-first model.
Despite the fact that I think most teams would be more productive working co-located, you will often get a more effective team by embracing some form of distributed model because it will widen the talent pool of people you can get.
When using a remote working pattern, pay attention to how the communication patterns form. Invest in improving communication, including travel and technology.
The fact that you can get a better team by supporting a remote working pattern has become increasingly important during my time in the software business and I expect its importance to keep growing. I sense a growing reluctance amongst the best developers to accept the location and commuting disadvantages of single-site work. This is increasingly true as people get more experienced, and thus more valuable. You can either try to ignore this and accept the best people who will relocate for you, or you can explore how to make remote working patterns more effective. I think that organizations that are able to make remote working patterns effective will have a significant and growing competitive advantage.
I will never stop learning. I won’t just work on things that are assigned to me. I know there’s no such thing as a status quo. I will build our business sustainably through passionate and loyal customers. I will never pass up an opportunity to help out a colleague, and I’ll remember the days before I knew everything. I am more motivated by impact than money, and I know that Open Source is one of the most powerful ideas of our generation. I will communicate as much as possible, because it’s the oxygen of a distributed company. I am in a marathon, not a sprint, and no matter how far away the goal is, the only way to get there is by putting one foot in front of another every day. Given time, there is no problem that’s insurmountable.
I have remote paired at Pivotal Labs full time (with week on-site visits every 4-6 weeks) for going on ten years.
Remote pairing is very different than non-pair remoting, which most people write about. It’s physically, intellectually and emotionally draining. But, it’s my only chance to work at an amazing place like Pivotal, so I deal with it.
My colleague Joe Moore, who has remote paired nearly as long as me by now, has a site with a lot of great info: http://remotepairprogramming.com/
Thanks for the insight. I used to absolutely LOVE TDD and Pairing. Now, I view those more pragmatically. Both TDD and pair programming work optimally for certain scenarios, but not for others.
These days, my team is really loving the combination of Skype for video and ScreenHero for screen sharing.
However, Pivotal Labs was founded on a culture of full-time pairing and strict TDD (along with other XP principles), so it’s a clear prerequisite and expectation when people interview to be hired.
That’s also why they never hire new remote employees - co-located teams are the expectation. I think I was the only exception, along with some other people who were hired locally and subsequently moved but wanted to stay with Pivotal.
As I said, it’s much more demanding than “normal” non-pairing remote work, but after pairing for so long and recognizing the value, it’s actually harder for me to work solo in many ways.
