Say you’re starting a startup. Should you go remote? It’s not a binary choice. There’s a spectrum of options you need to pick from:
Best Option: Hire In The Same City
There’s no substitute for collaborating in person, whether pair programming, helping someone debug something, brainstorming at a whiteboard, and so on. Remote work adds an extra layer of overhead, despite what remote-first cheerleaders like Basecamp say.
Working with people is also social. We also friendship and trust with people we work with in person and go out to dinner with, more than we do with pixels on a screen. Building a startup is hard, and we need to feel that not just that we happen to be doing this right now, but that we are in it together, that we’re friends.
If you hire people in the same city, you can use remote collaboration tools when they’re the best solution for the problem, and meet locally when that’s the best solution. You don’t need to meet everyday. It’s the best of both worlds.
If I’m starting a startup, I’d hire only people in my city.
Second-best Option: Hire In The Same Country
This makes it easy to hop on a flight and visit, without having to deal with the hassles of international travel: getting a passport and visa, airport delays, currency conversion, long flights, and so on. You can ask the person to visit every month, which people located abroad may not accept.
Salary payments become easier. It’s easier to ship equipment like a laptop. Signing contracts become easier. You have a better idea of what a reasonable salary is in your country. Negotiation is easier. It’s easier to work and bond with people from your own culture. Dispute resolution is easier. One way to look at it is that running a startup is hard, and there’s no reason to make it harder.
Third-best Option: Hire In Similar Timezones
In this option, you hire people with half a day of timezone overlap. For a founder in India, that would be anywhere from Ireland (-5:30 from India) to Sydney (+4:30 from India). This covers all of Europe, Africa, Asia, and Australia.
If I hire someone from Sydney, I wouldn’t also hire someone from the UK, because those two people no longer have a half-day overlap.
With half a day of timezone overlap, you can get into a meeting spontaneously. After the meeting, you can work on what was discussed, and get back. You can have multiple such iterations in a day, which is almost as productive as working shoulder to shoulder.
Worst Option: Hire Even With a 12-hour gap
If you’re considering hiring someone with a 12-hour gap in timezones, don’t. Or insist that they change their timezone to have at least a one-hour overlap with the timezone of the head office. For example, I know people in the US Pacific timezone who stay up, late till 11 AM India time to work effectively with India. I start my work at 9:30 AM, so this works perfectly for me.
If they’re not a night owl, I’ll have to change my schedule to stay up till 10 AM Pacific time, so that we can coordinate from 9 to 10 AM Pacific time.
In either case, schedules need to be agreed upon before hiring . Everyone in the company should be okay with this, rather than feeling, “Why should we all change our schedules for one person in the wrong timezone?”
A meeting should be scheduled every working day in this common slot, which should be at least an hour. This time should be reserved for cross-timezone communication. Local meetings should be scheduled in a different time. That way, if you need to coordinate across timezones, it can be done in a day. As opposed to first having to message to ask for a meeting, taking a day for a response, and few more days to find the right time, which causes collaboration to break down.
 If you don’t have a one-hour daily overlap, the only way it works is in a bigger company, with a local team that’s responsible for one product or effort within the company that’s not closely linked to the rest. It should be like “Go execute this and come back in three weeks”, not like “Let’s work on this together”. The local team should have the ultimate decision-making ability on the project, held accountable only for outcomes.