Building Remote Teams (2) – Hiring

This post covers:

  • Things to do before hiring for your remote team
  • Approach to staffing. Employee or Contractor?
  • Finding the people

When it has been decided that building a remote team is a route to thread, the fundamental building block is the people that are going to be on the team, how to find them, how to get them on board and how to set them up for success. We talked about how the style of leading affects hiring choices on Building Remote Teams (1) – Leading. This is going to be our attempt to document exactly what we are looking to get done, find the kind of people we are looking for to get the work done and clarify what our expectations of them are.

Speaking about documenting, there are quite a few strategies that you could use depending on what you are building a remote team to do. I like to think of documentation as articulating a vision or function into specific and actionable explanations that the team member could pick up and understand-

  1. What the job that needs to be done is
  2. How it needs to be done
  3. Why it needs to be done and in the way suggested
  4. What the objectives or performance expectations are

How these actually translate into documentation depends on the type of team that is being built.

What type of remote team are you building and what type of documentation do you need in advance?

I like to categorize the general team types when it comes to remote teams into two dimensions; project based teams and transaction based teams.

Project based teams – This is a team that has a specific and time-bound outcome from the work that needs to get done. We could go into the intricacies of project management on this one but I’ll keep things basic for people working on small projects that don’t require a lot of pizzazz. Everyone on the team needs to have what I call a Project Brief.

A project brief at the very least should contain the expected outcome, the different competencies needed to achieve the outcome, the roles each of those competencies play, the timelines and the milestones. Also, it is important to have a gantt charting or project management software that you can use to ascertain your “critical path” to execution and ensure you are on track day-to-day. Two good options in this case are Wrike and Asana. Asana does not have gantt charting inbuilt but it could be a great way to manage project tasks day to day. What are the tasks that are dependent on others to ensure execution is timely? Who owns those tasks and how do we ensure the owners are aware that those tasks need to be prioritized above any other thing? The project brief should make it clear what role each team member plays, what their timelines and their milestones are.

Also, it helps to have a document called a Success Profile. The success profile should contain time defined objectives that are tied to the smooth execution of that project. They should clearly articulate qualitative and quantitative indicators that describe what needs to be delivered and at what quality level for a specific team member to be considered successful at playing their role on the team. Success profiles are typically composed to have staggered time restrained requirements depending on the type of project. For example, a success profile will define what a team member needs to accomplish or deliver in 30, 60, 90 days etc. to be considered successful. These things need to relate directly to the success of the project being undertaken.

Project based teams also need to have a document I would like to call an Execution Guide. This contains guidelines on how the team members need to execute their tasks to ensure that their eventual deliverable is usable and in line with the desired outcome of the project. For instance, the execution guide of a software project should include the tech requirements of the project. This includes specific instructions on how the code should be written, in what programming language and how to ensure one piece of the software interoperates with the other, or in the world of web 2.0, how it should interoperate with other external services.

Finally, the no brainer. A Job Description. This summarizes the character, attitudes, skills and competencies that you need in the person you are hiring to work on your team.

 

Transaction based teams – This is a team that works on a somewhat repetitive function that may or may not have been tested in a traditional work environment. An example is a Technical Support team. There is a technical product that needs to be supported, and even though each transaction might be different, the guardrails are basically the same. In this case, documentation is hardly ever a one time thing.Documentation basically becomes part of operating the remote team.

Transaction based teams benefit immensely from documentation like Best Practices (for handling a satisfactory transaction), Scenario Based FAQs (if X occurs, you need to do Y and inform Z), System Walkthroughs (if certain systems are used to facilitate the operation, walkthrough documentation with screenshots, videos or demos are helpful to have beforehand to help with training the team members on how to use them), Manuals, Troubleshooting Guides, Knowledgebases, Transaction Escalation Plans (who should be contacted when X occurs during an interaction, who has the answer when there seems to be no answer?) and Success Profiles.

Success profiles are an important part of performance management on a transaction based team. The success profile for a role should contain the required transaction frequency (in the case of a technical support or sales team for example, X interactions per hour) and at what service levels (X% customer satisfaction, Y net promoter score, Z customer effort score, XY conversion rate etc.) time bound for the purpose of ‘ramping’ the team member. For example, the requirements of them in 30 days will be different than in 90+ days. This should all be documented in a success profile that is provided to the team member before they are hired.

Finally, the no brainer here as well (the long awaited copy/paste). A Job Description. This summarizes the character, attitudes, skills and competencies that you need in the person you are hiring to work on your team.

Approach to Staffing

The next question usually comes in the form of; well, I have finally decided to build a remote team for my initiative, documented exactly what I need to get done, drafted a success profile and a job description. What next? How do I pay them? Should they be contractors or full time employees? How do I handle overseas team members? From the legal standpoint, I would advice that you speak to a lawyer to clarify what this means for your business. However, I find that recruiting people to work on your remote team is no different than finding people to work for you on your traditional team. There are portals like LinkedIn, Freelancer.com, oDesk, Guru.com, PeoplePerHour.com etc. that make it easy for you to find potential team members. After finding them, you can hire them as you would a full time employee or contractor that was working on site with you. I find that the approach of starting them off as contractors to test the waters and then transitioning them to full employees works well. That way, you have a chance to pull the plugs if you eventually determine that they are not a great fit for your team.

A great platform for managing payments and human resources with contractors regardless of where they are in the world is oDesk. Having used a lot of platforms as an employer and a contractor, they win my vote as they best platform to hire contractors through. They charge a 10% fee on your contractor’s pay but compared to all the headache they take out of the process of managing contractors, it is worth it. At the end of a year, they send the Form 1099-MISC to your contractors and you can add them as an agency expense on your accounts. They also have granular reporting that you can use to reconcile your books at the end of each accounting period. Finally, they allow you charge contractor fees to a credit card. Totally worth it in my opinion if your project or operation is not exactly revenue generating yet.

The next post will cover Operating remote teams. Have you read the first post in this series; Building Remote Teams (1) – Leading? It gives some context to this post. Ideas? Suggestions? Questions? Comment below.

Share your thoughts...