17 comments

[ 1.8 ms ] story [ 47.0 ms ] thread
I've worked in both remote and in-house teams. I can't stress enough how important it is to go to conferences together.

It doesn't need to be the whole team at the same time, but I believed it was my job as manager to make sure my team could go to conferences (dev, UX, IA, design) in groups.

Those situations have an uncanny ability to blend excitement, thought-provoking questions, a bit of insecurity, and plans of action.

When folks returned, both remote and in-house, it lead to better camaraderie and better output. Experiences are things people share and hold onto.

I'd really like to hear more stories like this one. Please share if you have a working remote team.

I'm absolutely over the rhetoric about how you need to be in the same office to have any sort of culture. There are online communities every where, they all have their own culture, their inside jokes, their group think, etc etc.

Maybe I'm just a bit bitter about the topic but I grew up online, I find online social connections to be equally as strong as offline ones. I guess I just feel the whole counter argument is baseless and unproven and not held up by anything more than survivor bias, industry norms and what people say investors hate to hear.

The pros easily outweigh the con's. Some teams it will absolutely not work. Some teams its the best way forward.

Sure. We're a company of 300+, completely distributed and contribute to building 23% of the internet. The company culture is unique, quirky, effective, and clever. I can imagine working in an office because I did it for many years. Can't imagine why I would ever want to do it again. Never been more productive or effective.

http://automattic.com/about/

A former colleague wrote a pretty good book about us: http://scottberkun.com/yearwithoutpants/

(comment deleted)
The aligns very closely with my experience in a distributed startup. Of course there are challenges like the ones mentioned in the StatusPage post, but I felt that post exaggerated the problems greatly. For example, complaining about a 3 hour time difference and lamenting that this meant almost no overlap in working hours for team members. Sure, if your team makes no effort at all to align working hours when needed.

There are a few points that stand out and ring true to me. As someone who has thrived as a remote worker and made a career of being a generalist, I was similarly surprised to hear from StatusPage that these qualities aren't compatible. My team members and myself especially picked up new languages, tools, roles, and responsibilities and ran with them.

As far as communication, weekly phone meetings (no video needed) coupled with in-person meetings maybe once or twice a year served to keep us all on the same page. The main method of day-to-day communication was via persistent chat rooms and direct chats between people as needed.

After years of great progress, we had a successful exit in 2014. When I find my next team, it will definitely be in a remote role, as the benefits to me are so great that I've essentially ruled out working in an office in the future. If you've convinced yourself that your organization can't operate with remote workers, then good luck and I hope you find the team members you need.

It seems that "high quality audio solution", in their case polycom, in our case mumble + good mics and "no videoconferencing" are among the most common thing I see in successful remote work setups.

For reasons I can't seem to put down on paper, remote setups that insist on lots of video conferences feel... oppressive in a way that working next to someone simply doesn't.

I've been on (and managed) both in-house and remote teams. As an employee, I love the flexibility of working for a remote team -- you're more focused on getting the work done versus spending 'x' hours a day in your office or in your cube. On managing a remote team, it emphasized my need to ensure that everyone had a clear understanding of the tasks at hand for that day/week/month and that we were all communicating effectively (We used IRC, VoIP phones with a built in VPN (they could be on the 'network' when plugged into the back of the phone), and google hangouts).

If you add in the fact that I'm basically in rural Appalachia (Eastern Kentucky) and there aren't that many DevOps/Linux SysAdmin jobs for guys out here -- I'm almost forced to be a complete remote resource for most companies. I've been doing a fair amount of interviewing recently -- I've had companies tell me that their engineering staff is completely remote but their DevOps team is an extension of corporate IT and that they need to be in the office for that (um, what?), that I'd be their first remote employee (scary), or that they have a cloud environment and they want a distributed team, but, everyone's in an office somewhere because they don't have enough internal support for a remote workforce.

