HN Explorer

Ask HN: How do you deal with offshore developers?

6 points by s-stude ↗ HN
Looking for some insights on what is good and what's bad in having an offshore development team. Does anyone have an experience?

What may go wrong? What is good, except the cost?

How do you manage a team? How do you hire them? Any challenges?

Will appreciate any help.

9 comments

[ 2.2 ms ] story [ 41.4 ms ] thread
kwikiel
https://sivers.org/how2hire

This covers most of it. I would focus on giving some small pieces of work to see how collaboration works.

s-stude
Good post on how to hire somebody. I'm more interested in an experience on how it was. If you have a team which works for you several months you see some challenges. Which are they?
dbg31415
Same as an on shore dev team; document every requirement as best I can, ask them if they have questions, get them to repeat my requirements back to me so I know we are on the same page, set up regular meeting times and regular work schedules, check in and hold people accountable to what they commit to... and budget time to do code reviews and QA before launch.
s-stude
Do you think a time zone will be an issue?

What else scares you?

dbg31415
Time zones don't scare me. But I do tend to get up early, like 5 AM in the US, and that tends to work well with people in Europe.

As long as everyone has some sort of calendar scheduling tool, with their normal work hours clearly listed, it's usually not too hard to schedule meetings and chat with people on Slack -- doesn't have to be real time chat.

grizzles
I used to run a labor hire company. I still do in a way (consulting), but at a lower volume. I've managed many offshore developers and other contractors. Because the skill continuum is massive, it took me several failed engagements and a long time to get really good at managing people across it. Nowadays, I can't remember the last time I had an unsuccessful project encounter.

There are at least a hundred valuable tips I could give you on how to be a great remote manager but if I had to give one, it would be this:

Be a mastermind. Remember first and foremost that variance is your enemy. Give detailed requirements. Hide information to keep your contractor focused. Avoid abstract directives like the plague. Instead, break off an atomic well-defined piece of work and give it to your remote worker to work on over a short time frame. Either do the integration engineering yourself or give that to a highly trusted, proven lieutenant. Iterate.

To summarize, until a relationship is well developed, imo micromanagement is basically correct.

s-stude
Great advice, grizzles. With all "remote work" trend those insights are becoming more and more important.

Question for you - have you met remote teams versus solo developers? Do you think there might be a team which had an experience in being remote and may save while we are doing our baby steps?

Pointer2
Highly defined work packages, short time scales, regular reviews.
jarnix
It has been a good experience in my company (web publishing, so we make a lot of websites).

> We talk/chat a lot with them, as if they were in the same place.

> Cut tasks to smaller pieces to minimize the risks

What may go wrong:

- bad understanding of the tasks, that's why we communicate more

> and we always allow a little more time (than usual) for every task just in case something was misinterpreted and needs refactoring

> people located "offshore" hire them according to our requirements (English language is a must-have anyway, even if we're French)