This article is the third part of my extended series on boundaryless teams, remote-first companies, and the future of work. In my two previous installments, I talked about the changing dynamics in many tech-centric cities. I explained why authorities like Sam Altman of Y-Combinator, Angel List’s Naval Ravikant, Twitter CEO, Jack Dorsey, and Bill Gurley, GP at Benchmark Capital, believe boundaryless companies built by remote-distributed teams are the future of work.
In this post, I want to start getting specific. We’ll discuss the critical questions a CEO needs to answer to effectively capitalize on the remote labor market while avoiding the pitfalls most commonly encountered when people attempt to hire developers that are far from their company’s headquarters.
The Big Question: Why isn’t every company distributed today?
It wasn’t long ago that it made sense for companies, and especially Silicon Valley companies, to hire locally and have everyone working from one central location. The reasons for this were simple and clear:
- Developer talent was nearby and abundant.
- Real estate was relatively cheap.
- The tools required for effective remote work were either rudimentary or didn’t exist.
- Bandwidth sufficient for efficient communication was unavailable or prohibitively expensive.
Today, especially in tech hubs like Silicon Valley, Los Angeles, New York, or Seattle, none of these facts hold.
Instead, we see:
- Massive local competition from tech giants like Apple, Facebook, and Google absorbs a vast number of top-caliber local hires.
- Real estate costs in tech hubs have skyrocketed.
- Huge leaps in technology have made seamless communication with remote teams efficient and cost-effective.
- Global internet bandwidth has exponentially increased while costs have become radically lower.
In other words, the most compelling reasons for NOT relying on remote engineering talent to build software no longer apply.
So why aren’t more companies launching with a remote-first mindset? That is the million-dollar question, and it’s what I’m keen to talk about today.
The Challenge with Building a Boundaryless Company from Day One
In addition to the changes above that are driving a shift towards remote-first companies, investors are no longer skeptical of distributed teams. Investors that I’ve worked with in Silicon Valley have done a 180 when it comes to sourcing talent from around the globe.
In spite of these recent tailwinds, there are still some significant challenges that make it hard for a new company to “go remote” on day one.
From my perspective, four primary obstacles stand in the way of a company that wants to operate as a distributed team.
- Sourcing talent is hard.
- Vetting prospects is very hard.
- Onboarding new talent is crucial and a common point of failure.
- Managing distributed teams is not the same as managing a local team, and many managers are unprepared for this challenge.
First, is how do you find the right talent?
Finding talent is a big one. Hiring remote talent is much more complicated than hiring in your backyard. First, you cannot rely on a lot of the recruiting and hiring shortcuts that people are used to in Silicon Valley.
It’s simple to hire people when you can look for keywords on their resumes that you recognize as indicating high-quality talent — “Stanford,” “Berkeley,” “Google.”
Recognizable schools and recognizable companies make it a lot simpler to do the first pass when it comes to evaluating talent. It’s a strong and positive hiring signal when you can look for people who worked at Google, Facebook, Stripe — other well-known companies that have high-performing teams and stringent hiring standards.
But when you’re hiring from the global talent pool, you can’t rely on those shortcuts.
You also can’t rely on recruiters. Today, for hiring local talent, you can use AngelList, or you can use a recruiter yourself. But if you’re hiring from an African country (Nigeria, for example). If you’re recruiting out of Hungary, the signals you’d typically rely on to help you identify strong candidates probably don’t exist.
If you’re here, in the US — you probably don’t have any idea what Kosovo’s equivalent of Stanford is. Likewise, you probably have no idea what companies in Nigeria are analogous to Google.
Unbiased, credential-blind testing
The solution to a lot of these challenges is to have a credential-blind testing process that is bias-free. That way, if you can’t easily recognize the quality of a candidate’s education or their prior work experience, you still have an objective testing method that gives you strong candidates.
At my company, Turing, for example, we use AI to test for technical skills, communication skills, and fit for remote work.
In terms of technical expertise.
- We test for software engineering fundamentals, and we use technology-specific tests.
- We also use testing to help us determine if a person is capable of working as an individual contributor, or can they be a tech lead or an engineering manager as well?
What to Look for when Vetting Remote Engineers
Once you’ve managed to source prospects that match up with your skill requirements, you’re facing the next hurdle; vetting these candidates and determining if they’re ready for remote work.
Communication capabilities.
When vetting candidates, it’s vital to focus on communication skills. Many people think communication skill is a prospect’s ability to speak English. Although that’s crucial, proficient English alone is not sufficient.
When you’re working with somebody who works remotely, you need to understand how proactive that person will be in asking questions, clarifying ambiguity, and even pushing back against unrealistic deadlines.
Ability to evaluate a project.
As someone that has hired a large number of remote developers, I’ve learned that there are specific signals you can use to help you determine what level engineer you’re evaluating.
- Can this person handle discrete tasks efficiently?
- Can they take on a specific project and deliver it within the allotted time frame?
- Are they capable of leading a team?
- Can they lead the development of a complete product from scratch?
You must figure this out. It’s also challenging to do. Many people believe they’re more qualified than they are. One way I like to test this is during a technical interview.
Often, I will provide a project spec with some ambiguity. I will then ask the candidate to go over the specifications and allow them to ask me questions. What I’ve found is that there is one type of personality that might say “yes” without clarifying things.
These people will eventually get blocked by the uncertainty or make the wrong call. Judgment errors can slow you down or put your project off-track. Having several people that fall into this group can put your entire company in jeopardy.
You should look for engineers that can evaluate an ambiguous spec, and realize that this could mean either “A” or “B.”
The people you want to find will seek to understand what you mean. The better communicators for remote work will request more precision within their project details. Strong communicators might also push back against unrealistic deadlines.
We often include a challenging deadline when asking a prospect to review specifications. If an individual is unconcerned with the timing, we seek to understand three main points about them.
- Are they unusually effective?
- Are they unwilling to voice a potential problem?
- Or, are they naive to the demands within the spec?
Ability to understand realistic plans and deadlines – The Proactive Communicator.
It’s often challenging to know if a developer will be a proactive communicator, but this skill is also essential. Look for people that are quick to recognize when an obstacle is interfering with progress.
A passive communicator might fail to move with speed to resolve a problem that’s blocking their work. What you need from remote developers are people that will quickly escalate an issue to resolve it rather than staying stuck and losing time.
Why being a proactive communicator matters more with remote teams.
In an office setting, you have enough incidental contact with co-workers that a lot of clarifying communication exchanges can happen very easily, and the cost of the action is low. But when you’re using a distributed team, the communication bandwidth is narrower.
Someone that isn’t afraid to push for a quick resolution of a blocking, ambiguous, or confusing issue is going to be much better suited to moving projects forward while working remotely.
Onboarding
Nothing is as important as getting a newly hired developer started on the right foot. But you’d be mistaken if you think this is easy, simple, automatic, or always successful.
Unless you have a rigorous, well defined, and disciplined approach to onboarding new remote talent, you’re probably failing your new hire right from the beginning.
Many of the things that a local hire can either learn via osmosis or simply by asking someone in the office next door won’t happen with a remote start unless you establish a clear and consistent onboarding process.
When onboarding, I ask myself, “what does the developer need to know about the company? What does the company need to know about the developer?”
The key questions you should ask and then answer with a remote hire.
- Is there a company-wide context your new hire needs to know?
- What is the company’s mission?
- What are the company’s global OKRs?
- What is the company plan for the quarter?
- The year?
- Have you introduced the new hire to the corporate organization chart?
Then ask:
- Do they understand the lines of reporting and whom they should go to address a particular question or problem?
- Is it clear to the new hire who everyone is, what team they’re on, and what their inputs do?
- Is it clear to the developer which teams are related to her projects?
- Who are the managers for the project?
- What are the main contributions expected of the different teams?
Someone working locally might be able to figure a lot of this out by themselves or learn spontaneously during regular interactions with co-workers. But this isn’t possible for someone remote.
If you don’t convey all this information upfront, you’re setting your new hire up for failure.
In addition to having a specific protocol for communicating all these details, we typically assign a buddy or a mentor for the first two months. Having someone specific, a new developer can go to for answers can dramatically reduce problems, blockers, and frustration.
Make sure your new hire becomes familiar with the company structure and culture.
We also believe that having a defined manager and weekly one-on-one sessions goes a long way towards ensuring onboarding success. We find that not only does this radically reduce failed matches, but it helps both the manager and the new hire grow on the job and in their careers.
Another thing we’ve discovered is that time-zone overlap is critical.
We won’t hire a developer or secure a placement for an engineer unless there’s a minimum of four hours of working time overlap. People may think it doesn’t matter, but you don’t have people in your office at two am interfacing with co-workers because it’s not efficient. The same is true when people are remote.
Some people think you have to sacrifice efficiency when your company goes Boundaryless.
But this doesn’t have to be true. What is true is that you have to have a disciplined approach to each aspect of company management when your team is largely distributed.
Speaking of management
Managing a boundaryless company is a complex topic.
In my next posts, I’m going to dive into how we manage our team at Turing, and share some of the coachings we provide to our clients to help guarantee their remote hires perform as well as the ones right down the hall.
