I like to classify the general team types with regards to remote teams into two dimensions; project based teams and transaction based teams.
Project based teams This is actually a team that has a specific and time-bound benefit from the job that requires to get done. A project brief at the minimum should contain the anticipated final result, the various competencies required to achieve the outcome, the functions each of those competencies play, the timelines and the milestones. Additionally, it is important to possess gantt charting or project management software that you can use to determine your “critical path” to execution and ensure you are on track day-to-day. Two good choices in this case are Wrike and Asana. Asana is lacking in gantt charting but, it can be a terrific way to handle project tasks daily.
It is advisable to have a document to make note of time defined targets which are associated with the smooth execution of a project. They should clearly mention qualitative and quantitative indicators that portray exactly what must be delivered and at what quality level. A team member’s effectiveness can be analyzed based on the data achieved from this analysis.
Project based teams also need to have a document that conveys to them the best ways to execute a task. For instance, the execution guide of a software project should include the technical requirements of the project. This includes specific guidelines on how the code should be written, with what programming language and also how to make sure that one piece of the software inter operates with the other.
Transaction based teams
This is actually a team that works on a somewhat repetitive function, which may or may not have been tested in a conventional work environment. A good example of this is a Technical Support team. There is a technical product that needs to be supported, and although every single transaction might be completely different, the guardrails are essentially the same. In this instance, documentation is hardly ever a onetime thing. Documentation generally turns into a part of operating the remote team.
Transaction based teams benefit immensely from documentation like Best Practices (for handling a satisfactory transaction), Situation Based FAQs (if X occurs, you need to do Y and inform Z), System Walkthroughs (if certain systems are used to facilitate the operation, walk through documentation with screenshots, videos or demos are useful to have beforehand to help with training the team members on how to make use of them), Manuals, Troubleshooting Guides, Knowledge bases, 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 element of performance management on a transaction based team. The success profile for a role needs to include the essential transaction frequency and at what service levels time bound for the purpose of ‘ramping’ the team member. For example, the requirements of these in 30 days will probably be completely different than in 90+ days. This should be recorded in a success profile which should be provided to the team member to achieve desirable results.
The benefits are incredible, but it takes time and patience to build a successful remote team, especially if you are just starting out a new company. There are many factors to consider, some of these harboring risks, but when done right, you can cover great distances with people who you trust and who support you as well.
Source : Railscarma