
Ask HN: How do you integrate remote developers? - tnitsche
We are a team of 12 developers in our local office plus five to six remote guys. How do you integrate remote developers? On a technical level (video conferencing, IM), but also on a social&#x2F;personal level (team spirit etc.).
======
up_and_up
I have worked remotely for 4 years.

Start by creating a remote-first culture. Everyone should think "remote"
first. Thus it should never matter if a local employee is working from home,
the HQ, from the other side of the world. Make all work processes remote
friendly. That should be step zero when considering hiring a remote person
regardless of the reason. The goal should be to avoid a two-tiered culture.
Some differences will always be there but if the spirit of the remote-friendly
culture is there integration is pretty fluid.

Thus (near) all communication happens in Slack/Hipchat/etc. Group meetings,
when including remote people, happen in video conf / Hangouts. Shared Google
docs to collaborate on. Have in-person meetups 2-4 x a year for beneficial
face-time and for people to get to know each other better on a personal level.
When a new person is hired, have them do 20 min 1-on-1's with all team members
to get to know each other and their job role. Have monthly video conf/hangouts
on non-work technical topics where people rotate presenting.

The biggest element is the decision to be a fully remote team. Which honestly
is a major retention benefit as well. Why should local employees not enjoy the
same flexibility to work as needed remotely?

~~~
dhd415
Your point about a remote-first culture is 110% true. It has to be in the DNA
of the company or else remote workers end up as second-class citizens. While
it does not have to be the case, it does seem to be true that if a large
portion (~50% or more) of the team is not remote, the culture will rarely end
up being remote-first. If the culture is not remote-first, you end being just
that guy who comes into the office every few months. I'm working now in such a
situation and it's not pleasant.

~~~
dsp1234
A concrete example of this is if someone stops by your area to ask a "quick
question" then culturing an environment where an answer of, "Why don't you
bring that up in the global chat so everyone can contribute?", is welcomed
rather than brushed off as being unfriendly.

~~~
dvcc
Would anyone else find this tiring though? I feel like I am omitting the use
of basic communication skills in favor of something less than ideal.

I guess I am just not a huge fan of remote work in general though, so I have a
hard time coming around to the idea that quick questions must go through a
chat at all times.

~~~
dsp1234
It's a matter of culture.

It may be tiring for some people, but having what I call 'dark meetings' all
the time encourages a policy where remote workers are shut out of the process.

This is pretty much the same as a default policy of "Don't IM me one-on-one,
IM us all in the group chat", with exceptions for personal issues. I feel it's
a good policy in general for two main reasons, first it increases the
possibility that an issue is seen by the exact person who can respond to it,
and second it discourages the formation of cliques of people who are doing
their own thing which no one else knows about. Business requirements can get
lost all the time with reasons like "Oh, I PM'd Jim about it, and I though he
would mention Helen".

So relating that back to remote workers, most meetings (and at least in my
office, most meetings means basically every single one) are not formal
meetings where everyone is involved. It's one-on-one's in someone's office, or
talking offhand at the break room, or passing in the hall, and almost never
officially recorded. That's perfectly fine (and it works with us as we have no
remotes), but it hurts when you bring in remote workers because, by
definition, they are attending less 'meetings'. Previously working remote, and
having supervised remotes, this is one of the greatest issues that they face.

So if the original question is 'How do you integrate remote developers?', then
whatever solution that is presented will need to deal with these 'dark
meetings'. My personal suggestion, and the one I've seen work the best, is
just to try to encourage a culture where people recognize that they are
talking about work, and to table that discussion until everyone is present
(which in remote workers case is IM). It may sound dumb, but if everyone just
said something like, 'Hey, this sounds like an issue Bob or Jane could help
with, why don't we discuss that in dev chat', and that was considered Ok, then
it flows smoothly.

~~~
chris11
Does this scale well? I don't think group chat would work well for larger
chats. I personally ignore a lot of email that I isn't personally relevant.
And one-on-one conversations are usually more personally relevant than group
conversations.

~~~
brianwawok
I know of several 100 to 50p person companies that are 100% remote. You just
use chat rooms a lot.

I never worked at a giant remote only company or old school Yahoo, so not sure
how it scales there.

