Hacker News new | ask | show | jobs
by bzbarsky 1961 days ago
There are a lot of assumptions going into that implication. My experience with working remotely, on globally distributed teams, for about 20 years now is:

* Synchronous high-bandwidth communication (read: meeting, ideally with a shared whiteboard) is pretty handy sometimes.

* Timezones really do matter. If you want a sync meeting that includes people in Europe, the US, and APAC, someone will have a bad time. If you want quick turnaround on code reviews, having 8-12 hour time zone differences is a significant barrier. Even a "4-hour" difference for meeting time purposes can be a huge problem in this sense: it's 9pm on Thursday where you are (US West coast), but your coworkers' weekend has started (in New Zealand), so any code reviews you ask for on Friday morning you won't see until you get back to work on Monday. And any code reviews they ask for on their Monday morning won't happen until you get back to work on their Tuesday.

* Language matters. Even if everyone involved speaks English to some extent, it's a _lot_ easier to follow some accents than others, especially on an imperfect (read: teleconference) audio feed. Which accents depends on which people.

* Shared context matters, just in terms of understanding requirements. This can be developed, but it takes time. People from more similar backgrounds often require less time to get to mutual understanding around this sort of thing. This needs to be weighed against blinkered thinking and lack of diversity in perspectives, of course.

I love working remotely, and am used to the scheduling issues around this sort of thing, but there are a _lot_ of issues that come with hiring someone halfway across the globe that you don't get with hiring someone also working remotely but in the same city or at least speaking more or less your accent of your language and within an hour or two timezone distance. The fact that the latter works for a particular position does not imply the former will.

2 comments

I think companies also need to deal with the tax implications of someone working in another country. Not sure what impact that would have.
Yes, this can be a pain. There are some contracting companies that handle this for you, but that can involve hiring people in other countries as contractors, not employees, having an extra intermediary that handles their payroll and whose incentives in terms of quality service may not align with yours, etc, etc. Plus of course regulations about how long you can have people contracting for you before you have to hire hem as employees and whatnot.

Also, it's not just tax implications. There's also complexity about time off (vacation and leave regulations differ a lot across the globe), conditions under which people can or cannot be fired (or hired), differences in terms of non-salary benefits that must be provided, etc.

A simple example of the hiring/firing thing: under French law, if someone is on maternity leave you can't fire them. You also can't hire someone on an indefinite-term basis to do their job while they are on leave. Hiring someone for the specific term of the leave seems to be OK. See https://www.globalworkplaceinsider.com/2017/05/do-employees-... toward the end, though the whole article is a great illustration of some of the differences in this area between French and US law.

And then there are the fun parts about general regulatory compliance. As a simple example I've run into, the US _requires_ you to collect and report data about the race of your employees (see EEO-1), while the EU _forbids_ collecting this data to start with, last I checked. So you have to have distinct processes for employees in different jurisdictions, your HR database needs to handle these differences in rules, etc.

Most of these hurdles seem really unimportant compared to the salary savings
Kind of like making products out of crappier constituent parts seems really unimportant compared to the cost savings.

Does it make sense on the short term balance sheet? Of course. But, to quote Christmas vacation:

"Sometimes things look good on paper, but lose their luster when you see how it affects real folks. I guess a healthy bottom line doesn't mean much if to get it, you have to hurt the ones you depend on. It's people that make the difference. Little people like you."

This is assuming that programmers from countries with lower salaries are less competent, which is not always the case. It's harder and harder for workers in the developed world to justify that they are more productive than others. For millions of smart people around the world the hurdle to a better life is just the right visa or residence permit.
No, but what should be unequivalently true is:

* Longer distances with more variance in connection quality degrades meetings and shared whiteboarding

* Timezones can destroy productivity if you let them, and need managing to not be a hindrance. If you want to run a complicated bit of SQL past a DB admin first, but your DB admin is 5 hours ahead of you and finished work already, you pay the cost of context switching and picking it up again tomorrow.

* Even if everyone speaks English, having a dozen different dialects and accents in one meeting doesn't help with comprehension, even moreso on dodgy connections.

* Cultural differences can be managed, but if you've got people from half a dozen different cultures on your team, you're gonna hit differences, some very difficult to surmount. And this is magnified with the lack of body-language communication you'd get in person.

It depends. If you have to redo the work multiple times because of miscommunications, that can easily eat up salary savings. If you can't hire the best people because of some of the aggravations involved, you may get a worse quality product or it may take a lot more time than you planned, or both.

Again, hiring someone remotely in the way you describe might well make a lot of sense. But it's not nearly the no-brainer you paint it as.