3 ms·

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 ove

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.

klouczers 11y ago
> 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.
- euroclydon 11y ago
  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.
fishfacemcgee 11y ago
> But the onus of communication is on the remote worker, IMO. I may be misunderstanding you, but, if I'm not, I mostly disagree with this. Remote workers need to communicate well, but if all 12 local developers are in a shared office/working environment, then it's really easy to exclude the remote devs. If your remote devs are treated as second-class citizens (intentionally or otherwise), they'll never be integrated in your team. Lots of things you get "for free" with local teammates (as far as communication, camaraderie, etc.) you have to be more deliberate about with remote ones. Part of the benefit of being remote is the ability to be even more self-driven than you are when you're in an office. That shouldn't come at the cost of being left out of the loop and/or not being included in discussions that you could contribute to. This may not work for everyone, but the way we do things where I work is we use remote-focused communication (chat, video conferencing, Wikis, etc.) as our primary communication. We try to limit any in-office conversation to the relatively trivial or the extremely time-sensitive. However, the way our company is distributed, most of our team leads, internal stakeholders, etc. aren't local, which helps "enforce" that mindset. As far as specific tech solutions here's what we use: HipChat Zoom (video conferencing) GitHub Confluence + Jira Jell (distributed/asynchronous standups) At the end of the day, the tools make remote working possible, but the mindset we approach remote working with is what makes it viable.
- euroclydon 11y ago
  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.

klouczers 11y ago

> 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.

euroclydon 11y ago
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.

fishfacemcgee 11y ago

> But the onus of communication is on the remote worker, IMO. I may be misunderstanding you, but, if I'm not, I mostly disagree with this. Remote workers need to communicate well, but if all 12 local developers are in a shared office/working environment, then it's really easy to exclude the remote devs. If your remote devs are treated as second-class citizens (intentionally or otherwise), they'll never be integrated in your team. Lots of things you get "for free" with local teammates (as far as communication, camaraderie, etc.) you have to be more deliberate about with remote ones. Part of the benefit of being remote is the ability to be even more self-driven than you are when you're in an office. That shouldn't come at the cost of being left out of the loop and/or not being included in discussions that you could contribute to. This may not work for everyone, but the way we do things where I work is we use remote-focused communication (chat, video conferencing, Wikis, etc.) as our primary communication. We try to limit any in-office conversation to the relatively trivial or the extremely time-sensitive. However, the way our company is distributed, most of our team leads, internal stakeholders, etc. aren't local, which helps "enforce" that mindset. As far as specific tech solutions here's what we use: HipChat Zoom (video conferencing) GitHub Confluence + Jira Jell (distributed/asynchronous standups) At the end of the day, the tools make remote working possible, but the mindset we approach remote working with is what makes it viable.

euroclydon 11y ago
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.