A practical guide to building Remote Teams
Outsourcing isn’t necessarily cheaper and some of the horror stories you’ve heard might just be true. But in countless other cases it does work well for companies and teams, so what is the key to success?
For the last 10+ years, I’ve been involved with outsourcing projects for several companies throughout Europe. Having also lived in Romania for close to a year working for a Dutch agency at their local office, as well as currently working for the Poland-based agency Divante, I’ve seen both sides of outsourcing. And I can tell you from experience this seldom fails on a technical level, it’s often culture and communication.
This article is based on my personal experiences while working with remote teams. All views are my own as are the pictures, taken during visits to various teams, added to this article.
Getting started with a remote team
By invitation of Wouter Dieters, a fellow Remote Team and Outsourcing consultant, I ended up traveling to the south of the Netherlands to sit down with a Magento agency who were, like nearly every other agency in the Netherlands, having issues with hiring developers. This agency started to look into outsourcing as a way to handle the ever-increasing workload. Their question; “Would this work for us, and if so… how?”
I’ll use what we discussed in the meeting as the thread for the rest of the article.
Shifting the company culture
Hiring a remote team starts with preparing the company for a cultural shift. Assuming we’re talking about an agency that is operating from one main office, hiring a remote team is pretty much the same thing whether it be halfway across the world, near shore on the same continent, or the next town over;
- You can’t roll over to their desk for a chat
- They might have different habits or language
These two points are vastly underestimated while being able to make or break the entire project. Let’s start preparing for this.
Does your company offer remote working to the team? We’re not talking a day or two per week, more weeks or months on end. Assuming they have a laptop and wifi colleagues can work from just about anywhere.
Frequent reasons heard against remote work are amongst others; degrading communication over time, no internal processes to support this or a simple lack of trust they’ll work nine to five. And those can be valid points, but will also be a showstopper when working with an outsourced remote team.
Dogfood your processes
A first step to working with a remote team can be as simple as having a few of the current developers, as well as QA or project managers, work remote for a longer period of time. Have them keep a diary and evaluate after a couple of weeks. What challenges did they experience, did they miss out on importing information, were they able to join meetings and if not, find notes on the meetings they missed.
Documentation is crucial here. Both real-time by communicating via a public slack channel for example, as well as archiving topics discussed and decisions made in tools like Google Docs and Confluence. This documentation should extend beyond the projects. Write down what goes on in the organisation, and why things are done a certain way.
Bringing a new hire on board are key learning moments to test this. What had to be taught to them verbally after they read the documentation, what project or company knowledge were they missing.
If someone is able to work remote, go on holiday or get hired into the team and get up to date with the goings on solely through documentation and real-time communication channels then odds are the remote team will be as well.
On a side note: the most common language when outsourcing is English. Make sure all documentation is written in English. Where possible translate older documentation and project briefings as well.
Define, define, define
Unfinished tasks, loose ends and missing information leads to irritation and stress. This might be just one of the biggest factors of unsatisfactory cooperation when outsourcing.
But when is a task performed well, what makes for a task to be done, or what should a finished feature look like? Clearly defining what is expected is crucial for both sides.
Although this will be an ongoing exercise here are a couple of items that are definitely worth tackling beforehand. Some of these points might be slightly more technical, bare with me.
- How do we communicate? Should verbally be agreed upon things be emailed afterwards? What is the best way to reach out in case of an urgent issue, is it ok to use WhatsApp and do you expect a read or received confirmation. These things differ wildly per culture, and per person.
- What are the Office Hours? What time does the day start, when does it end and how long does the lunch break last? Just because you eat your cheese sandwich (Dutchy here) in 15 minutes doesn’t mean the Italian colleague can do the same with his 3-course meal with wine. Agree on when to expect someone to be available.
- What should be included in bug reports and feature requests? When is an issue ready to be worked on. A title and five words in the description with a promise to tell someone more during a call will not be sufficient.
- What does an estimation of an issue include? does the colleague account for reading documentation, testing, some rework after feedback, or is it just their own hours writing code. This difference might account for constant over- or underestimate.
- When is an issue ready to be Code Reviewed? Should there be some form of unit testing included? Documentation written? Or would a first pull request include more or less a minimal viable product or proof of concept?
- What is the coding standard used? Code quality is a very subjective and ever-changing subject. What is an acceptable compromise for one is a dirty hack for another. Document code requirements and use static code analyzers to give quick, automated feedback on the written code. Use Pull Requests to educate team members on what is expected.
- Definition of Done/Ready. This one has some overlap with the previous ones; define the DOD and DOR. This way there can be no discussion on what should have been delivered.
Talk about expectations and biases
Outsourcing has a bit of a stigma to it and there’s a chance some of the team might not be as open to setting up a remote team as you might be.
It’s important to discuss this openly in the team. Address bias and perhaps even discrimination early on and identify ambassadors. These ambassadors, which should be present in every layer of the organisation, will help smooth over issues as they arise later on, and lead the effort as the two teams get to know each other.
Only when the remote team is seen as equal colleagues they will feel welcome and put the effort into the relationship as well.
The Selection
Having done the preparations for including a remote team we can start to select a partner. There are a few decisions to make here, each with their merits but also pitfalls. Next to that, we need to be clear in what we need and expect from these partners.
We’re looking for a reliable outsourcing company as well as the quality of resources they might be able to deliver. We’ll want to know a lot from them, talk to possible candidates, know the company itself, their HR department and other intimate details, not just the sales pitch from the account manager sitting across from you.
Please note I’ll use the term resources. A remote team
Decisions
1. Location. Generally the further away the cheaper the hourly rate will be. But with distance also comes a greater difference in culture, as well as timezone differences which create more challenges around communication.
When starting out my advice would be to keep it close to home, within a few timezones. This gives more time during the day to communicate as well as making physical visits between the teams easier.
2. Culture. This is definitely an important one. Communication is complex enough in a non-native language, let alone with wildly different cultures that have different contexts and habits.
What cultures are represented in the companies team, or what is your team familiar with through family, holidays or previous jobs? What values does your team appreciate or require to be able to work with someone? Make sure to have a clear picture. To find out more about cultural compatibility I can recommend reading “The Culture Map” by Erin Meyer.
3. Full time, Part time or Project based. Resources can be hired on various terms. For a one-off a predefined project might be considered, or if the workload tends to fluctuate part-time resources hired by the hour could work. The best result tends to come from investing in relationships. Outsourcing with full-time resources giving longer commitments means investing in people. They will know the company, the clients and have a deeper understanding of the projects.
4. Managed Teams or Standalone Resources. This one pretty much comes down to how comfortable the team is with leading resources from a distance. In general, when hiring standalone resources the outsourcing company will provide said resources, and it’ll be on the hiring company to keep them busy, review their performance and perform various more people-management related tasks.
Companies offering Managed Teams will work together with you on interaction with the team, they will coach the resources as well as help the team with any issues they might encounter. Of course, this will be reflected in the hourly rate as there is some overhead.
5. Company size. Outsourcing companies differ wildly in size, or could even be a freelancer. In general bigger companies, let’s say 3- to 400+ employees will tend to provide stand-alone developers. They offer many disciplines from frontend to backend to DevOps in different languages and have well-oiled HR departments providing a steady stream of new talent. On the other hand, smaller companies allow for more relationship building and might feel more like a cultural fit with the team but lack the large and diverse pool of talent. There is something to be said for both, be aware of the pros and cons.
What to ask for in the RFP
Having made those decisions we can narrow done our list of outsourcing companies. Now it’s time to send out a Request For Proposal to get to know the companies a bit better.
Start off by describing the company and the types of projects and clients. Outline what kind of a team is required and what expectations there are based on the above-mentioned decisions.
Include descriptions of the positions as would be done in a job posting, the more specific, the better the outsourcing company will be able to find a match. This company might also need to hire for these positions so be clear for what period of time the resources are to be engaged and expect some ramp-up time.
The team might take one or two months to form as resources are hired to transferred from other projects.
Some other information to ask for could be:
- Average employee turnover of the company
- Process for replacing a resource because of sickness or underperforming
- Insurances in place at the company
- ISO certificates and GDPR compliance
- What their HR department and hiring efforts look like
- At least two relevant references of clients
- If available, CVs of possible candidates.
Face to face meetings
Since the team will work closely together with this company visit the shortlist of possible partners after receiving their proposals. Taking time to see the company and their team for yourself beats any Skype call.
Extending the stay beyond a formal 60-minutes meeting by asking for a desk to work from for the morning is a great way to get a better chance to experience the culture and atmosphere of a team.
Make sure to take the time to get to know the company as well as the people working there, on all levels throughout the organisation.
Working with the remote team
As with any team, maintaining a healthy relationship takes effort. A company with remote teams should focus on this and have a plan to keep improving this.
Two important points are frequent in-person meetings as well as retrospectives on the collaboration.
Make sure there are quarterly visits back and forth including time outside the office. Personal relationships will make working together easier. Having team members visit each other for longer periods of time, one or two weeks, in each other’s offices creates a deeper understanding.
Project kickoffs work best in person, and exposing the client to the remote team will have positive results.
Having a tool such as Slack or Hipchat will help with communication. Conversations should be done in public channels as much as possible and frequent check-ins or daily standups help team members to keep track of what others are doing.
Sprint plannings, Code reviews (in case of developers), test feedback rounds and sprint retros are vital moments to call in and discuss the project. This means project teams are mixed. Both in-house and remote team resources work together.
Stay vigilant
Over time there are several pitfalls that tend to occur between the local and remote team. These happen in most projects I worked with but when caught early are easily fixed.
- Communication in group emails or slack channels reverts from English back to the native language
- During stressful periods there might be a “us vs. them” mentality
- New hires lack indoctrination both in the local and remote team
- In-person meetings are less frequent.
- Changes in the company, processes or philosophy are not well communicated to the remote team.
Having ambassadors and a more formal liaison, whose job it is to keep an eye on this will help a great deal.
Make sure these people believe in outsourcing, and in the hired team.
Dealing with issues
While flaws or shortcomings in the processes and communication around a project will become clear much faster with a remote team than with an in-house team, personal issues around a colleague, or between colleagues might linger for longer periods of time.
As mentioned before having frequent retrospectives both about the project, as well as processes and one on one personal talks with team members will bring these to light.
If problems do arise try to not postpone addressing them till a next face to face meeting. A video call is the best option here. As we are most likely dealing with different cultures it is important to be aware of these.
Keep asking questions and insist on detailed feedback.
Is it worth all this hassle?
You’ve made it this far in the article, and by now you might wonder if working with remote teams is worth all the hassle. I probably can’t answer this without being a little biased. As the Dutch saying goes “Us of WC Duck advise… WC Duck”.
When done right working with a remote team will not only give you a potentially unlimited pool of talent as well as reduce hiring effort, but will also bring in new ideas, improve communication and internal processes, allow companies to more rapidly grow and embrace new technologies.
Last, one of the biggest benefits I’ve found in working with remote teams, it gives diversity to a team and brings refreshing new input both on a professional and personal level.