------
princehonest
In office and working remotely will never be the same experience. I worked
remotely for three years at my previous job, where I was part of a team of a
dozen or so that was headquartered in a central location. The majority of the
team participated at the HQ, and I was remote. We had IRC, video conferencing,
and all the necessary technology set up. Regular visits to HQ helped. However,
the thing that made the biggest impact was everyone else on the team started
to work from home on occasion. This made communication happen in a remote-
first manner so it was level playing field for all members. I would suggest
reading the book, Remote, for more ideas of how to make it work.

~~~
dorfsmay
This is a huge thing. If you're not mainly remote, let locals work from home,
with the same standard as remote workers:

\- be available during core hours on chat

\- mark your calendar when not available or in meetings

\- do video and phone meetings from a quiet space (no dishes, drill, vacuum
noise, no kid crying)

This will do two things, it'll reduce the jealousy and tension towards remote
workers, and it will increase the local workers understanding of remote
working (eg: they'll start to make sure they're always on chat even when in
the office).

------
junto
I'm one of a few remote developers on a team of 15.

Daily standups, dialed in on planning meetings and the odd visit for project
kick off meetings all help to make me feel a little more integrated into the
team. In saying that, I'll never be as integrated as the people that are in
the office everyday, but I can live with that for the flexibility remote
working gives me.

I should also note that I don't work from home, but rent a desk in a coworking
space.

I truly think that this is the future of the work environment. People go to an
office to work, but one that is local to them, rather than relocate.

~~~
vmateixeira
I like you're thought about the future of the work environment. Can you tell
me, from your experience, how easy was for your company to accept for you to
work remotely? I work for a startup in the UK, with a very small team, and
can't find an easy way to apply for that.

~~~
junto
I'm pretty much the same as you. My main client is in the UK and they are a
solutions provider. At the beginning I was due to move away from the area
local to the company. I made the suggestion that we try the remote working and
if it didn't work for either party, we'd call it a day. That was 2004.

The most important part is trust. People know I'm sitting at my desk working
and checking in code, because they can see me/call me on slack or Skype and
they can see a steady stream of code check-ins nd build server and JIRA
tickets being closed off. Never take the piss, always be completely honest and
upfront with your time and be respectful. I can't think of any other advice I
can give over that, apart from that you should definitely try to work from a
coworking space rather than from home!

~~~
vmateixeira
Thanks for your advice! I can see your point and those arguments you described
can also be applied to my behavior and actually be a valid argument for my
remote working application. I also agree that working from a coworking space
can be much more beneficial than from home.

------
jmarucci
We have a 40% remote staff at DigitalOcean. So this is really important to us.
Initially, they come to the office for 1-2 weeks when they first start to get
face to face introductions with everyone on their team and as much of the
company as possible. Part of our standard onboarding is for each manager to
take them out to lunch and to host a team event while they are in town. This
is social time to get to know them on a personal level. We conduct a remote-
exclusive on boarding for an hour to provide them with key tips on being
remote and how to be a successful remote at DigitalOcean. This includes
booking travel in the future, expensing items when in town, information about
corporate apartments, and an introduction to our people team Remote Point of
Contact. After they return home with a better sense of the role and company
they just started for, the full “remote” experience starts. We have a slack
channel that our remotees “hang out” in all day. They created a weather bot to
share their local weather, greet each other with a “good morning” and continue
on to chat all day as if they were next to each other in a space. This is
actually my favorite channel on slack because it encompasses all the random
water cooler conversations around the office into 1 area. We do a lot for our
employees in house and remote. The key is to not make our remote staff feel
like they were a second thought. For example, we had a large company
Thanksgiving dinner in November so we sent Thanksgiving pies to all of our
remote staff. They received it right around the same time we were all going
out to eat. We had a holiday dance party, so we sent our remotes speakers in
the shape of droplets (which is our product here). We went to Tribeca Film
Festival at HQ, so we sent each remote a box of movie candy and gift cards to
the movie theater for them AND their families.

