If you’re looking to hire remote developers or bring in a remote team to add to your own team, the biggest challenge ahead of you will be eliminating “walls” that can create tension.
After managing remote teams for many years now for X-Team, here’s how I’ve been able to eliminate those walls as early on as possible and create long-lasting relationships with many onsite teams.
It’s all about creating opportunities for your remote team to build trust and respect with everyone else, rather than creating walls and more tension.
The first mistake many companies do is they hire a project manager to manage their remote teams under the assumption that the only way to keep remote developers in check is through rigorous management by a “remote” project manager. Sometimes they even appoint a separate lead developer just for the remote developers.
This immediately creates your first wall that divides the remote team from the rest of the development team. They need to report to the same leaders, otherwise you’ve created unnecessary bottlenecks, competition and potential for fingers to be pointed.
Along the same line, they should also all be working within the same project management tool.
If you hire a development team that already has their own PM tool, consider asking them to work within your project management system rather than their own for the sake of accountability (across ALL developers), insight/tracking, and also to make them feel part of the team.
The onsite team will start to get used to seeing the remote team’s names more often, they’ll be able to do code reviews for each other, and most importantly, they’ll start building trust and respect for each other as they see the remote devs closing tickets.
If you want your remote developers to feel part of your team, let’s start by not calling them remote. If they’re part of your team, then they’re part of the team and nothing else.
The more you say in meetings with your onsite team, “We’ll get one of the remote devs to do it,” the more the onsite team will start to believe there is a wall between them.
Call developers by their names and help build that respect that your onsite team can follow.
Also never refer to them by their location, such as “The Brazilian Team” or “The Canadians.”
If a group of developers in one location is working on a single project together, refer to them by the project name rather than their location. Call them “Project X” team instead.
If you’ve made it this far, your remote development team is already in much better shape than most.
You can make the situation even better though by starting to focus next on the culture you build among your entire development team, especially now that it has a remote element.
It’s very common in X-Team that our developers will go onsite to meet our partners before the kick-off of a new project. They also get time for bonding as well.
But you can take it even further for better results by getting your onsite team to go on a retreat for a weekend with your remote team.
An Airbnb and some flights will cost you a few thousand, compared to the cost that will come with having developers with grudges for one another.
Take for example this castle we rented in Poland for our developers there to go meet and hang out for a weekend.
We also had them go paintballing, ATV riding, kayaking and more.
A quick hackathon is a great idea, too. Give them that opportunity to build trust, respect and become friends before they start working together.
Each week at X-Team, we post to a channel called “#learn-about-x-teamers” where we post a technical Q&A with one of our developers.
The goal here is to build trust and create transparency.
If your remote developers are simply seen as “the Polish guy” or “the Brazilian lady”, that facelessness will only lead to more walls.
Your onsite team can’t trust anything remote developers say without proper introductions that show each person’s background and skills. It also lets them know who they can reach out to for questions about a certain tech expertise.
So give them a chance to be put under a spotlight and build some respect and reputation as early on as possible.
Learn more about how to do this using Slack in one of my past tips here.
The keyword here is everyone.
Once a month, you should bring your entire development team together (even if it means someone has to wake up at 3 a.m.) to celebrate successes, share big updates, meet new developers, etc.
Every time we do this in X-Team, the feedback is incredibly positive as it reminds everyone that, despite being remote, we’re all part of the same team.
Get more action going in #random The #random channel (or whatever your main hangout channel is) can be an incredible culture builder if you encourage more action to take place there.
Start sharing links more often to interesting tech news, or photos of things happening in the office or in your life (run a marathon recently?), etc.
The more you make it a safe place to share, the more that people will share and ultimately start conversations with their remote comrades that lead to more respect and trust.
We have a bot that asks a random question once a day to a random channel member, such as: “What’s the best thing you’ve seen on YouTube recently?”
Bonus: Learn how to get your team creating their own GIFs in Slack like the one below in one of our Slack tips posts here. It’s another huge team builder using a remote tool:
We’ve had great success with building respect and trust among our team by encouraging our developers to host short tech courses as Hangouts on Air that broadcast to the whole company.
It gives developers (especially remote ones) a stage to show off their skills (building reputation), while also keeping your team educated and always learning and growing. It’s win-win all around with this one.
Here’s a recent Crash Course one of our developers hosted:
Last, and certainly not least, is an absolute must. It’s also the most enlightening part of the benefits that adding a remote element to your team can have.
All too often in offices, knowledge is shared by leaning over and telling someone. No one else ever gets that knowledge or information, and for remote developers, that can result in confusion, delayed ship dates or worse.
Adding remote developers to your team means that you have to document everything so that knowledge is always accessible by everyone on the team.
One of the best solutions we’ve found to this is journaling on platforms like Slack.
Each developer will post updates to their journal each day about important learnings, tasks accomplished with context, and any other knowledge/info that the rest of the team should know about.
Here’s a short tutorial on how to start doing this with your team and ultimately discover the most powerful tool our team has for building trust and moving faster and forward together as one team: