There has been a massive shift in how we build tech companies. The old way of hiring top tier tech talent was to look for talent 20 miles from company HQ or to find talent willing to relocate. Assuming, of course, that personal preferences or H1B visas weren’t a non-starter. Now, remote, distributed teams are the way to build unicorns. Remote work is the future of work, and remote first is the new way to build companies.
The World has Changed
As software eats the world and every industry becomes a tech industry, demand for skilled engineers has skyrocketed. Local supply simply cannot keep up. As a result, it is more costly and challenging to start a tech company in the Bay Area than ever before. Retention rates are reduced, even for the very best companies.
Winners and Losers
Companies that have adapted to this shift are very successful.
More than 60% of the workforce at Github works remotely. And Stripe, with a current valuation north of $22 billion, just announced that their upcoming engineering hub will be fully remote. When asked why they’d build an entirely remote hub, Stripe CTO, David Singleton said, “We are doing this to tap into the 99.74% of engineers living outside the metro areas of our current offices.”
The case for making your company remote-first is even more evident if you have your headquarters in Silicon Valley.
If your business is building software — and today almost every company is a software company — engineering talent is oxygen. It’s tough to get enough to thrive if competitors like Facebook, Apple, Google, and well-funded startups are sucking it all out of the room. Companies that haven’t adapted will die.
Today, we’re fast approaching a stage where it’s financially irresponsible for founders and companies to ignore the benefits of remote work and distributed teams.
Why I Believe Every Start-Up Should be Remote First
Some of the world’s savviest investors agree that distributed teams are the future.
AngelList Founder Naval Ravikant says, “we’re going to see an era of everyone employing remote tech workers.” Bill Gurley of Benchmark Capital tweeted, “every company I know or work with inside Silicon Valley has a plan to hire engineers somewhere outside of [the] region.” And Sam Altman of Y-Combinator recently said that it’s no longer fiscally responsible for building a whole company in the Bay Area. I agree.
I’m not blind to the fact that remote-first companies can be challenging to create and challenging to operate.
As the CEO of a remote-first company that’s building a platform to make push-button hiring of remote engineers a reality, I’m understandably bullish on the future of remote-distributed teams.
My last company, Rover, would have failed had we not gone remote.
But it was a learning experience. In this series, my goal is to leverage what I learned and help you understand why it makes sense to build a remote-first company. I’ll also do my best to expose obstacles and pitfalls — so you can avoid them.
Remote Distributed is Smart; not Easy
Building a company using distributed teams isn’t easy.
Sourcing talent is hard when they’re outside your region. What’s the Stanford of Sao Paulo? How about the Harvard of Kosovo? If none of the schools or companies on a resume are familiar, how do you rapidly assess an applicant? Vetting remote talent is also hard.
How do you test for technical and communication skills when you can’t physically interview the applicant on-site? What else should be screened for in a remote developer who works from home? How do you ensure she’s proactive in her communication and working style?
These challenges are just the beginning. Once you’ve found someone great, you need to get them started and do it efficiently. The problem is that onboarding remote talent is tricky. It’s tough to get a new remote hire onboarded and up to speed quickly.
And management? Successfully managing remote-distributed engineering teams is really hard.
How do you make decisions? How do you enforce a shared sense of culture? How do you unblock developers? How do you communicate priorities? How do you run meetings? How do you conduct feedback and performance reviews? How do you replicate the magic of serendipitous water cooler interactions?
How do you create a sense of belonging? How do you ensure your remote team members aren’t second class citizens on your team? Managing remote teams requires unique management styles, processes, skills, and discipline. Not all managers are well-suited to run a remote development team.
The good news is that it’s easier than ever to build a successful company as a remote distributed team.
Tools that enable remote work are getting better all the time. Thanks to Slack, Zoom, Invision, and Github, as well as dozens of other technology companies, tasks that were extremely difficult in 2012 are simple today. We compiled a full category landscape for remote and distributed teams.
Tools are only half the story.
Remote first companies require more rigorous management processes, more comprehensive knowledge bases, better communication architecture, and a carefully designed organization structure to work effectively. Thanks to all of these working together in concert, our Senior Director of Engineering at Turing has 29 reports, almost all of whom work remotely!
The Biggest Category in the Future of Work Deserves a new Name
I believe remote work will be the single biggest category in the future of work.
I also think the terms such as “remote work” and “distributed teams” do the category a massive disservice because they signal the absence of something. Remote signals not local. Distributed signals not unified. These are not inherent benefits.
We need a new term that signals what the category uniquely offers.
For this reason that I prefer “Boundaryless teams.” Where you are born, or where you live shouldn’t limit your employment opportunities. And where your company is located shouldn’t limit who you can hire. Technology and human potential have no boundaries.
The Step-by-Step Guide to the Boundaryless Enterprise
On ReadWrite — over the next twelve months — we’ll dive into the best practices, resources, and tools to help you craft your own remote-first culture.
We’ll examine the challenges remote-first companies face, and we’ll talk about how to avoid big mistakes that can cost you time and money. We’ll pinpoint skills you’ll need to develop to manage a remote engineering workforce successfully. Finally, we’ll talk with leading figures in the Silicon Valley boundaryless ecosystem.
As we learned at my first company, Rover, building a company as a remote distributed team is daunting — but doable. I’m not going to promise that creating a remote-first culture is easy. But if you stick with me through this entire series, you’ll be better prepared to leverage the many benefits of building a boundaryless future for your company.
