Note: this is a long article because this is a complex topic. Assembling and managing remote teams is largely like assembling and managing local teams, but there are a few differences. Further, though hiring is pretty much the same, since most people have little formal background in how to conduct a proper hiring process, I go in-depth in how to do this in a solid fashion which will gain you the best employees. This will largely be explained via our process of consulting, but it's appropriate for internal use, too.

I was living in Paris a few years ago and I was contacted by an old friend living in Brighton, England. Despite exhaustive searching, his company couldn't find any local developers experienced with Perl, nor could they find any developers both willing to learn Perl and work on their old, creaky codebase. After a bit of discussion, it was pretty clear what the issues were and what needed to be done to fix them. I've done this enough that I'm practically genetically engineered for this role and I was contacted because of my deep experience in this area. So when I received the news that they hired a junior programmer with no Perl experience and who failed their language-agnostic programming test, I was a bit surprised. He did, however, have a key qualification I lacked.

He was willing to sit in a chair in their offices for eight hours a day. I was telecommuting. Oh, and he was probably cheaper.

The situation went about as well as you would suspect and my friend eventually left the company when it was clear things weren't getting better. Apparently their junior developer couldn't redesign a decades-old codebase in a language he didn't know.

So why would a company make such a silly mistake? Fear. Developers often want to rewrite instead of refactor simply because they don't know how to rebuild a large code base. Similarly, management often says "no" to remote teams because they don't know how to manage one.

And I get it. Managing a remote team requires a subtly different skillset than managing a local team, especially for managing communication. However, once you learn how to build and manage a remote team, you have your pick of of some of the best talent on the planet. Think about having a team of top experts at your fingertips to build real value for your company. This is the real strength of remote teams and this is how you manage them.

Building a Remote Team

You can have the greatest management skills on the planet, but if you have an awful team, you're going to struggle.

Hiring well is the most important thing a company can do.

Every bad hire is flushing money down the toilet. Every bad hire takes the place of the person you really wanted. Every bad hire distracts other employees as they have to pick up the slack. Every bad hire tells other employees "management doesn't understand."

And so it's worth repeating: hiring well is the most important thing a company can do.

That said, we have to identify what you're looking for. What you want in a remote team is what you want in a local team: a team that can respond to your needs and cares about success. In fact, most of what I say here will apply to local teams. Our consulting firm, All Around the World , has a complete hiring process that focuses on both hard (technical) and soft (interpersonal) skills.

Hiring

Our hiring process is in three phases:

1. CV (résumé) review
2. Technical test
3. Structured interview

The CV

Many would-be employees get upset that HR departments often use software to filter based on keywords and phrases, but after years of hiring, sometimes in recruiting for other companies, I understand why HR firms do that. We don't use such software, instead choosing to hand-review every CV. But honestly, CVs are often worthless. First, many people lie on their CVs . In fact, as I've seen on a number of reports, this number appears to be increasing in the past few years. Other CVs are terribly dull, but have great minds behind them.

Thus, many experienced HR people will tell you: just use the CV to screen out the obviously unqualified. You need someone with a Java+Hibernate background? Ignore CVs that don't have Java on them. You can probably ignore CVs that don't have Hibernate on them. Make sure your CV lists the core hard skills you really need and if that's not on the CV, ignore it. It's amazing how many CVs we filter this way.

Also looks for duration of their experience. If you need top talent, don't go with someone who used your core technology on a three-month side project.

And because CVs are almost useless, that's pretty much all I have to say.

The Technical Test

After we filter the CVs, we then offer candidates a chance to take our technical test. A technical test must not be Trivial Pursuit! Yes, I happen to know what the $" and $^V variables are for in Perl. I can never remember what the $< or $> variables are for. That's OK, because if trivia is what you're asking about, you'll get trivial employees. Instead, you're looking for people who can think clearly about your problem domain. For example, when we're hiring backend software developers, our technical test is a small program we ask them to write, using a CSV file we provide. It might look roughly like this:

Write web-based software that allows someone to upload the included CSV file and saves the data into an SQLite database. Assume more CSV files in a similar format will be uploaded later. Create reports that show ...

