Ask HN: How do you integrate remote developers?
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/personal level (team spirit etc.).
92 comments
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?
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?
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.
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.
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.
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.
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.
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.
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.
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.
I never worked at a giant remote only company or old school Yahoo, so not sure how it scales there.
Your solution is good. I also will take 'dark meetings' and summarize the meeting in the tickets/confluence. This gets the information out to everyone (even others who are locally present but not in the meeting), and saves it for when I forget the meeting later :)
The problem with that approach is that it inevitably favors the input of people who are physically present even if they are not the ones with the best answer to the question. As a remote development lead in a company without a remote-first culture, I find this happens a lot. The end result is that I end up having to fix a lot of problems that were caused by technical discussions that did not include the people such as me who had the most product context and technical expertise to correctly answer the question.
Do you not hold that more on your team though and less on the communication style? To me, if I know that someone else might have some information that would contribute to the discussion I'll include them.
That feels like it would be more on the individual team members not knowing when to reach out, more so than the in-person meetings causing a remote/local gap.
That feels like it would be more on the individual team members not knowing when to reach out, more so than the in-person meetings causing a remote/local gap.
Some teams may be more prone to that problem than others, but it always takes more effort to include the remote folks in the conversations. It's usually true that the really momentous decisions are handled in meetings that include the appropriate workers, whether on-site or remote. The biggest problem is often the "not quite really important" questions for which the on-site folks figure that a answer from another on-site person that is "good enough" will suffice. The end result of that is growing technical debt from a series of decisions that weren't as good as they could have been with the input of the workers with the most knowledge of the problem area.
I guess the person who is always interrupting others in favor of their own issues would find it tiring. But the person who is constantly being interrupted would find it refreshing that they can prioritize themselves.
We need to get off of this 'I am a special snowflake' that cannot be bothered to work with a team. If you want to solo develop than go be a solo app developer. If you want to deliver software as part of a team, then working with the team is part of the gig. I know it is hard to believe, but the act of coding is only one part of many required to deliver working software that meets the requirements.
Great function you wrote there that does the wrong thing because you were too busy to be bothered.
Great function you wrote there that does the wrong thing because you were too busy to be bothered.
Working with a team doesn't mean synchronous communication. We need to get off of this "I am a special snowflake" and my current issue trumps whatever anyone else is working on.
Hire good people and trust that they will respond to issues appropriately. If your services are down and the company is bleeding cash every second, they will stop what their doing and help fix the issue.
Having communication be synchronous-by-default more easily leads to scenarios where you decide to ask a colleague a question real quick that breaks their flow. I'm guilty of this myself.
Hire good people and trust that they will respond to issues appropriately. If your services are down and the company is bleeding cash every second, they will stop what their doing and help fix the issue.
Having communication be synchronous-by-default more easily leads to scenarios where you decide to ask a colleague a question real quick that breaks their flow. I'm guilty of this myself.
The equivalent for remote is to ask someone if they've got a sec to jump on a hangout, it definitely isn't to start having a chat on slack. Slack is extremely low bandwidth, especially if you're trying to reach consensus on something, where body language becomes more important.
Personally I would not like that. There are times for putting something on global chat but a direct conversation is often hard to beat to figure things out.
I second the "remote-first" culture. Mixing on- and offsite developers is very hard.
I second the "remote-first" culture. Mixing on- and offsite developers is very hard.
Happened to me too. I lived on the east coast and my team, where I was the only remote employee, was in the west coast. They would schedule stand-ups in their afternoons not realizing it was 7:30 my time. I didn't stay at that job very long.
I agree. I've both worked as an employee and as an employer from remote work, and it's just really hard to get right. But if there's one thing is to make it remote friendly right from the beginning. Think about it, it's practically impossible to force an existing organisation to change the whole way it works in just one day because there's a new remote employee. And, if the organisation doesn't change, that new remote employee won't like his experience (I know I didn't). However, built from the beginning, then everyone will already work and be remote-friendly.
>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.
This is a turn-off for me as a full-time remote worker. When I browse remote job listings, a lot of companies list this like it's a perk. Maybe it's a perk if you're a 23-year-old single guy, but it's not a perk for me; it actually flies in the face of why I'm a remote worker, which is that I want to focus on my work with minimal interference on the other components of my life (which are what really matter to me).
I don't want to travel. I find planes immensely uncomfortable and telling the employer that I only fly first-class is usually not an option. I don't want to be stuck in a room with everyone from the company for a week or more while I miss everything that's going on at home, and like most company functions, skipping out on this also isn't really an option if one wants to remain politically viable.
One of the great things about remote work is that it takes a great deal of bullshit out of the employment process; you don't have to worry about if you're making the wrong facial contortions, if you're offending someone by slouching, if you look bored, or if you laugh hard enough at someone's bad attempt at a joke. The work is the focus.
There are few social signals to misinterpret or blow out of proportion. I think a remote-first culture is one of the best ways to secure a meritocratic working atmosphere, simply because it removes so much of the irrelevant noise, like personal charisma, that people misinterpret as being relevant to the performance of job duties.
Occasional company meetups only serve to dampen this focus on actual working output. I prefer to keep a professional emotional distance from my co-workers, generally speaking, which I think is for the best. If we really hit it off, there's no reason we can't arrange our own meetups, but for most colleagues, we develop a strong sense of professional respect for one another and that's plenty sufficient. No need to mess that up with personal elements.
I understand that these company meetups may be great if you're looking for companionship, but I don't really think a lonely person is well suited to remote work anyway. At home, I have a wife and several children to hang out with, plus a few close friends and a group of loose associates from hacker meetups, community functions, and/or church.
This is a turn-off for me as a full-time remote worker. When I browse remote job listings, a lot of companies list this like it's a perk. Maybe it's a perk if you're a 23-year-old single guy, but it's not a perk for me; it actually flies in the face of why I'm a remote worker, which is that I want to focus on my work with minimal interference on the other components of my life (which are what really matter to me).
I don't want to travel. I find planes immensely uncomfortable and telling the employer that I only fly first-class is usually not an option. I don't want to be stuck in a room with everyone from the company for a week or more while I miss everything that's going on at home, and like most company functions, skipping out on this also isn't really an option if one wants to remain politically viable.
One of the great things about remote work is that it takes a great deal of bullshit out of the employment process; you don't have to worry about if you're making the wrong facial contortions, if you're offending someone by slouching, if you look bored, or if you laugh hard enough at someone's bad attempt at a joke. The work is the focus.
There are few social signals to misinterpret or blow out of proportion. I think a remote-first culture is one of the best ways to secure a meritocratic working atmosphere, simply because it removes so much of the irrelevant noise, like personal charisma, that people misinterpret as being relevant to the performance of job duties.
Occasional company meetups only serve to dampen this focus on actual working output. I prefer to keep a professional emotional distance from my co-workers, generally speaking, which I think is for the best. If we really hit it off, there's no reason we can't arrange our own meetups, but for most colleagues, we develop a strong sense of professional respect for one another and that's plenty sufficient. No need to mess that up with personal elements.
I understand that these company meetups may be great if you're looking for companionship, but I don't really think a lonely person is well suited to remote work anyway. At home, I have a wife and several children to hang out with, plus a few close friends and a group of loose associates from hacker meetups, community functions, and/or church.
2-4 times a year is not really asking for much out of anyone. The fact is that relationships and trust especially can fray after a long time without actually meeting with people (most of the time, you may be a special case). Its a lot harder to know what a person has been actually doing and working on without a little bit of occasional face time - you may be in a very special situation where there are almost no benefits to actually knowing your colleagues better than what you can say over IRC, but for me its always been very helpful to get a good feel for who is on the other end of the keyboard, which becomes super useful for collaberations.
>2-4 times a year is not really asking for much out of anyone.
Sure, I agree it's not "asking much" relative to the requirement of a lot of employers that you be in the office every day. That doesn't mean it's something to advertise as if it were a perk.
>Its a lot harder to know what a person has been actually doing and working on without a little bit of occasional face time
I don't get this. You only find out what your remote colleagues are working on 2-4 times a year when you have a company retreat?
>but for me its always been very helpful to get a good feel for who is on the other end of the keyboard, which becomes super useful for collaberations.
Yeah, I just don't see this either. I think I collaborate fine with my colleagues. I think the focus on work-related things that occurs in IRC makes it easier to respect one another professionally. It's not the best medium for some things, but it's a great medium for collaborating on a work-related issue, especially issues that require the sharing of logs or lines of code; it's a lot easier to send the message in Slack and collaborate that way than trying to do it in person and cram around one guy's computer.
Sure, I agree it's not "asking much" relative to the requirement of a lot of employers that you be in the office every day. That doesn't mean it's something to advertise as if it were a perk.
>Its a lot harder to know what a person has been actually doing and working on without a little bit of occasional face time
I don't get this. You only find out what your remote colleagues are working on 2-4 times a year when you have a company retreat?
>but for me its always been very helpful to get a good feel for who is on the other end of the keyboard, which becomes super useful for collaberations.
Yeah, I just don't see this either. I think I collaborate fine with my colleagues. I think the focus on work-related things that occurs in IRC makes it easier to respect one another professionally. It's not the best medium for some things, but it's a great medium for collaborating on a work-related issue, especially issues that require the sharing of logs or lines of code; it's a lot easier to send the message in Slack and collaborate that way than trying to do it in person and cram around one guy's computer.
True, work things are generally fine over the wire. I've found that even in a professional relationship it's nice and even advantageous to know whats going on with your coworkers!
> One of the great things about remote work is that it takes a great deal of bullshit out of the employment process; you don't have to worry about if you're making the wrong facial contortions, if you're offending someone by slouching, if you look bored, or if you laugh hard enough at someone's bad attempt at a joke. The work is the focus.
all this still happens on the phone, and in chat, and in ticket updates. little textual mannerisms, passive aggressive bullshit, inappropriate comments, inattentiveness, over-attentiveness, obsessive compulsive typing habits, deliberately ignoring stuff, the list goes on and on. and video chat is its own can of worms.
but you're just better at that particular game, so you prefer it. you spent 6 paragraphs rationalizing it, but really, you just prefer one pile of shit to another.
other people don't have that limitation, we can operate in person just fine.
all this still happens on the phone, and in chat, and in ticket updates. little textual mannerisms, passive aggressive bullshit, inappropriate comments, inattentiveness, over-attentiveness, obsessive compulsive typing habits, deliberately ignoring stuff, the list goes on and on. and video chat is its own can of worms.
but you're just better at that particular game, so you prefer it. you spent 6 paragraphs rationalizing it, but really, you just prefer one pile of shit to another.
other people don't have that limitation, we can operate in person just fine.
Nah, it's a lot less intense on IRC solely because there is a lot less data to read bad information out of. Paranoid people will always find something to be paranoid about, but there's a much smaller attack surface, and "Sorry, it must have come across wrong via text" is a pretty good catch-all excuse if anything goes awry.
I disagree that it's about being better at operating in one context or the other. It's about minimizing the issues. I've managed people in face-to-face work settings and over IM/email/whatever text-based. People generate far fewer petty grievances over a text-based medium, at least fewer grievances that they're willing to air, and it shouldn't be difficult to see why that's the case (there's very little non-work activity to get offended or suspicious about). It works much more smoothly in general, unless you have people that just can't read (which are plentiful).
I disagree that it's about being better at operating in one context or the other. It's about minimizing the issues. I've managed people in face-to-face work settings and over IM/email/whatever text-based. People generate far fewer petty grievances over a text-based medium, at least fewer grievances that they're willing to air, and it shouldn't be difficult to see why that's the case (there's very little non-work activity to get offended or suspicious about). It works much more smoothly in general, unless you have people that just can't read (which are plentiful).
"nah" is a perfect example of what i'm talking about. a tiny little passive aggressive textual slight that would go unnoticed by most, but allows you to exercise a smidgeon of that petty vindictiveness you are so incapable of dealing with (or delivering correctly, i suspect...) in person.
What I'm taking from this is "beachstartup aggressively reads hostile intent into text messaging, avoid textual interaction with this person". I've found that far fewer people perform this type of aggressive misreading over text than over face-to-face stuck-in-a-room-with-you-for-40-hours-a-week interaction, that's all I'm saying.
I'm certainly not opposed to a video call or face-to-face meeting when it's the easiest way to clear things up. We're talking about the best mode for daily work interaction here, not the best mode for touchy-feely "make this guy like me again" interaction.
I'm certainly not opposed to a video call or face-to-face meeting when it's the easiest way to clear things up. We're talking about the best mode for daily work interaction here, not the best mode for touchy-feely "make this guy like me again" interaction.
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.
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).
- 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).
That's a great point. When onsite people start/try working from home they start paying more attention to the small things that make remote actually work.
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.
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.
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.
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!
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!
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.
Not all companies will be open to this idea, and the ones that are may have some criteria eg: how far into your career you are (for instance new/junior devs are less likely to be going fully remote).
Picking the right motivation will help, "I can't be bothered coming into the office everyday" won't work but "I'm wanting to move away from the city for X/to do Y" gives you a good reason to be asking about it. If you truly feel like remote is for you, you'll have to present the case at some point to your boss, even if informally at first. If they are against the idea, you can start looking for a new, remote, job.
Picking the right motivation will help, "I can't be bothered coming into the office everyday" won't work but "I'm wanting to move away from the city for X/to do Y" gives you a good reason to be asking about it. If you truly feel like remote is for you, you'll have to present the case at some point to your boss, even if informally at first. If they are against the idea, you can start looking for a new, remote, job.
I got recently promoted to Senior, have a bit more than 5y of experience.
My main motivation is to be able to save on two hours commute, which I think can be beneficial for both parts. I would be able to start early and without the commute hassle, and same on time/money as well.
I think my major problem is due to having a short team, and company concern about having a fair Dev representation in the office.
Did your company assist with the local office, or is that on your own dime? I have an opportunity for a full-time remote position, and I was considering a similar setup.
I'ma contractor (long term) and I have other clients, so it's on my own dime, but it is also a tax write-off. I couldn't go back to working from home again. I did that for 7 years and I nearly went bonkers.
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.
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.
++ 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).
> [...] and are continuing to grow our remote staff Internationally
You wouldn't happen to be looking for a Linux sysadmin / Java dev from Romania, would you?
You wouldn't happen to be looking for a Linux sysadmin / Java dev from Romania, would you?
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...
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.
http://www.hanselman.com/blog/CategoryView.aspx?category=Rem...
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.
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.
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.
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.
I assume the latter - but it sounds like a very nice way to do things.
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.
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.
> Then you just have to worry about communication. But the onus of communication is on the remote worker, IMO.
As a remote worker, I'm glad that you brought this up. I think that the communication must be good on both sides. That being said, I think that remote workers have already much better communication skills than "local" workers. It should be the duty of the local team to pass on the information about what they do. I faced the situation when the whole "local" team went to a meeting not saying a single word. It was very disappointing for two reasons: I didn't feel like a part of the team and I didn't know what happened. We slowly developed good communication practices.
As a remote worker, I'm glad that you brought this up. I think that the communication must be good on both sides. That being said, I think that remote workers have already much better communication skills than "local" workers. It should be the duty of the local team to pass on the information about what they do. I faced the situation when the whole "local" team went to a meeting not saying a single word. It was very disappointing for two reasons: I didn't feel like a part of the team and I didn't know what happened. We slowly developed good communication practices.
Yeah, that's a good point. If you don't know what's going on at the office, you may waste a bunch of time doing something that's been done, or is not needed. My point was to focus on remote work integrating in the context of writing code, and let it evolve.
> 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.
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.
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.
I have been managing remote devs for 4 years and now running 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 . 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.
#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 . 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.
Do you also work with single remote devs, or just teams?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> mimic the actual whiteboard
What do you currently use? I'm looking for a smooth way to do the same thing.
What do you currently use? I'm looking for a smooth way to do the same thing.
I could see something like a Surface Pro or iPad Pro being useful for white boarding.
> Find team building activities that can be conducted via video-conference.
What kinds of things have your tried? or would recommend?
What kinds of things have your tried? or would recommend?
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.
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.
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)?
Maybe it's important to distinguish "remote" working from "flexible hours" working. Maybe people would be more accepting of remote if it wasn't also perceived as unreliably available.
Not that there's anything wrong with flexible hours. I'm just thinking it should be a different conversation. In those cases it would make sense to me to have "mandatory times" where the video stream is active (meetings, team working, etc.) and other times when it's off.
In some cases flexible time is the only option that makes sense- I've worked with people from 6 to 12 time zones away, but never on a full-time basis.
Not that there's anything wrong with flexible hours. I'm just thinking it should be a different conversation. In those cases it would make sense to me to have "mandatory times" where the video stream is active (meetings, team working, etc.) and other times when it's off.
In some cases flexible time is the only option that makes sense- I've worked with people from 6 to 12 time zones away, but never on a full-time basis.
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.
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.
What about being available on chat and being able to quickly do a video conf whenever needed?
That's interesting, but it takes away a lot of the advantages of working remotely. I would rather go to the office than working under this kind of surveillance.
Yes of course. I did it because my wife got job offer in a different city 6 hours drive away and I wanted to stay with her but still keep workin for my old company.
I keep meaning to try out https://perch.co/.
- 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
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.
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.
@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.
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. 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....
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/ (1238+ stars), which is the number one package that integrates Ruby on Rails with React via Webpack and NPM.
I'm Justin Gordon, the founder of ShakaCode, 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....
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/ (1238+ stars), which is the number one package that integrates Ruby on Rails with React via Webpack and NPM.
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).
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.
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.
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.
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.
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.
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.
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.
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.
"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.
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.
Sounds like you've had some bad experiences, but I would encourage you to not over generalize. For example, "Remote devs start to have mental health issues from the loneliness and lack of supervision in down times." is a bunch of BS.
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
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
Do you have a preferred sketching tool? One thing I've yet to figure out remote is a seemless whiteboard session.
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.
I find my boogie board works really well as an input device! I believe you can also set it up to transmit to a webpage.
I use the free edition of Autodesk's SketchBook pro, with a Wacom tablet. This is for teaching, not remote work.
Realtime Board is pretty good:
https://realtimeboard.com
We've used it a few times with good success.
We've used it a few times with good success.
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...
https://automattic.com/work-with-us/
https://automattic.com/work-with-us/
[deleted]
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.
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.
Make everyone work from chrome books....they will learn how to remote real quick even when they are in the office.
https://perch.co/ is useful for us.