We have built our current office space to be as remote friendly as possible.
We integrated Google Chromebox for meetings in every conference room and
telephone room. This prevents about 5 minutes of initial setup for microphone
and camera. We have already invested in, and continue to invest in, state of
the art technology for our All Hands Meetings. Proper microphones, speakers,
and cameras in our “Atlantis”. Once all presentations are are complete, we
switch to the camera view so we can see all of our remotes in the room with us
as we continue through our AMA portion.

These are just the baseline of things that we have done to make our remotes
feel connected even when they are not in our office. We continue to upgrade
the experience often and are continuing to grow our remote staff
Internationally.

~~~
jmarucci
++ WORKSTATIONS! We give our remote employees the same workstations our in
house employees get. Choice of 1 - 2 screens (27" Dell 4K, 1 34" Curved Dell
or a Thunderbolt), keyboard (Apple, PC, or Code), and mouse (trackpad, MX, or
PC mouse).

------
brudgers
Scott Hanselman has worked remotely for several years. Unsurprisingly, he's
done so loudly and opinionatedly.

[http://www.hanselman.com/blog/CategoryView.aspx?category=Rem...](http://www.hanselman.com/blog/CategoryView.aspx?category=Remote+Work)

Part of the problem stems from the framing of the question. Flipping it on its
head as "how do you integrate local developers into a team?" highlights how
easy it is to believe the team's core must be determined geographically rather
than functionally.

Reframing remote work as the normative context then places responsibility for
accommodation on the people who have the habits that make integration
difficult.

------
mariojv
Pretty much the whole team works remotely.

We use IRC for everything, which has the good side effect of preserving
knowledge for later. Everyone has a bouncer like ZNC setup so they don't miss
anything while they're offline. Managers, directors, and VPs all encourage
work from home, and a lot (including my manager) work from home themselves. We
have an internal video conferencing system that we use frequently. We have a
sync twice per week via video, a weekly 1-on-1 with the manager, and people
hop into a dedicated engineering room whenever they want high-bandwidth
communication with someone or just want to hang out there.

We also have a non-work IRC channel we use to talk about anything, in terms of
social / team spirit related things. We have monthly tech talks that anyone
can give. Once a year, we meet up for a week in person to get high priority
things done. The company also sends us to open source conferences, so we see
each other there a couple times a year. A couple folks play video games
together like CS:GO. We are thinking about making an optional weekly gaming
event with people, maybe something like LoL.

A totally optional thing that I like doing to preserve some record of my work
is IRC standups. We have a web form where you can submit what you did
yesterday, what you're doing today, and any blockers which gets posted to a
separate IRC channel to avoid spam. Other teams with whom we collaborate on a
daily basis also use IRC heavily. My manager doesn't like having this, but I
like having an IRC highlight with my name that beeps whenever someone mentions
my nick or asks me a question.

With this, we're able to collaborate across quite a few timezones, including
one dev in the UK. It's worked out really well. I live near the HQ and
sometimes go into the office, but generally working from home has been really
efficient for me and a lot of our team.

~~~
kzisme
What sort of company do you work for that uses IRC heavily? (IS it a software
company or a non-software company)

I assume the latter - but it sounds like a very nice way to do things.

------
euroclydon
Hmm, how do you integrate local developers? Everyone is unique. Bob may not be
too excited about the Sweet Sixteen beer fest that Jane and Jim are so pumped
over. I'd say developers are most integrated when they have important tasks or
areas of responsibility that they handle well, and everyone acknowledges their
competency. In other words, they are a solid contributor. So have them work on
something important, that's within or near their capabilities. Or if they're
more junior, give them tasks that require them to ask questions of more
senior, local developers. Remote developers have to be driven and independent,
hopefully the kind of people that read the docs and code before asking too
many questions.

Then you just have to worry about communication. But the onus of communication
is on the remote worker, IMO. The most successful remote people I've worked
with were all excellent at written communication. You may think that having
extra meetings and video chats are a way to integrate the team, but it could
be better to let remote workers leverage the quietness of their remote setting
in order to knock out code that requires focus.

That said, chat is huge! But it's like texts, in that it's socially acceptable
to answer anywhere from immediately, to an hour later.

For team building, I find it's good to fly everyone in a couple times per
year, for product planning and social time.

~~~
fishfacemcgee
> But the onus of communication is on the remote worker, IMO.

I may be misunderstanding you, but, if I'm not, I mostly disagree with this.
Remote workers need to communicate well, but if all 12 local developers are in
a shared office/working environment, then it's really easy to exclude the
remote devs. If your remote devs are treated as second-class citizens
(intentionally or otherwise), they'll never be integrated in your team. Lots
of things you get "for free" with local teammates (as far as communication,
camaraderie, etc.) you have to be more deliberate about with remote ones.

Part of the benefit of being remote is the ability to be even more self-driven
than you are when you're in an office. That shouldn't come at the cost of
being left out of the loop and/or not being included in discussions that you
could contribute to.

This may not work for everyone, but the way we do things where I work is we
use remote-focused communication (chat, video conferencing, Wikis, etc.) as
our primary communication. We try to limit any in-office conversation to the
relatively trivial or the extremely time-sensitive. However, the way our
company is distributed, most of our team leads, internal stakeholders, etc.
aren't local, which helps "enforce" that mindset.

As far as specific tech solutions here's what we use:

HipChat Zoom (video conferencing) GitHub Confluence + Jira Jell
(distributed/asynchronous standups)

At the end of the day, the tools make remote working possible, but the mindset
we approach remote working with is what makes it viable.

~~~
euroclydon
Yeah, I agree. Everyone should be on chat when you have remote workers (in a
similar time zone). Important communication should happen or be tracked in
email, slack, code review comments, issue/bug discussions, etc.

------
alexeysemeney
I have been managing remote devs for 4 years and now running
[http://devteam.space](http://devteam.space). So, have a decent expertise at
that. Maybe you can apply it too. Here are must have rules:

#1. You need to have a PM for remote devs, on their side. Or decide who is the
PM out of these remote devs. This person will be your trustworthy manager. If
something goes not right, you talk to him/her first. Ask him to provide all
the honest and bold feedback from himself and all the other remote devs if
something happens.

#2. Request daily short updates from every developer. Just 2-4 lines of text
about what have been done during the day. Explain to them that you will not
actually reply to these updates. It's just to keep everything transparent. So,
they write - you only read. Rarely reply with some questions.

#3. Set the goals on projects you work on with them, request deadlines, you
can set it in sprints. It's like mini OKRs (google it if you don't know what
is it). It helps them to be accountant and spend their working hours wisely.

#4. Have at least one 30 min call per week with all the remote devs to chat
about what you are doing and motivate them with some good news. So they would
feel they actually get paid not just for the code, but they make a difference
for your company and for your clients. Share with them what you personally
have done during the week. All people want to work with even better people, so
it should be clear for them that you are awesome. They will respect you more.
Basically, treat them as your usual team members.

#5. Use some reporting tools. At DevTeamSpace we have this kind of dashboard -
[http://i.imgur.com/F6Q3COn.png](http://i.imgur.com/F6Q3COn.png) . Maybe it
would be helpful for you too.

In fact, so many companies struggle to manage remote dev teams. If you need
any help - ping me at alexey(at)devteam.space.

~~~
berd
I like how you work, can you please contact me?

~~~
alexeysemeney
yep, ping me over email

------
mbrock
The prevailing ideal of a commercial software team is a tight knit tribe.
Members are selected for "culture fit", ability to do pleasant small talk
around the lunch table, personal hygiene, and so on. The team should huddle
around every day for status updates, bonding, and small talk. Communication
should be frequent and face-to-face collaboration is considered the ideal.

You can adapt this ideal to remote work situations and there is lots of
material about how to accommodate that. But many people who gravitate toward
remote work are probably trying to move away from this ideal.

For some it may be because they've experienced open source collaboration and
don't see why commercial development can't be done in a similar way.

Open source projects tend to use low-bandwidth, asynchronous communication,
perhaps as a cultural heritage from the days of slow internet. That enables
collaborators to schedule their work in whatever way suits them.

Many programmers are psychologically introverted, which means that they
function best when they're allowed to be by themselves, instead of being
constantly communicated with. These programmers are often unhappy in the
office environment, especially those with open plans.

If you take a step back and look at contemporary software development offices
from a kind of anthropological perspective, it's actually quite a bizarre and
extraordinary way of life.

When everyone is in the same house for 8 hours every weekday, the demand for
social compatibility is, in some sense, even greater than with most families
and friend groups... one way to get around that is for each worker to wear
headphones all day, which is also quite a strange situation, socially...

I'm personally yearning to be able to work remotely in a way that suits my
introversion and my preference for asynchronous independence—or to be frank: I
just don't want to be in the same house all day every day with 10 other dudes,
and I really don't want to be on conference call with them all day either.

Nor do I really want a strong "team spirit" in the sense of social bonding. I
think work would be more sustainable and enjoyable if team relations were
_less_ tight, and if my lifestyle allowed me a wider spectrum of daily social
interaction.

I'm motivated by helping to do good software development. I'd rather do this
in a way that's like the open source model, preserving my basic independence
in terms of location, time, and communication.

~~~
joesmo
This is exactly how we work at my job currently. We use pull requests and each
programmer picks a task and goes on his way. When it's done, it's submitted to
the other programmer for review (we have two full time). Most communication
happens in chat and pull requests and we rarely have meetings other than the
daily scrum-like sync up meeting (which is tolerable). Most tasks are half a
day to a day (except larger tasks) so the turnaround is quick in case
something was misunderstood. I think this process could easily scale to more
developers as long as they are independent and able to work by themselves most
of the time, unsupervised. That doesn't mean they have to be senior, only that
they are disciplined and won't get stuck on easy problems.

~~~
mbrock
As I see it, that's still far away from the kind of "open source" development
model I'm thinking about.

Most obviously, no open source project has mandatory daily status meetings!
And usually, tasks are larger. They often have chat rooms, but they're not
really used for synchronizing work, more for idle socializing and occasional
discussions.

Daily coordination in the "scrum" fashion, I think, is still under the
threshold where work tends to become "tightly coupled" and synchronous. I have
more thoughts about how I think this can discourage longer-term projects...
but, another time...

By the way, I think these are just two different models, with their own flaws
and benefits, and it's interesting to think about whether they could be
combined in some novel way.

------
alistairSH
My team (I'm the project manager/tech lead) is roughly half remote, with the
remotes including my product owner and lead test engineer (among others).

As noted elsewhere, thinking remote-first is required for non-co-located teams
to be successful.

Technical items, in no particular order: All meetings are conducted with full
video teleconferencing.

Most meetings are configured to default participants as muted (help stop
random noise on line).

When we white-board, we use a webcam (or lacking that, frequent cell-phone
pics) to keep remotes in the loop.

Heavy use of IM tools, online wikis/notes, etc

Social Things: Try to meet in person occasionally. Obviously doesn't work if
people are truly global, but I usually see my team in person at conferences,
client meetings, or we fly them in every so often (project kick-offs, major
high-level design efforts, etc).

Find team building activities that can be conducted via video-conference.
Commit to doing them regularly.

If you conduct 1-on-1s, make sure part of those meetings is social. Take the
time to do some "water-cooler" chit-chat.

~~~
gautamdivgi
I work remote most of the time and so do almost all of my colleagues. But I
think you've highlighted an important issue here. White-boarding!!!

No communication tool comes close to a human drawing pictures to explain
complex concepts - a picture is worth a thousand words.

What I did is invest in a Wacom tablet (I do not work for Wacom) to be able to
explain and draw to people I'm on calls with. It takes a bit getting used to
but definitely makes my meetings much more productive.

From a technology standpoint I'm surprised there isn't a better integrated
experience to mimic the actual whiteboard that can be shared across several
people on a conference call with a digital pen.

~~~
jmarucci
Smartboards exist! Also, some competitors are creating comparable items as
well. I am looking into this myself so that our engineering team can white
board together.

------
ollifi
Not good general advice maybe, but I had good success working remote with more
like telepresence setup. I had small monitor in the corner of the office and
people could walk up to it and speak to me. I could also overhear quite a bit
of the chatter in the room. It was very important that people could see me on
the screen.

Although I missed many of the perks of working remote I felt pretty connected
socially. What I discussed with my colleagues they also found it ok.

As said this is not for everyone, but I look forward to technologies that
enable people being in same place remotely.

~~~
JangoSteve
I really like this idea for our office, but I'm afraid if instituted, it'd be
perceived as just a way to ensure remote workers are butts-in-chair during the
day. How useful do you think this would have been as a one-way stream (i.e.
remote workers can see the office, but the office can't see the remote
workers)?

~~~
ollifi
I understand what you mean. For me it was not a problem. If you are working in
office people can count the hours you are sitting as well. I didn't view
working remote different.

And you can still turn the stream off if you want to concentrate. I can't do
that in open office.

If the monitor was turned off for some reason it immediatly turned into
eavesdropping as people simply won't feel that you are there. So I think it
was important that audio would only travel if person listening was being seen.
That really helps the lizard brain to sense that someone is present.

~~~
dorfsmay
What about being available on chat and being able to quickly do a video conf
whenever needed?

------
fourfivesix
\- Smalltalk can happen over IM, if you work at it. During standup ask for
"consumption updates" meaning what movies, books, TV shows people have
consumed - great fast way to learn interests. \- Move from oral to written
communication. Could a person who could not hear at all make it at your
company? Write everything down to keep a remote minority in the loop. \- This
is harsh, but teach the remote developer that they need to do some of the work
themselves to integrate. They might have to go out of their way to push
updates, ask questions, etc. They are the canary in the mine and should tell
you when they are left out. Be open to this feedback

------
pinewurst
I've been working remote for the past 5 years at 2 employers.

My first group was very coherent and supportive even if remote. We were
constantly in contact via chat/email/phone and there was a sense that we could
count on each other to get things done. We only met in person once or twice a
year, which didn't seem like a big gap given our close communication.

My current group, while the company strongly supports remote workers, is very
detached and isolating. I actually see my coworkers a lot more frequently but
don't feel a lot of commonality or support. Some of that is just how this
organization is constructed - it deemphasizes peer-ship.

------
mgav
@alistairSH is right about taking time for chitchat. I think of it as an
investment in a relationship, like any other. Be interested in the other
people and what they're passionate about in their lives. Share some of
yourself as well. Sending an occasional article or image the other person
might be specifically interested in takes very little time, but if it's of
quality and a great fit for them it's a nice building block.

------
justin808
Picking either in-office or "remote-first" is what matters most. Companies
cannot optimally be both simultaneously.

I'm Justin Gordon, the founder of ShakaCode,
[http://www.shakacode.com](http://www.shakacode.com). My article and video on
telecommuting from Maui is still the number one google search result for
"telecommuting maui": [http://www.railsonmaui.com/blog/2014/05/06/remote-pair-
progr...](http://www.railsonmaui.com/blog/2014/05/06/remote-pair-programming-
tips-using-screenhero/).

I've been a full-time remote worker from Maui, since 2007, a remote freelancer
since 2011, and over the last 2 years, I've run a remote consulting and
product company. To brador, that says "Remote devs start to have mental health
issues from the loneliness and lack of supervision in down times", I'd say
that's total hogwash. We spend almost every day video chatting on Skype with
people (team members and clients) around the world, and we are very often on
ScreenHero sharing screens (often with Skype video), and always on Slack and
github conversations. There is 100% no loneliness with this lifestyle. In
fact, I'd say spending 1-2 hours a day commuting is a far bigger risk for
physical and mental health issues!

Since I founded my company to be 100% remote-first, we've avoided many of the
issues that face companies that are schizophrenic about remote work. I've
heard numerous stories around Silicon Valley about how companies start
allowing "work from home days" and then the senior managers see the parking
lot 3/4's empty at 11am, and then there's an ultimatum that you have to work
from the office unless you have specific management approval to work from home
for one given day. And I'm NOT EVEN EXAGGERATING ONE BIT!

One of the keys to my firms success is to hire team members that love what
they do, either programming or design, and that typically interact well on
open source. To that end, I've found almost all my team members though our
popular open source,
[https://github.com/shakacode/react_on_rails/](https://github.com/shakacode/react_on_rails/)
(1238+ stars), which is the number one package that integrates Ruby on Rails
with React via Webpack and NPM.

------
Sondra
In our team there are 4 remote guys. We communicate in Slack, share Google
Docs when needed, track tasks in JIRA, collaborate on the product design in
RealtimeBoard app, conduct daily meetings via Skype. To support the team
spirit we organized several AMAs within the team via Skype. There was no
restriction on the questions, so we also learned some facts about employees
private life (f.ex. when they have shown their pets).

------
dorfsmay
In addition to everything said here, one thing I find that helps is framing
video meeting. Are you calling to mainly shoot the breeze and talk a little
bit about work? Or is it literally 5 minutes to get a specific answer? Or a 30
minutes formal meeting with an agenda and take always?

If you don't some people will become very reluctant to video conf as they'll
see it as constant water cooler talk that prevent them from working.

------
flurdy
First, all remote developers must first work on site for a few weeks/months.
That way people know what they mean between the lines and vice versa, and what
their personality is like etc. So communication becomes much more fluid once
remote again.

I also would insist on tools equivalent to screenhero and floobits to
facilitate pairing, whether remote or inhouse.

I would also have a convention of not switching off webcams in meetings.
People often do that, thinking why do people need to see my face, but it is
essential that they do so that visual communication/presence also works.

I also like the idea of having a skype/hangout running all day long so remote
people are aware what happens in the office, who is around etc. At one startup
I hurt my leg and was WFH for 3 weeks. They left an ipad running skype all day
on my desk. It was great as people would walk up to my desk to ask quick
simple questions / water cooler comments etc, instead of most likely not send
a hipchat/slack message as not important enough.

------
hellofunk
We're quite dependent on all the Google tools: chat, Hangouts, shared Docs. We
do screenshares often as well as normal face-to-face video conferencing all in
Hangouts. It's worked for us for many years.

We also use Basecamp on a daily basis for specific project tracking.

All in all, we are pretty "integrated" using this rather minimal set of
technology.

------
brador
I tried remote developers and couldn't get it to work efficiently. Remote devs
start to have mental health issues from the loneliness and lack of supervision
in down times. Regular employees can start to feel jealousy towards them, and
organizing teams and talks becomes hell with a random face showing up.

My advice - have a core team in house and out-source what you would have given
to a remote dev. You're going to be parcelling out jobs to the remote dev(s)
anyway, but with freelance they're not your problem if they get lazy and you
can next them easily. Also, a single cost for the job and no employee
paperwork to deal with.

Plus, if a freelancer proves themselves an excellent part of the team you just
throw them more and more projects of increased scope.

It's win-win.

~~~
LargeWu
"lack of supervision"

If you need to "supervise" your employees, you have either hired the wrong
people, or not given them agency to just do what needs to be done. In either
case, remote isn't going to work, but it's not necessarily because they're
remote.

------
planetjones
With difficulty:

1) Use as many visual techniques as possible e.g. Screen sharing and drawing
pictures and sketching examples of what you're talking about.

2) open chat channels all day

3) ability to build rapport e.g. During standup calls look at what the weather
is like in their country or share something about what's happening in your
area at the weekend. Ice breakers if you will

4) if possible get them to visit you so they understand the culture in your
office and understand the people. the most success we've had is when people
visit the local team soon after joining

~~~
kasey_junk
Do you have a preferred sketching tool? One thing I've yet to figure out
remote is a seemless whiteboard session.

~~~
planetjones
I'm quite happy with SnagIt - just take a screenshot of my starting position
and start to annotate it. Or start with a blank image in SnagIt and start to
draw my boxes and arrows.

------
trequartista
Automattic, the makers of Wordpress is an all-remote company. Here are a
couple of good articles on how they make this work:
[http://www.businessinsider.com/automattics-awesome-remote-
wo...](http://www.businessinsider.com/automattics-awesome-remote-work-
culture-2013-8)

[https://automattic.com/work-with-us/](https://automattic.com/work-with-us/)

------
TheCondor
Good quality time together when you can get together. Initially I'd try to
conduct as much business as possible during office visits, building rapport
and friendship is more important. Eat together, talk about non-work things. Do
team building.

Beyond that, you have to practice the technical bits, conduct all meetings on
a google hangout. If people don't offer remotes that opening to talk, they
have to make it.

------
samrocksc
Make everyone work from chrome books....they will learn how to remote real
quick even when they are in the office.

------
cjbprime
[https://perch.co/](https://perch.co/) is useful for us.