There are a few other things, but we give the candidates a week to complete the test and send us the results. To make sure the test is fair, I take it myself. The above version of the test took me about two hours to complete the first draft. Again, candidates get a week to do this and we don't send them the test until they say they have the time to complete it.

And here's our secret sauce: we tell the candidate that they should return something they consider "production ready", but we don't tell them what "production ready" means. Thus, instead of writing to meet our needs, they tend to show us what they think "production ready" means.

For us, we're looking for well-structured code, with tests and documentation. We're looking for a properly normalized database . We're going to see if you noticed the data quality issues in the CSV file. We're going to see if your code is vulnerable to injection attacks. We're going to see if you've used appropriate modules. In short, we check many things. and we use a checklist to track our findings. We usually won't fail you for missing just a couple of items, but very few developers pass this test.

And in return? The developers get a full code review, including references of where they can read more information about those areas on which they were weak. I've been amazed at how many developers we turn down who thank us for that code review. Many of them have never had one before!

The Structured Interview

The final part of our individual hiring process is the structured interview. Very few people make it this far and this is the part where most hiring processes break down. Most interviews are worthless. From the article:

Countless studies show that the unstructured 30-minute interview is virtually worthless as a predictor of long-term performance by any criteria that have been examined. You have only slightly more chance of choosing the better of two employees after a half-hour interview as you would by flipping a coin.

You may as well just chuck half your CVs in the bin and say "I don't hire unlucky people."

The alternative is the structured interview. Here's a choice quote from a meta-analsis of 200 articles and books spanning 80 years :

In the 80-year history of published research on employment interviewing (dating back to Scott, 1915), few conclusions have been more widely supported than the idea that structuring the interview enhances reliability and validity.

The analysis is quite in-depth, but it becomes clear that we go from the unstructured interview—well-proven to be almost worthless—to the structured interview—a powerful hiring tool that does an excellent job of helping you select the candidates who will actually be a great fit.

They actually take a fair amount of time and effort to create, conduct, and evaluate, but here's the short version.

First, the interview is primarily about assessing soft skills which are harder to teach, though we do throw in some technical questions to cover potential gaps in the technical test, based on particular client needs. So you take stock of what you really need for a candidate to succeed. Our company, All Around The World starts by interviewing the client to find out their work environment. Are there tight deadlines? Do you need to work directly with customers? Do you have to communicate with non-technical stakeholders? Have you worked with remote developers before? And so on ...

From there, we assemble a list of open-ended questions that help us to better understand how the candidate's background fits. For example, in a fast-paced environment, the candidate might find themselves dealing with tight deadlines, so we might ask a question like "tell us about a time when you had a tight deadline and you were concerned you might not be able to deliver on time." And then you apply STARR.

Situation

Describe the problem you faced.

Task

Describe your role in addressing the problem.

Action

What did you do to address the situation?

Result

What was the end result?

Reflection

Is there anything you would have done differently?

By asking every candidate the same question in the same order, and ensuring you have covered all of the points of STARR for every question (and taking careful notes the entire time!), we get a thorough and relatively unbiased view of the candidate's abilities in relation to the client's needs.

You want to have at least two interviewers for every candidate and immediately after you're done with the interview, you score the candidate (we use 1 to 5) for how well they meet the client's needs for each question. And then you just add up the points. It works amazing well and produces stellar candidates.

A few points about structured interviews are worth noting. First, they're not often used simply because most people have never heard of them. Second, as previously mentioned, they're a time-consuming hiring process, but it's worth taking more time up front to avoid getting a "dud" employee. Third, candidates sometimes find it stressful to have you drilling into each question in such extreme detail, so be aware of that.

People Skills

Please note that throughout the entire hiring process, you're looking for people with good people skills. A destructive personality wrecks teams. I don't care how good they are, if they're a jerk, they ruin things for everyone. They need to communicate easily, be friendly, challenge without arguing, and generally be pleasant to be around. Don't hire toxic employees.

Managing a Remote Team

