Recruiting top software engineers may involve distributed development teams. Here are eight tips to ensure these remote teams are productive.
By Paul Rubens
Demand for top software engineering talent is going through the roof, which makes recruiting and keeping exceptional developers one of a CIO’s biggest challenges.. This is especially true if you happen to be in a location where you are competing for talent with a tech giant like Oracle or Google.
Paul Graham, a co-founder of seed capital firm Y Combinator, published a blog post stating following about developers: “The U.S. has less than 5 percent of the world’s population. Which means if the qualities that make someone a great programmer are evenly distributed, 95 percent of great programmers are born outside the U.S.”
Graham implores the powers-that-be to allow more exceptional programmers to migrate to the U.S. so the country can remain a technology superpower. Another possibility is for the government to issue more H-1B nonimmigrant visas allowing U.S. employers to temporarily employ foreign workers in specialty occupations. (There’s currently a cap of 65,000 on the number of people provided with H-1B status each year, although there are some exceptions to the cap.)
But there is an alternative solution to the shortage of exceptional developers. Why not hire the best people wherever they happen to be — in the middle of Nebraska, or in Mumbai, London or Sydney for that matter — and allow them to work remotely?
There can certainly be problems with this approach — for some companies, at least. For example, Google used to employ remote teams of developers around the world, but in 2009 it started consolidating them into larger centralized teams. “This move enables us to build larger and more effective teams, reduce communication overhead, and give engineers increased options for future projects,” Alan Eustace, senior vice president, engineering and research, said at the time.
But running productive distributed development teams is by no means impossible, as many other companies will testify. If it’s something you are considering, here are eight tips for success from people who have hands-on experience.
Put communication at the center of everything
“Good communication is incredibly important if you want to succeed,” says Matt Mullenweg, the original developer of WordPress and founder of Web development company Automattic. “If you do it right, the best distributed development teams can work better than ones that are colocated, allowing you to compete with the likes of Google and Oracle by doing something they can’t.”
So what is the right way for remote developers to communicate with teammates? Mullenweg warns against using email (“It’s not collaborative enough”) and has specific suggestions for communication tools that can help developers work together. He recommends using a WordPress theme called P2 instead of email, a platform called Slack for team messaging and Google Hangouts for holding developer team meetings.
Pick the right projects for remote development teams
Not every type of software project lends itself to development by a distributed team of developers, warns Naresh Jain, founder of the Agile Software Community of India. “If you need deep domain expertise and feedback from one business area, it is suboptimal to develop in a distributed fashion,” he says.
In software projects for banks or insurance companies, for example, you often need domain experts close by to ensure that the developers understand what is needed, he points out. “It is much better if domain experts can just go into a conference room and get the developers up to speed with current requirements, especially if three days later those requirements are likely to have changed.
“And if you are working in something specialized like medical insurance, you just can’t connect to it as a developer unless you have experience working in that environment,” he adds.
Hire developers who like to work remotely
This may sound obvious, but it’s important, Mullenweg says. “Everything starts with hiring. You need to filter out the people who are not productive in a distributed environment.”
He points out that many companies have people working in roles that are distributed — like journalists in a news organization or salespeople in almost any organization — and those people are used to working remotely. But while some developers are suited to working remotely, that doesn’t automatically mean all of them are.
“If you have a developer that likes to have a social life that revolves around your workplace, then working remotely won’t work for them,” Mullenweg says.
Meet up regularly
Communication tools can be effective, but it is very hard for remote teams that use them to simulate the “water cooler effect” of chance encounters and conversations with fellow developers, believes Avleen Vig, an operations engineer at online craft marketplace Etsy.
“We solve it by having people come in once a quarter,” he says. “Productive chance water cooler meetings don’t happen five times a day, but perhaps once every few weeks. We try to have all those moments in a short period of time when we meet.”
He explains that these quarterly meetings also help developers make social connections with each other and learn how they like to interact: in a serious way or a more informal way. “If you are not next to someone from time to time then that kind of thing can be hard to pick up,” says Vig.
Ensure project leaders can manage remote teams
A person who is otherwise a good manager won’t necessarily be good at managing a distributed team, Vig warns.
“When I worked in the office I used to have a one-on-one with my manager once a week for about 30 minutes,” he says. “Now that I work remotely, my manager calls me two or three times a week for about an hour. That may seem like a time sink but it isn’t, as we would have had more interactions in the hallway. The point is that now it takes longer for him to fill me in. Leaders need to learn new skills.”
Naresh Jain goes further, suggesting that it may not be necessary to have a permanent team leader at all. “Open source projects don’t have a central command and control structure,” he says. “Leaders emerge and disappear as needed — so with a distributed team you don’t have to have a dedicated leader.”
Beware of time zones, but take advantage of them, too
“Time zones can be a pain in the butt when dealing with distributed teams,” says Mullenweg. “We don’t try to put developers in the same place, but we do try to keep teams spread across no more than eight hours.”
Time differences greater than that can make working in a closely knit team difficult, he warns. But when you need to keep a team active 24/7/365, then having staff in different time zones around the world can actually be a big benefit, he adds. That’s because it’s always daytime somewhere, making it easier to fill night shifts in the U.S., and having team members in different countries also ensures that everyone is not off celebrating the same national or religious holiday.
Make remote working the default
Many distributed development teams have a core of developers working in an office as well as talent working remotely. If that’s the case, then Vig recommends treating every team member as a remote worker.
“You need to get everyone in the office to use email, instant messaging and other communication tools and discourage office-based developers from walking up to each other and having discussions,” he says. If office-based workers ignore group communication tools, then remote workers are excluded from conversations, breaking up the team dynamic, he explains.
Treat all communications as asynchronous
This last piece of advice from Vig is all about getting remote developers used to working by themselves. He says that communication tools can be effective, but somewhat of an adjustment for developers used to face-to-face conversations.
“You have to learn to trust that someone will get back to you if you send them a message. You can’t sit there waiting for an answer and feeling left out if you don’t get a reply immediately.”