Remote-First vs. Remote-Friendly
Yeah! We’re remote friendly! We got Bob who lives in San Diego, we’re based in San Francisco, and we have a Slack room, and people usually can come in to work at ANY time (between 8am and 9am), but really fuck Bob he’s kind of a loner and we’re going to probably let him go soon anyway, but yeah you can totes work remote!
We’re kind of in the surly teenager phase of remote work right now. A lot of companies are using tools like Slack, Hangouts, and GitLab, so our technical chops are heading in the right direction… but our processes and workflows still have a long way towards maturity.
Just because you happen to use chat rooms doesn’t mean you’ve suddenly become a glorious haven for remote workers, dammit.
Tools- and process-first
Look: to some extent, I don’t even really care if everyone on your team actually lives in the same city. That’s great — they could live on the same block for all I care. Maybe you chain them to their desks in some sort of twisted open office floor plan perversion, who knows. The point is that our tools have come a long way, but unless we adjust our processes, we won’t use those tools to their fullest extent.
I think there’s a split between being remote-friendly — hiring some workers in a different city — and remote-first, meaning you build your development team around a workflow that embraces the concepts of remote work, whether or not your employees are remote.
By forcing yourself to use chat instead of meetings, by forcing yourself to use chatops to mercilessly automate every single manual action, you end up creating things faster, with more built-in context, and greater ability to share your knowledge across the organization.
If you’re not working in a remote-first environment today, not only are you not going to have a remote-friendly environment tomorrow, but you’re going to eventually have a hard time retaining talent and keeping competitive pace in the future.
The world of work is changing. That’s just the way it is.
Other ways to not fuck up remote work
Assuming you are operating in a remote-first environment and you want to dip your toes into hiring some remote workers, here’s a couple pointers that you might want to keep in mind:
Geographical makeup of teams
The number one indicator of well-functioning remote teams inside of a company is a reinforcement of remote employees in the structure of the team itself.
In simpler words:
Teams with one or two remote employees on them are fucked, and teams with a larger proportion tend to do better.
I’ve seen this play out again and again across many different spectrums of companies. It seems to be such a clear indicator that if you’re the only remote employee on a team, I’d recommend you might be proactive and try moving to a different team entirely (unless the team itself is particularly adept at working in a remote-first environment).
I think the rationale behind this perspective makes sense, and I don’t think it’s inherently mean-spirited, either: if seven people are in the same room in San Francisco and someone else is in Singapore, the seven locals are naturally going to have more informal and formal conversations about the product, unless they go out of their way to move their conversation online. It’s doable, but it takes a dedicated team to do that.
If you’re going to have a go at fostering a strong remote culture in your company, try structuring a diverse representation of geographies on a team. If you don’t have enough of one or the other, aim for either all-remote or all-local teams… it’s better than having the odd person stuck as the de facto outcast.
Timezones, not just geography
Having remote workers is one thing, but having remote workers across timezones is another.
I’ve seen some companies proudly say their culture is remote, but their workers tend to line up between Seattle, Portland, and San Francisco, all in one timezone. Even if they’re stretched across the United States or Europe, that’s still only three or four hours across, and that’s close enough to enforce a culture of a “work day”.
Again, that’s fine if that’s the culture you’re looking to be. But if you’re really aiming for a remote-first culture, spreading your team across really varying timezones will force you to use tools differently. You’ll lean more heavily on email, chat, pull requests and other asynchronous work rather than relying upon meetings, daily standups, and power work luncheons.
Just like the aforementioned diversity of remote/local ratio splits on teams, try to enforce a split of timezones as well, where possible. Baking that into the structure of the team itself helps you stay remote-first by default.
Face time
Lastly, and very simply: you can’t be digital all the time. If you want to build a great remote environment, you need to front the dough to have some in-person face time from time to time. Fly people in, get them meeting each other in meatspace, and make things a little more human.
It’s amazing what you can accomplish in a two day trip. Creative problem solving becomes easier, people identify closer to real faces instead of just avatars, and all around it can be a great experience than sitting around computers all the time.
I’m pretty ecstatic that so many companies are getting better at remote work… I really am. When I first wrote How GitHub Works, a lot of this stuff was still a little amorphous at the time. Seeing the blistering growth of Slack and other tools over the last few years has been really lovely; I think people are really starting to get it.
But there’s always room to improve, of course! There really is a big gulf between being remote-friendly and being remote-first when you’re helping to build your culture, and it’s important to focus on ingraining these things into your process early and often.