Now that you know how we hire individuals, how do you create a remote team? This is where really knowing what needs to be done shines. You need people with different, but complementary skills. Some people might be brilliant at front-end while others are brilliant at backend. You might have someone who can see all possible complications and design a system which can handle all of them, but have another person who's good at simplifying designs and applying the "YAGNI" (You Aren't Gonna Need It) principle ruthlessly. Another person might be very skilled at building tools which just make life easier for other developers (we like a devops person embedded in the teams directly). By having a wide variety of skills, you get more well-rounded solutions and higher quality work.

These are people who can put their ego aside and have the willingness to work together to provide the best solution. And because they have diverse skill sets, they learn to trust one another when someone else is addressing an area of their expertise.

Important: creating a team with diverse skills is even more important for a remote team. Just because you client says they have a DBA or a DevOps engineer doesn't mean those people will have time for a new team. They have other things to do and they may not prioritize you as much as the friends they work with and know.

Supporting the Team

The absolute number one obstacle (and objection) to remote teams is communication. Sometimes that quick email someone dashed off misses key details about a particular task that needs to be done. Sometimes the employee gets finished waiting on a task and is asking around for work to do (but see my "Project Management in Three Numbers" article for a great way to work around that). And you can't just pop your head over the cubicle wall and say "hey, Sally, where in the code do we handle authorization?". So your role as a remote manager is to ensure that everyone always has the information they need.

This need for extra communication and working very hard on this communication seems challenging, but we've found that this makes our teams often more effective than local teams because sometimes local teams make assumptions about how things are, when our team can't afford to do that.

Communication Channels

One of the beautiful things about remote work is that you skip the office chatter, the constant interruptions, the need to beg IT services to let you use a different editor, and so on. I often work with my terminal fullscreen so I can engage in deep work on heavily demanding tasks. But when I need to talk to someone about something, I need to have quick and easy to use communication channels. And email isn't one of them.

The tools you'll adopt will be different depending on your needs, but IRC, Slack, Zoom, Google Hangouts, and other tools will all be part of that arsenal. Whatever you do, ensure that you have at least one visual means of communication (but don't forget accessibility requirements your team members may have). It's great to ask a quick question on Slack about which hashing algorithm you should use, but nothing beats a quick Google Hangout session for quickly discussing complicated topics.

Listening

Agile fans like the term servant leader because it makes it clear that management is there to support the team getting things done. Managing remote teams reinforces this. When your team needs you, they need you. Yes, you're setting goals, providing direction, and often serve as the voice of the business, but when Oliver says "I can't get QA to test my branch," then you follow up and make it happen because Oliver's job isn't fighting with QA. When the team says there's a problem, your job is to clearly identify what's wrong and get it sorted. This is much like the ScrumMaster role of removing any and all blocks for your team.

Sometimes management can seem distant or not paying attention—they often are juggling multiple things at once and this can be distracting. Managing remote teams cannot be like this. Especially when you have your daily "stand up" (scare quote explained later), you must be focused and care what your team is doing.

Politics

One issue I've seen about remote teams is that they have a particular sensitivity to office politics. This may seem counter-intuitive because your team members aren't standing around the office coffee machine, complaining that Martin isn't doing his job; they're working. The problem is that they're often anonymous to other teams. You need to build bridges to the other teams and bridges aren't supported at only one end.

When different groups have different priorities and there are limited resources (as there always are), it's very easy for local teams to have the "we were here first" attitude. Or maybe your remote team needs a new database provisioned, but the people responsible for it don't know who you are and, more importantly, have other things they need to do.

Your job is to fix this, but it's a delicate task. Yes, you can often go to senior management and say the work you've contracted to do is stalled because other teams aren't cooperating. And, especially if you're on a critical project, senior management will sometimes respond by stepping on the foreheads of those who aren't helping you.

This exchanges a short-term problem for a long-term one.

Senior management doesn't want to step in every time you're struggling and this can leave the impression that you can't solve things for yourself. As anonymity is a classic driver of politics—you're not human to them until you meet them—fix that and other problems will be much easier.

Get to know the other teams and managers, paying special attention to those you'll be working with. When you have stand-ups, invite representatives of other teams to your Zoom meeting. If they have remote meetings, offer to be present, explaining you'd like to learn more, or offer help if need be. When they need your support, give it to them, too. Are they struggling to figure out why their PostgreSQL database is running slowly and you happen to have a PostgreSQL guru on hand? Offer that support if you can. People don't want to help if they view it as a one-way street.

