Hacker News Reader

Comment by ericclemmons | Hacker News Reader

The problem I still can't seem to adequately solve is remote teams working entirely in sync with local teams.

For example, I need to hire an additional 2-4 JavaScript or PHP developers, but most of our team is in Houston, TX, which is not really a hot spot for these.

I already have some remote workers, but their projects tend to live more in isolation until the PR needs to be discussed, while the local team constantly works together, on their own accord, through the whole process.

How can this gap be bridged where remote and local can cohesively share the same projects without the "latency?"

View on HN

I've been working remotely from about 90mi outside of Austin (for folks in Austin, doing front-end work on top of PHP).

By being generally fast with email and generally quick/responsive I've gotten a lot of freelance work, so maybe it's just a general skills issue; it's not easy communicating certain things in email/phone/text/message and developing that as a skill takes a lot of work... it's totally subjective, but it feels that it's taken as much effort to learn when to reply to an email and when to sit on it for a half hour as it took when I first learned how to use jQuery.

IMO, this skill is made tougher to practice when the people I deal with are not also skilled at communicating; there is a lot of communication that I get remotely that takes a bit more decoding because whoever wrote it doesn't put a lot of thought into the communication.

I dunno what the good answer is; just saying "hire more experienced remote workers" sounds like a dumb answer...

No, that sounds a lot like exactly the right answer.

To promote remote working we need developers that can help and teach a company to handle remote work. Not people who will just whine about how companies suck because they don't offer remote work.

Remote working is a skill, on both sides. Most companies that would theoretically not be averse to remote workers don't have that skill and can't properly evaluate that skill in others, so the only alternative to a long period of trial and error is to hire developers with a proven track record.

Either that or wait for 37signal's book to come out...

It sounds like your process isn't handling them well, or you just aren't making them a real part of your team.

At my company, we have half our staff in Melbourne, Australia... and half spread out globally around many different time zones.

The remote workers are every bit a part of the team as the Melbourne workers.

I think adopting a more asynchronous workflow makes sense, both to include remote workers but also it can be very efficient (remove distractions).

A tool like Campfire to handle communication is really important too, anyone can log in and see what they missed and you don't need to be there at the same time to have a conversation.

Also, you need to trust them and give a lot of autonomy, it can't be managed in a traditional way.

I think the autonomy is where the problem likely stems from. Everyone handles their own tasks however they see fit, which leads to collaboration in the local office because of the ease in doing so.

Perhaps centralizing all communication in Campfire (or one of the recent "Show HN" posts) rather than our daily Skype call would help alleviate that...

If you're not factoring latency (<24hrs) into the equation you shouldn't be hiring remote workers.

It should be the assumption that goals should be on a weekly or >1 day basis for remote workers. Although scrum/sync ups can still happen daily.

Reply on news.ycombinator.com