From a manager's perspective, letting go control of your team is scary: you lose the ability to check in on your employees by walking to their desk, you lose the 'butt in seat' visibility of your team, and you lose the 'over the cubical' conversations. What they don't immediately see is that those same things still exist, and still happen, but in different mediums. Employees will still chat amongst themselves in IRC, managers will still message people or note who is or isn't here based on activity. Giving up that control resulted in a productivity boost for my team -- almost everyone (there was one employee who had an interesting home situation and we had to get him office space to work) was twice as productive at home than they were in the office. We still had our team dynamic -- we'd meet up once a week for dinner and work from a shared working space one afternoon a week -- but we felt closer to one another and understood our goals and targets more.

I did remote contract dev work for about 2 years with a startup (all members of our team of 3-4 were remote). It did take a little getting used to, but ultimately I enjoyed it. A few key things that helped:

1) Good communication (as many others have mentioned) - team members were always on chat (campfire->slack) while working. We also had semi-regular weekly video chats where we talked about what was going on. Video was nice because it helped to put faces to the people you were working with.

2) Don't focus on work 100% of the time - just like non-remote offices, people need time where they can chat about non-work related things, like games, home life, funny cat pictures, etc. Talking about these things helps create bonds beyond work, and improves the team imo.

3) Meet in person occasionally - the team all met once a year in person. Yes it can be a little awkward initially, but it also helps to further cement that there is a real person behind the chat.

I was curious about their point with VoIP. (Implementation, that is!)

David, if you're here, are you guys using SaaS for your VoIP provider, or are you using FreePBX or something? Or just direct phone-to-phone voip with the port forwarding that entails?

I'm not David, but I work remotely (+900 time difference!) and regularly work with others over VOIP. Hardware SIP phones are pretty hard to beat, but we often use Mumble for pair programming. It is a bit fiddly to get used to but it has some very nice features and we actually prefer it to SIP. First, you can easily (once you get the hang of it) configure the sound so that it is really voice activated. This is actually quite important for us because only about 25% of the team are permanently remote. When the office is noisy, it really is nice not to hear the background. When I used to work in the office regularly, I would pair program "remotely" with other people in the same room -- it is just a lot more physically relaxing to have your own space. I can also adjust the other person's volume to my own liking.

Another nice feature is the really low overhead of the server. Running a Murmur server barely ticks over my CPU, so it is easy for each of us to run their own server. This allows people to essentially join conversations at somebody's "desk" at will. Everything is essentially a conference call so it is easy to casually come and go, which is less nice with most SIP clients.

Finally, Mumble is really low latency. Especially since I'm 9 timezones away, this is really important. We tend to pair program using Tmux and Vim (which is really efficient), so you really want the voice to not lag too much from the action. Honestly with a combination of Mumble, Tmux and Vim, I often completely forget that I'm not physically in the same room as the person when I'm pairing.

We tend to use Google Hangouts for our standups and planning meetings. We make good use of the video and screen sharing in those meetings. I wouldn't say that I need video overly much, but seeing everyone for 15 minutes a day does help me feel more in touch.

Anyway, I know we're not the only group using Mumble. You might like to give it a try.

Using Mumble had never occurred to me, but it's a great idea. Thanks! :)
Using Mumble had never occurred to me, but it's a great idea. Thanks! :)
We do what they do, but not with voip phones, with Sococo. I work there, and our team is in 5 states and 2 continents. We use our own product for all of our development.

Its especially important to have regular team online meetings e.g. Scrum. This is both for communication and for socialization. Its easy to forget that other remote workers are people; its easy to quit talking to them. Seeing and hearing them daily makes them people again, instead of just an avatar.

The biggest problem I've seen with remote work is management. You need the right people but management can also make or break the team. If they don't understand how to manage a remote team effectively it's going to be a disaster.
I run a consultancy of about 15 including myself. We use a combo of Ventrilo (http://ventrilo.com) and Slack. I'd make a bet that our productivity and communication is better than 99% of any company.

Alternatives to Ventrilo (just my personal preference, really), includes Mumble and Teamspeak. Everyone is required to have a push-to-talk key, too. We give everyone their own office (a la dedicated channel for them), and have some scripts built into that allow us to page another user and tell them we need their attention.