You are a helpful, friendly, rising tide that lifts all boats. Helping one another and making sure everyone knows one another helps to minimize politics quite a bit. But they'll still be there. No matter how important your work, the work you're not doing is important too. Some other manager might think you're the greatest thing since sliced bread, but she has a tight deadline and no, the bug your team identified won't get fixed by the next release.

That's a realistic position, but it gets called "politics." When you let your team know the bug can't be fixed right now, you're supportive of your team, but of your client, too. If the team insists on the full story, tell them the truth, but tell it from the standpoint of the manager who denied the request. "She would love to help, but she doesn't have the resources to fix this before the next release."

By doing this, you show support for everyone. You're like Tom Hanks as Captain John H. Miller in "Saving Private Ryan": you don't grumble or complain. You support. You build bridges to others and you shield your team from the mess. They will learn to trust you, they'll reserve their complaints for critical issues, and they'll have fewer distractions from their work.

Answer Questions Before They're Asked

This is one of the hardest skills to develop, but it goes a long way to ensuring you have a great team. Often your team will say things like "we tried to extract the data but we can't because the API appears to be inconsistent." If your answer is "I'll find out immediately what's going on", that's great, but it means your team is blocked until you come back with more information.

A better answer is to realize they're dealing with an external resource and find out who's an expert you can call on right away. Then your answer is "Damien knows the best about that system and he can provide you with documentation and answer your questions."

Curiously, non-technical managers are sometimes better at this. A technical manager might have some experience configuring SNMP for Cisco routers and in a meeting, might not realize that SNMPv2 is insecure and SNMPv3 is more secure. The manager may not know anything about the NETCONF alternative and be unaware that the suggested polling solution doesn't scale with SNMP.

Thus, a technical manager might gloss over details, thinking they understand (this is not a given, of course), while the experienced non-technical manager learns to swallow their pride and ask why there's a mixture of SNMPv2, SNMPv3, and NETCONF solutions being used. Your job is to listen and listen hard and if you must leave a meeting with unanswered questions, you have a list of them and will immediately start tracking them down. Don't make assumptions that "they'll figure this out" because as a manager, your job is to ensure that you have the answers and the information flows freely.

This also means not shying away from the pain of a late-night session reading through documentation and checking it against your notes to ensure that you haven't made bad assumptions. You're not providing solutions, your team is, but you are there to guide them and you can't if you're not able to address their questions immediately.

Remember: one of the greatest obstacles facing remote teams is the communication flow.

Daily "Stand Ups"

The daily stand-up is our biggest change from traditional management techniques, particularly agile ones.

The name "stand-up" comes from the idea that if you're all standing up and some team members are starting to lean, the conversation has gone on too long. Thus, stand-ups are often time-boxed to 15 minutes. This does not work as well with remote teams.

The idea of a standup is to have every team member answer three short questions:

1. What did I do yesterday?
2. What will I do today?
3. What blockers do I have?

We've found that the 15 minute time-box doesn't work as well with our "complete communication" style. The reason is simple. When everyone's in the same room and someone's explaining a technical problem at length, you often hear the ScrumMaster say "let's take that offline" because it's disrupting the flow of the meeting. Except with remote teams, there's no "offline." You can't turn to the person next to you and say "hey, let's talk about that problem I had." Even if you do, you're not fully sharing the information because not everyone hears about it.

And if someone identifies a blocker, you address it in the stand-up, you don't "take it offline." Everyone on your team needs to know you're there for them if they're waiting on a code review, if they can't figure out what MyCompany::Catalyst::Role::RewritePaths does, or they have a test failure they can't figure out. Ask for solutions, discuss the issue, have someone volunteer to look at their code. And if you must, assign someone to review their pull request. Someone might grumble that they're being taken away for a code review, but they know their code will be reviewed in a timely fashion too.

