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?
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 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.
I never worked at a giant remote only company or old school Yahoo, so not sure how it scales there.
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.
Great function you wrote there that does the wrong thing because you were too busy to be bothered.
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.
I second the "remote-first" culture. Mixing on- and offsite developers is very hard.
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.
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.
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.
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'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.
- 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).
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.
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!
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.
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.
You wouldn't happen to be looking for a Linux sysadmin / Java dev from Romania, would you?
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.
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.
I assume the latter - but it sounds like a very nice way to do things.
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.
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:
Zoom (video conferencing)
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.
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.
#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.
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.
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.
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
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.
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.
What do you currently use? I'm looking for a smooth way to do the same thing.
What kinds of things have your tried? or would recommend?
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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
We've used it a few times with good success.
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.