Comment by flappyeagle | Hacker News Reader

Comment by flappyeagle | Hacker News Reader

The era of remote work is not over. It’s just arrived. We overshot the equilibrium point by a lot during the pandemic height and that will regress back to something closer to long term trend.

No matter how much the HN crowd vociferously defends remote work, it’s simply an inferior mode of operation for many creative jobs.

People are not machines. We’re evolved to congregate and share space, to read body language, share meals, interact with zero latency.

Those things are valuable, and barring some huge leap in technology, we give them up when we go remote.

For some jobs and work cultures, those things don’t matter as much — those companies can self select into remote work and save on office costs.

But for American engineers especially, the more you encapsulate yourself into an interface of pull requests and slack messages, the more you’re handing power to corporations in the long run.

I can and have hired quality developers in EU, GB, and South America at heavily discounted rates because without an office, what’s the difference?

Even interviewing and managing people in Asia is much easier as a result of zoom, slack, figma, etc.

I find it so odd that American software engineers don’t see this. Time zone is not a moat, I promise you.

>We’re evolved to congregate and share space, to read body language, share meals, interact with zero latency.

On the other hand we didn't evolve to spend eight hours a day staring at a screen. Nor to spend two hours a day sat in a car commuting.

Supposedly a part of correcting an overshoot is possibly finding a hybrid.

>I can and have hired quality developers in EU, GB, and South America at heavily discounted rates because without an office, what’s the difference?

Great, you've confirmed remote work works and can produce high quality results without an office. You've failed to bring up the other challenges beyond timezone of hiring outside your country of incorporation, it's not just timezones that creates challenges, but even timezones and keeping global teams in sync has its overhead. If you're also going to hire globally, then it looks even more daft to have people go into an office to "collaborate" with people who are in bed on the other side of the world.

"Ability to sit in an office" should never be a bullet point on anyone's resume.

Maybe I wasn’t clear. Let me be more terse:

If you’re remote anyways, you won’t get the in person advantages so you might as well pay less.

In many cases, I would be happy to pay more for in person.

>If you’re remote anyways, you won’t get the in person advantages so you might as well pay less.

You are still ignoring that a remote-in-country employee is different than a remote-out-of-country employee from a legal, HR & logistical perspective. Hiring someone in Kentucky is not the same lift as hiring someone in Poland or India. There's going to be extra expense and overhead to manage out-of-country employees & the logistics of operations between different countries. Many companies aren't setup to do this. You can't just look at the pay rate.

Additionally you can't just look at the pay rate of an in-office employee. In office requires a commitment to pay for the office, pay for the staff to manage the office, accept a reduced talent pool in some areas, and if you're in an area with a large talent pool, it's probably a high-cost-of-living area, so your rate will not just need to be "a little more", but "a lot more" to be competitive.

> Time zone is not a moat, I promise you.

It may not be a moat, but it does serve as constant friction that adds latency. Sometimes you can plan your way so latency doesn't slow things down too much - but anything that requires operational coordination is going to be very difficult.

It may be difficult. It may be better in some cases. Around the clock pager support might be much easier. You can ship some features quicker by working on them around the clock. You only need 2-4 hours of overlap to cover the majority of meetings.

Good callouts, those are definitely situations where distributed time zones work better! Not sure about running 3 shifts to ship a new feature, but I have no experience in that area. What I am currently experiencing (working with half my team in the same tz, half is 10-12 hours off) is that it adds complexity. For example, when we coordinate handoffs between time zones, we have to be really explicit about dates and times. Delays tend to be more costly - instead of 1d delay, things become 2 if someone is out sick and doesn't deliver their critical path dependency.

It's a tradeoff, does require additional coordination and thinking things through. It's somewhat similar to remote work, tbh - it adds complexity but you also get benefits. Depending on each situation, the value added/cost parameters change.

Reply on news.ycombinator.com