1. Sourcing & vetting candidates? 2. Managing international payroll? 3. Bootcamps? 4. Infrastructure & working space?
Let me know your thoughts!
I'd add that this culture-setting rolls down from management -- if they aren't setting a good example, others will falter and the remote-supporting culture will fall apart.
Things like payroll, taxes, infrastructure are all solvable today, IMO, with the right resources or tools.
As someone who works at HQ for a local-first company with a significant contingent of remote workers in two satellite offices, it's _exhausting_ to be the developer in the corning who has to say "can we make sure the remote guys can hear OK" or "got a ping from Dan, remote guys aren't getting sound" in every single meeting.
Our office infra guy got a microphone with a padded box around it that you can toss around during the full company meetings so remote people can hear audience questions. The execs talking at these meetings have never once said "hey make sure we pass around the mic," it is always someone sending a text onto the big presentation hangout screen from a remote office saying "can you repeat the questions too please?" while the mic sits there on the little table right fucking next to the main speaker every single time.
When the managers and leadership don't care enough to prioritize it, it's almost impossible to change the culture around supporting remote team members.
Biggest challenges?
Communications - I think every company has this problem but if you don't solve it when you are remote it will crush the company eventually. Whereas an office company can be shitty at communications and still do ok.
Execution... - LOL, I feel silly saying this but if your devs are split all over it is hard to collaborate, esp depending on speed and size. You need really great organization, focus, and just the right amount of meetings. You also need to do that in a way that gives them the ability to write code without checking in with someone every 10 min or stepping on toes. Esp if you are crossing big time zones, you have to really think and plan who is working on what, and it might even affect the entire design of the app...
quick background - grew a 100% company to ~135 people in 18 countries. Mix of software and dev ops and customer service.
I'm sure there are some special circumstances where being the only remote worker on a team works out ok, but my experience has been horrible.
I'm interested in this, as a person who does remote work, and has experienced some of these issues.
So, what are some good remote-first companies? I know of a few that may be: Automattic, Scrapinghub. What others? Asking all here, not just the parent commenter.
Maybe this should become a separate thread. Note: Obvious, but: "remote-first companies" is not necessarily the same as "companies that are hiring for remote positions".
https://basecamp.com/books/remote
As for your actual question, I don't yet know of a great resource for understanding which companies are truly remote-first, but would love it if someone had one to share.
Some people feel really insecure without an office, deep inside they think it isn't a "serious business" unless you own real estate in a "serious" postcode. I don't know if it's just an European thing but it's definitely an attitude I've encountered.
In IT, tbh, I think we should just own it. There are more productive and creative ways to send out that sort of signal.
But, then the marketing/sales part of my experience chimes in and I think of all the various times in my career that having physical space added to my credibility. I think of the sectors (government tech and financial tech instantly come to mind) where decisions makers are heavily moved by AAA office space. And, I think of how many times I've seen spending an obscene amount on rent actually convert into paying customers.
My inner developer is saying "right on" but my inner marketer/sales type is thinking of all these times when physical space has a positive ROI from a sales/marketing point of view.
I think it's even harder for companies that have open open offices or are doing Agile. Those two things usually mean the companies are explicitly stressing in-person collaboration. In-person communication isn't a bad thing by itself, but I think that explicitly valuing in-person communication ends up making remote work harder.
It is really hard for established companies, full of many different humans with their habits, to shift from shouting across the room to some sort of distributed, async, communication.
Arguably, one of Ubuntu / Canonical's failings.
The Debian - Canonical distinction is milder, though the latter has at least some centralisation. Nowhere near as much RH's.
These are two areas where good solutions may exist at reasonable price-points, but if so that information isn't widely known.
Not sure if it fits with your business model, but it would be extremely helpful for someone to carefully evaluate the effectiveness of various technologies / products / services for those areas, and provide recipes for known-good setups.
I.e., if one of your clients can tell you their current and upcoming team sizes, network connectivities, etc., you can tell them what products and services give them good video / whiteboard quality at various price points.
IME companies with remote workers tend to be "penny wise, pound foolish" regarding these things.
EDIT: To be more specific: For call quality, having good data on what setups result in good call quality in Skype vs. Slack vs. Google Hangouts etc. And for shared whiteboards, having good information on how effective / sufficient teams find various approaches such as (some website + iPads), (some website + a particular Wacom tablet), (everyone on the team having a particular model of interactive whiteboard such as this one [0]), etc.
[0] https://www.cdwg.com/product/SMART-Board-6075-75in-LED-displ...
But no software can fix variances in bandwidth or latency. I wish there was a way to test a remote hire's internet connection quality. Lack of access to a good internet connection would be a deal breaker for a remote hire for us.
One of the most useful parts of it was timing http requests and tracking response times. We solved some very complicated technical support issues using this tool. Do you think it would be useful to adapt something like this to remote workers? It's weird because I've struggled with internet connections when I've worked with remote workers, but never thought of actually testing it until I read this comment...
I suspect the reality is that, amongst the best-performing services, which one works best depends on network QoS details, network topology, particular client hardware / OS, etc.
For example: some conferencing software seems to have a real problem with echo cancelation, so either (a) everyone needs mic/speaker hardware that sidesteps the issue, or (b) you accept that everyone will go insane.
Similarly, difference conferencing software has different solutions to people talking over each other accidentally due to latency. One product (Cisco's maybe?) has an icon for metaphorically raising one's hand to request a turn speaking.
Doing it more seriously you might even want to use a separate older machine as a skype drone (ie only runs skype) and feed your audio out from your main machines sound card into that.
I had an initial phone call with a firm and it was obvious that they where clustered round a mac laptop - inaudible and very low quality sound.
Amen to that. I recently was interviewed remotely, and the voice call quality was unacceptably low- I could barely even understand the questions being asked!
Don't be discouraged. I checked out your site (and github) Looks nice. I'll use the tool next time I need remote collaboration
Keep up the good work.
Personally, I find the toughest part to be actually managing the people. You really need to trust your team to be self-motivating which can be tough for a manager to do, especially new ones, because you need to give up some control.
But even though you trust them you need to have a way to measure results. That means being more disciplined and mature in your project planning than you might be if everyone is co-located.
For a startup that is key. Startups often skimp on disciplined project management.
I also find it tougher to do things like say, identify when someone is having a rough time (personal or professional) and take steps to correct or accommodate for that. If a co-located employee starts underperforming but I can see they are clearly checked out (like their head is somewhere else) I might suspect there is something going on at home and adjust my management style with that person. If they are remote it is harder to tell those things. Communication becomes extremely important when body language / behavioral clues are lacking.
So to pile on a lot of the other answers here... communication, communication, communication.
I can recall several times where clearly (or so we thought) laid out plans were given over to have them come back a week later with some measure of misunderstanding. The 2 solutions to this have either been micromanaging the remote team, which is painful or time consuming -- or giving the team enough autonomy to work independently, which is risky.
In practice what this means is if you're based in the US, you can either focus on having teams in Europe or Asia, but not both.
Instead of just a requirements document, give them a requirements document but also define a set of red/green tests to show whether the requirements were met. It's hard to do this with front end, where feel is often very important, but in my experience, it works well provided that the remote team's manager is qualified to make the types of architectural decisions necessary to pull this off.
You can even start tying compensation into passing red/green tests!
I'm going to use this comment as a way to talk about remote hiring generally, rather than respond directly to your comments. I want to help others understand some of the challenges it has been being one of the larger (relatively) fully distributed companies.
I think there is a common misconception that the world is mostly flat and that our company can hire from anywhere. I am commonly criticized when tweeting job postings (almost always remote) when the countries we can hire from is limited to a select few. "Not real remote" "first world remote only" "remote != 8 countries" etc. are common criticisms.
Disclaimer for the remainder: I am not a lawyer and my exact details because of that may be wrong. Please consult your own legal team.
When hiring remote, there are a few things to keep in mind:
1.) You have to adhere to employment laws within the country you're hiring from. Employment laws vary widely between countries and getting them wrong can be very expensive. For example: vacation time will vary, holidays will vary, the ability to let someone go will vary, what you can/cannot expect from an employee varies. In one country, emailing an employee outside of work hours is legally considered harassment; when working with multiple timezones that's a challenge because "in work hours" for one country may be "out of work hours" for another country.
2.) To employ someone full time, many countries require you to have a legally entity within that country. Establishing a legal entity takes a lot of time and a lot of money.
In the past 12 months, we've had at least one member (more now) on our HR/finance teams establishing legal entities _full time_. I've had my signature on at least 8 incorporation documents in the past 6 months. By the way, most incorporation documents require a "wet" signature so if you're remote like we are, be prepared to be FedExing a lot of sensitive legal documents around.
Beyond just paperwork, there are often requirements to establish a legal entity: a real, physical, local address is one. In one country, we had to pay out of a local bank account in local currency (which has its own red tape), and this country also required we maintain a minimum balance to pay 3 months salary in the local account in local currency at all times. For a startup, that much cash "not working" can be problematic depending what stage you're at.
In one country we're establishing an entity in, the process just takes a LONG time. We've been responding to any inquiries and sending paperwork immediately and we're 8 months in and still probably 2 months away from completing the process. Meanwhile, we still can't legally hire there.
A lot of legal paperwork is understandable in the local language of where you're creating the entity. This means that you also have to pay lawyers fluent in that language to vet the paperwork. We employ full time lawyers, but primarily in English, so this requires us to go to expensive outside counsel.
Finally, this is all expensive. There are fees to creating entities but also recall that we have multiple full time employees that spend their entire day establishing legal entities. So we have our own full time salary costs plus filing costs plus legal costs.
3.) Hiring contractors DOES work around some issues, but has its own downsides. First, we can't offer options/stock to contractors and we'd like all our employees to benefit from this. Second, we often can extend the same full time benefits we want all our employees to share such as healthcare, 401K, etc. Put another way: we want all HashiCorp employees to be employees, we don't want to create second class citizens.
Legally, some countries have legal limits on the hours a contractor can work or length of time they can be contracted before they're considered an "employee" by default and regardless of what you SAY the relationship is, the country will consider it employment and points 1 and 2 above all take effect immediately.
So we certainly DO hire contractors but our point of view is that we intend to hire those people full time over time. We'll often hire contractors if we know that we'll have a legal entity established to hire them within X months, and we're up front with the new hire about this. We'll also pro-rate option/stock vesting for their contractor period when they are hired.
4.) We prioritize countries where we have the most interest. We get asked a lot "please hire in X" but if the number of times we've heard X is much lower than Y, then we'll prioritize Y first.
This creates somewhat of an imbalance, since more countries with a more established tech ecosystem generally have more qualified candidates and therefore get prioritized higher.
We WANT to hire from everywhere, but as a startup with constrained capital and timelines, we have to be pragmatic about choosing the locations where we'll probably be able to hire the most roles while we continue to expand our entities.
5.) We are also open to relocating employees into countries where we do have entities. We've done this multiple times, we pay a relocation fee, and its a great way to hire someone from a country where we can't [yet]. Also note they're "relocating" but are still working remote.
Of course, this is highly dependent on the individual and it is unfair of us to ask or force someone to do this if they have an established family, friend circle, and generally just a life in their existing country. So this only works some of the time!
6.) Despite building process around remote-first, we try to a keep a healthy timezone overlap in each of our teams (3 to 4 hours out of the working day is best). We find that teams that have a team member with a non-overlapping TZ struggle for multiple reasons. So, even though we can hire in many countries now, we'll restrict some job postings to certain countries so we can have that overlap.
EDIT, some additions:
7.) Each US state ALSO requires a legal entity in addition to adhering to state-local employment laws, taxes, and more. At this point HashiCorp has entities in ~30 US states.
Further, there is a tax consequence to the business outside of employment taxes. If you hire an employee in a state, you also now have to pay sales tax on revenue from there. You may argue for/against whether that makes sense, but for a startup this can be VERY expensive.
Our corporate tax obligation would be hundreds of thousands of dollars [less] if we didn't employ people in New York state. We've had to weigh this in cases because the tax obligation from hiring _one_ individual could suddenly be that you can't afford to hire _multiple_ other individuals.
Note we don't want to avoid taxes, that's not what we're doing. But startups are capital constrained and we have to determine long term how we continue to grow and hundreds of thousands of dollars can make a difference.
----------------------------------------------------
Finally, I want to note that we're 100% dedicated at HashiCorp to remaining fully remote. We WANT to hire from everywhere. We're establishing the entities and process to hire in new countries full time. 18 months ago we could only legally hire in 2 countries, today we can hire in 8. By the end of the year it should be at least 4 more. We'll continue from there.
I could write a LOT more about culture and process within the company. But this comment is already getting very long and I think I'll keep it to this. Maybe in the future I'll write more about "chat literacy", the importance of decision inclusion, things that definitely don't work, keeping people motivated/happy, managing people you can't physically see, the lack of body language for signaling, and a lot more.
I hope this helps someone!
We're a remote team but much smaller and certainly unable to pay a full time employee to create companies.
Do you have, or know where to find, a list of countries that can work without setting up a legal entity? We've lost a lot of time trying to recruit candidates where we've not been to find a workable solution due to local laws and our limited resources (e.g. in France!)
Learning about this stuff basically requires a huge time sink per country in reading local laws, as well as a cost of paying a lawyer to verify your assumptions. It is unfortunate. A "tldrlegal" site for entity creation and employment laws would be amazing.
Also re: France... yeah, that is a tough one. We're just about ready to hire there. The whole process was very difficult, on the harder end of the spectrum that we've experienced so far. :)
Can you elaborate on what is keeping you from offering options to contractors? Sure, incentive stock options can only be given to employees but what about nonqualified stock options? They can be given to anyone.
Whilst you can offer on approved schemes - you might have to offer people in the uk more options to cover this which might make local (US employees) jealous
Tax avoidance is perfectly legal and encouraged to maximize shareholder value. Tax evasion is illegal.
> First, we can't offer options/stock to contractors
Can you elaborate why?
Would you be able to share the actual countries in question? In which country was it required to open a bank account in the local currency? Which one has taken 10 months to complete opening an entity in?
I don't know for the specific case you've posed, but we've had similar things happen. If an employee moves into a state/country we can't employ them in, it causes a bit of a panic. We either have to 1.) establish the correct legal/financial entities to employ them or 2.) let them go. In theory, you can convert the employee into a contractor, but this has ramifications on options vesting and benefits and so on and is a huge mess. I'm sure there are a lot more caveats to this that are under consideration (again, I'm now a lawyer) that may affect this, so I wouldn't generalize this too far.
I don't think we've ever let someone go for this though, we have once to memory panicked and rushed to establish the entity (potentially paying fines along the way). I may be mistaken, I just don't recall exactly. In any case, we kindly ask our employees to notify us of any change of location, since it almost certainly changes payroll tax even if you are moving to a location we CAN employ in (i.e. even between US states). Also, the panicking is not fun for anyone (including the employee, whose job status is suddenly uncertain).
(If the spouse is working for the US military there are NATO agreements which might make German employment law inapplicable but I know almost nothing about that.)
Timezone is a tough one. For us, finding a scrum time that works for everyone (in a small team it's doable), and sticking to it daily helped to get the team to communicate more openly with each other, and stay in sync.
Finding the right set of tools to manage remote teams is one the biggest challenge when a team is distributed across the world. Traditional task management tools didn't lets us easily ideate, organize, and share task lists together, hence we were inspired to build Taskade (Disclaimer: I'm the co-founder of https://taskade.com). The idea of having the freedom to work together on task lists in real-time, see each other's progress, and collaborate without any distractions.
Communication! Communication! Communication!
If any part of your product requires people to communicate with each other, then the team members lying on vastly different time zones will have low efficiency because information round trip time will be larger than those of the local (or time zone near) ones.
Hiring is hard to begin with, and hiring remotely has additional pitfalls. A company like Triplebyte that would perform additional vetting to prove a candidate's ability to work remotely would be quite welcome.
Re 4. VC systems are still awful and both companies and employees aren't willing to invest to the right level, and commit to workflow changes, in order to make it seamless to work remotely. In particular, latency and packet loss is what just kills VC and makes it very apparent that we're not actually in the same room together. The way to solve that is gigabit home-office Internet connections, but $10k to run lines and an additional $500/month, as well as the hassle of using a wired connection at home to take advantage of it, and then a dedicated VC system, is a total non-starter for many, on both sides, employer, and employee.
Throw in a timezone difference, and the wrong remote employees can take more time to manage than they're worth. (That's not to say there aren't some really really good, really solid remote employees, just that there are also the wrong hires - same as goes for in-person.)
Re. 2. On top of payroll, there are also plain cultural differences between countries that make it more challenging than when there is no difference - holiday schedules, vacation policies, etc, and until you've lived it, it's hard to know what to look for in advance.
I have a US company and trying to build a remote team as "employees". Going crazy trying to figure out how to set this up other than the usual option of "pay them as freelancers and let them do their own taxes". Not everyone is cut out for that and not able to attract good talent.
We ultimately went with a company[4] that had a different model where they connect you with a local PEO in each market and present a common UI on top of all the disparate local PEOs so that you get a company that specializes in just that country, but a common UX no matter how many countries you work with.
I liked the model, and more importantly, it was a fixed fee and much less expensive, and they published pricing. Disclosure: We made the decision to go with them, but haven't started working with them yet.
[2] https://www.globalization-partners.com
- Which payroll companies, if any, will be the best solution for handling international (or even just inter-state within the U.S.) payroll / tax issues?
- What communications technologies and practices work best for various team geographies / network-connection-quality / local-hardware setups?
- What's the optimal frequency, duration, structure, etc. of whole-team face-to-face meetings for teams that are typically distributed?
- What management training is most helpful for managers of all-remote teams, or of teams where only some members are remote?
For example: At ($10k initially + $3k/year) per employee, you're likely to avoid problems A, B, and C, but still run into D and E occasionally, depending on team size, using recipe $FOO.
At ($20k initially + $10k/year) per employee, you avoid problems A-D, using recipe $BAR.
How people have problems every day with the conference software? If you do, buy a dumb hardware that you use only for conferences (I think a raspberry could work too?). Or join 2 minutes earlier than your meeting and run a sanity check.
Connection will drop once every 10 meetings, but so people will get distracted, or sick.
What could work quite well often is more challenging... Some things that have made it easier for me:
- Dedicated PeopleOps person - this person's job is only to make all the tools work together better for everyone. Jira, Slack, integrations, notifications. People should be able to open requests to remove remote friction of using multiple tools, etc.
- Start with real-time remote (everyone who works is awake at the same time) has gone a long way. Plus or minus 2-3 time zones, no more. That way, especially in the beginning, everyone is available to work at the same time.
- International payments, in the beginning, is easier to start as a contractor via a service that takes care of it like Upwork. Once you know you have a winning candidate, it's worth figuring out that new jurisdiction.
- Onboarding - should be collaborative, hanging out on slack. Make candidates join your infrastructure during the trial period to confirm that in fact, they can use your tools.
- Read - there are lots of companies building healthy online cultures. STudy and follow them.
- Weekly WOS video call - 1/2 hour every week for everyone to have 1-2 to minutes to share what they're working on.
- Run all meetings as if they were remote. Everything gets scheduled on hangout, etc, in case someone needs to hop on.
There's some good handbooks out there for remote working too that have been a treasure trove. If I can find a link I'll update this post.
- Solitude (at first it's not an issue) - Asynchronous communication. Learning to read and write effectively. - Team collaboration work (designing/brainstorming). It's very difficult to explain ideas through <insert name of video conference product>. To solve for this, GitHub allows employees to meet each other as long as there is a business need. On top of this, we hold summits very often, where the team gets to meet each other in a location for a week. - Internet and great conferencing hardware (GitHub provides a great budget for both Internet costs and hardware).
But I would say the most challenging part is Trust. Trust in your manager, trust in your organization, trust in your company, and trust in your peers. Without Trust, there is no way to build a remote friendly company. How are you going to micro manage someone who is working in EU while you are sleeping in the US? Obviously GitHub is not a perfect place, but I would say that there is a mutual understanding among employees to trust each other and to communicate effectively.
What do you mean by "allow". Is it, in general, not allowed for employees to meet each other in remote-first companies, but GitHub notably allows it? Or did you say it that way to emphasize they must meet only for business needs and not for anything else. If so, why? Would you be able elaborate on that sentence?
What are some examples of companies that have been successful using primarily remote workers? I don't mean companies that Hacker News considers do remote work "correctly". I mean companies who have grown to around the nine figure mark without a co-located team?
Trying to figure it out on your own is irresponsible at best, so it boils down to hiring a local CPA or tax attorney in each state/city you hire in to go over the implications of bringing someone on in that city.
If the person is right, it's worth the cost, but it's a large, unexpected time-suck.
Even when everything works perfectly, there is always a lag or a missed connection due to miscommunication or timezones.
In short, it always kinda sucks, is a drag to deal with even with the best tech and we just get more done with our in-house teams.
Remote workers don't build up any social capital and so are always the first to be laid off.
If the person in charge doesn't know what he's doing the rest doesn't matter.
Regarding your options:
1. Hardly any different than on site. 2. Not an issue at all. 3. Huh? 4. For some.
My recent experience left me a bit scarred.
There’s no solution as good as yelling across the room or walking past the desk. chat is a poor substitute for all the reasons everyone in this boat knows.
The best way to get this to work is like that one company did (saw it here on HN): have everyone in the company work remote for a week.
None of these are big problems. The biggest problem we have is communicating effectively with people in various time zones, and making them feel apart of the team. Video conferencing is still an area that is lacking in this area. I've yet to find a service that meets all our needs. Right now we are using LifeSize because it's the best we've found, and still fairly annoying.
The problem really isn't on the "hiring" end. It's how to work as effectively with remote people as you would with people in the same office. When you introduce friction with remote, it causes problems. That being said, I think it's a worthwhile problem to solve.
Not sure this helps, but this is our biggest struggle right now.
Think about it: the benefits of remote work go mainly to the employee, but the drawbacks (harder to communicate, harder to evaluate productivity) fall disproportionately on the manager. Since the manager is the one making the hiring decision, they don't hire remotes.
So to give a really broad answer, my suggestion would be "change the incentives so managers will hire more remote workers". That could mean internalizing costs of on-site workers, better communication tools, etc.
Joining a startup is different than a 9-5 commitment, it means joining a tribe/family. So if the office people leave for a 2-hour lunch before spending a late night in the office, how does a remote person "join" that? Being part of the family means you are there for the leisure as well as the work.
If you go international, then you are probably dealing with a legal system that is stacked against you. The government probably even intends to divert your trade secrets to fully domestic (relative to them) companies, and will apply pressure to "your" employees (who may even be government agents) to make it so.
And right now that means dealing with a terrible video conferencing experience and not having a good shared whiteboard solution.
If you could figure out a way to realistically replicate "a bunch of people around a whiteboard", then I will pay you money for your product.
Our set up has partly brought us to create ellyot.com that allows you to find inspiring workspaces globally and network with like minded people.
Reasons not to be here are the absolutely ludicrous cost of housing and what that does to salary requirements.
But as a tiny company, execution speed is our single most important attribute and we couldn't work out how to work remotely without damaging that. I'm glad github and others have managed, but you have to wonder if they succeeded despite being remote.
ps -- I've worked remotely before. It's really nice not to start every goddamn meeting screwing with hangouts doesn't connect / lifesize hardware works great but doesn't connect well to mixed hardware + laptop calls / multiple zoom invites with different meeting rooms / go2meeting clients are shitty / etc.
I've found the most difficult type of remote work is highly collaborative. Iterating on designs, on software, or ideas in general.
Anything that can aid in that type of remote work would be a boon
Startups and fast growing companies grow quickly and changes happen rapidly. If priorities are constantly changing and communication/the planning process isn't really robust you won't have remote people who are successful.
- International payroll: often impacts tax situation
- Adjusting to remote collaboration. e.g. no more walls of sticky notes; can no longer rely on water cooler conversations or "quick meetings"
- TimezonesProblems 1-4 only become real problems after the management team feels comfortable with:
5) How are we going to integrate them into our workflow and team?
"Hire remote workers" has become an extended and rebranded form of "offshoring". Folks learned some hard lessons from the offshoring days that you can't just hire remote. Your organizational thinking and processes need to be ready.
My take is, if you're solving 1-4, you're selling to companies who already have some remote workers. If you're focused on companies with few to 0 remote folks, you'll need something to help them solve 5.
Country B requires employers to register with tax authorities and deduct tax directly from the employee's salary.
Country C allows employees to buy childcare vouchers with their pre-tax salary.
Country D has a similar scheme, except for bicycles and it's a loan.
Country E considers private healthcare a taxable benefit-in-kind.
Country F has three different tax bands for employee stock options, depending on when they can be exercised.
Country G makes it mandatory to provide flexible working for new parents...
Of course in a lot of cases you can save on admin by being less tax-efficient, like by not participating in tax-efficient government incentive schemes.
The US has 300 some million people. India has a billion some.
If you can't find an employee in those two countries, it seems you have other problems? (or add 1 or 2 more if you want to spread it around).
Not that there are not great people in all countries. But opening your resume pool from say 1.5 billion people to 3 billion people is unlikely to have a huge benefit to hiring.
Remote work is asynchronous programming.
The great part of co-located work is that so much communication happens organically. If you need something, or have a question, the answer is a desk or two away. Processes can be ad-hoc and decided in the hallway or around the water cooler.
At the same time, that organic nature turns on a company once it gets bigger. The organic transfer of information takes time. In small organizations or teams that time is small, but as the organization or team grows, the more repetition is needed to propagate the same information in the system. Where you used to answer a question once, it's now once a week.
The reason is because the ease of organic communication prevented the organization from writing down it's tribal information. It took too much effort! But as the organization grew, that slow organic information transfer simply could not propagate tribal knowledge fast enough or redundant enough like writing it down. Remote work is essentially permanent async work, but you are also temporarily async at 3am and your servers are down. I hope your coworkers wrote the production debug steps down, or you are relying on your own memory. It also affects your new hires because they will have to enculture themselves to the information and organization.
Remote-first policies see that, eventually, all companies require async access to it's tribal knowledge. That's READMEs, Wikis, tickets, helper programs, the accounting department, etc. Realizing that all corporations are eventually remote (if only because you will spread to another city, office, or different floors), you spend the extra energy to build those tools so you can look up your tribal information at 3am on a Saturday morning after drinking. Those Wikis really help, yo!
It also adds a tremendous amount of visibility and accountability into what you do. You have visible documentation and visible communication. Tickets are filed for bugs, and others in a completely different office can check the status. My drunk self can read the production FAQ at 4am before the hangover sets in. The best part is you can hire remote workers, because your entire process supports that asynchronous access to information.
In many ways these asynchronous processes add a tremendous amount of value to your business, as well as offer the perk of hiring fully remote employees.
Why, given all of these benefits, would companies bother with co-location at all? Well, to borrow from Behavioral Economics, I'd say they are making an economically irrational choice to value the show of productivity over actual productivity. Management by visibility. I do think management types are incentivized to continue the show, rather than the substance, because their boss judges based on visibility rather than metrics. At the same time, the fixes are spelled out above since they add that visibility into processes (to an extent), but it takes a management that holds itself accountable.
For another stupid geeky metaphor, businesses are highly parallelized processes. A synchronous co-located organization has highly mutable information sources, it's employees. To get information in such a system, that it must acquire a mutex lock (interrupt the employee) to read information but it's faster for both people. A asynchronous organization, through it's explicit processes and documentation, allows for lock-free reads of information but requires more overhead on the individual processes as well as embracing some Eventual Consistency. In a small organization with few employees/threads and few interruptions/locks, co-location probably is fine. But as your employee/thread count increases, those locks and interruptions exponentially explode and your whole organization can grind to a halt in endless Slack questions and status updates: The Deadlock of Corporations.
If you are thinking about remote, consider tools that embrace asynchronous access. IMHO this means any software that requires both parties to participate at the same time is bad. I'm including Phone Calls, Slack, IRC, AIM, Email, Hangouts, and others like them. You should never have to ask "Did you see/read/notice my X?" as these tools encourage synchronous behaviors. These processes are the Interfaces of your Organization. They increase overhead but they pay dividends when your organization grows in headcount. The ability to hire remote is a perk at this point.
PS. We are hiring
For example, bots like http://tatsu.io or http://standuply.com help running standup meetings.
I think remote work will become more and more popular in the future despite its challenges.