We've found that our stand-ups tend to run about 45 minutes to an hour. Every day. That takes more time, but when you have a good team, they absorb more information. Even if they don't remember all of the details about why you changed your connection pooling software, when it's discussed more in-depth, they're more likely to remember that it was done and know who to talk to when they encounter difficulties with it.

We also use stand-ups as a time for chatting and socializing. This is not the norm, but it's easy to feel isolated when working remotely and this gives the team a chance to bond, to share stories, and laugh. All work and no play ... well, you know the rest. Being part of a team of friends, and not just co-workers, is important. When I go to conferences, our employees and contractors are often there and we take them out to dinner and share war stories. It's great to build loyalty, but more importantly, it's the right thing to do.

Note that this suggests a change in your hiring strategy. If candidates on your Google Hangout are getting fidgety towards the end of a long interview, that might be a warning sign (or maybe they have another appointment). If you mention your stand-up approach to candidates and they immediately react with "stand-ups should not last more than fifteen minutes", that's another warning sign that agile has become dogma to them rather than a set of guidelines. You're looking for candidates who are willing to communicate well. That means both being able to explain themselves clearly and to listen attentively.

Building the Product

Just taking a work specification and working through the bullet points is a common recipe for disaster for remote teams. Instead, you have to build value; the software just comes with the territory.

Understanding the Company

When we're brought in to a company to help with an issue and have hired our team, we work hard to understand the business of the company and the problem they're facing. And then there are other concerns which might impact our solution. Do we have to address PCI-compliance? Is the company impacted by GDPR? Does the company have restrictions on the types of software they allow? And what's the full stack they have available and are we allowed to offer alternatives, if necessary? Building a real-time reporting system with heavy writes using a MySQL database using MyISAM tables requires a substantially different architecture than Oracle 12c.

Once we have that information and can share it with the team, the hard work begins.

The Architecture

As I've written before, the later in a project that a bug is found, the more expensive it is to fix. It's easy to fix a leaky sink; it's disastrous to realize your foundation can't support the weight of your house.

So we start with a careful evaluation of the problem, the kinds of data we're working with, and the resources we have at our disposal. Then we discuss possible solutions to the problem, with the entire team and their diverse skills contributing in their various areas of expertise. If possible, it's great to have a senior person from the company on hand who has deep experience with the codebase and company and can offer invaluable advice in driving the architecture.

If the problem is small, this might be a short meeting. If it's large, this might be a series of meetings. Regardless of the approach, the client must be able to review the architecture and offer appropriate feedback before signing off.

After hiring well, a strong architecture and review is the best thing you can do to reduce bugs and control costs.

Note that unlike code reviews, architecture reviews happen before implementation.

Code Reviews

After the architecture is approved, the implementation begins. How the work is organized depends on your management style, though I confess that I'm a fan of WildAgile and the three-number business case. Once a team member has a task, they might discuss it briefly to clarify the requirements, and when they're done working on it, they submit it for a code review.

After hiring and architecture, this is the third most important thing in assuring code quality. Even if your code works perfectly and your tests are passing, tests are not enough. Tests generally don't know when a public method should be private. Tests often can't point out that you forgot to test edge cases or that you missed a race condition. And tests certainly can't tell you that your technically correct code and documentation is nonetheless incomprehensible.

Thus, code reviews. When we do code reviews, we're checking that the code is correct, that it's understandable, that it's documented and that it has appropriate tests. More than half of all of our pull requests are sent back for more work, but that's normal for a team that is heavily focused on quality. The larger the pull request, the more likely it is to have some issues.

The combination of a thorough understanding of the problem domain, careful work on architecture, and deep code reviews means that when issues do arise in the software, or a change of requirements occurs, there are seldom systemic issues. This reduces the up-front cost of development and tremendously reduces maintenance costs.

Our Values

When working remotely, it's essential that the people you are working with share the same values. We work hard to find people who excel, are proud of their work, but can put aside their ego and focus on the client's needs.

For us, the value is to be able to help, to take the client to another level. We are putting our talent at the service of the client to support their growth. We are not there for billable hours. We are there for delivering; for supporting.

Whether you choose us or choose to develop your own remote team, following these guidelines will give you a superb team that can do things with software you never had the chance to do before.