Software development is hard. Working with remote developers is even harder.
In this article, we will share our top 10 best practices for working with a remote development team. This guide is based on my experience of being a remote developer, working with and managing remote developers, and running a company that provides remote development teams. I’m sure it can even help onsite development teams as it has lots of caveats and gems delivered as pro tips, learned over many years of experience on both sides of engineer and managing engineer positions.
1. Share Your Product Vision and Company Culture
I think many people make the mistake of just assigning easy work items to remote developers and then integrating the work on their end. Don’t make the mistake of not giving them the full product vision.
All developers need to understand what the goal is and where the project is going, and how people work within the company culture. Paint them a picture of your product vision and company mission effectively, so they can make smart choices as they work on the project and be a true extension of your company culture.
Pro Tip: Make sure any all-hands meeting caters to a Zoom (or Google Hangouts or Skype etc) session, even if remote members just listen in, so you maximize remote workers’ participation in vision and mission-shaping moments.
They also need to understand and be able to see the upcoming work items to do. They want to know they have job security and where the project is going. Be sure to include them not only in all product lifecycle rituals such as release and sprint planning, but also with any other important meetings held by other parts of the organization and key decisions made as time passes.
2. Over Communicate and Re-Engage
Under-communication can cause huge issues whereas over-communication can only be beneficial. Anytime you are working with a remote team it is easy for them to be left in the dark about a lot of things.
Don’t just talk to them once a week or once a day during scrum standup meetings. Be sure to engage with them 1 on 1 daily to really make sure they are getting enough help to get work done, especially during the early days of your engagement
Pro Tip: One great way to engage local devs with remote devs is to encourage pair programming and make use of remote development plug-ins in Visual Studio.
3. Overlap Your Work Schedules
One of the biggest challenges with remote development teams is working in different time zones. My team is in the UK (GMT) and my remote team is in Bucharest (GMT+2). They are 2 hours in the future from us but this can be worse with silicon valley companies with offshore offices in India etc.
The way we set up the Bucharest office is to work around 11 am to 5 pm core hours, with flexibility before and after these hours. This enables us to have at least 6 hours of time daily for meetings, scrum, Q&A, pair programming, etc. Luckily they are mostly night owls so love coming into work at 11 and leaving at 7 pm, meaning we get 8 hours of overlap which makes up the whole work day.
Pro Tip: Look into offering flexible working hours for your remote developers with core hours falling within your HQ work times, if the time zone difference is vast make sure there are plenty of tools and rituals in place that encourage offline knowledge sharing and book as many sync meetings as possible, ie adhering to morning standup rituals of Agile (even though it’ll be an evening standup time for one part of your office)
Shifted hours can also work as an advantage, ie a team in the USA can be overjoyed about having the Indian team handle on-call support while they sleep, and vice versa.
4. Simplify Your Communication
Depending on where your company and your remote team are, odds are, even though they speak proficient English, they may not be as fluent in your language as you are as a native speaker. The best thing you can do to help is to simplify your communication, and have clear distinct, and ideally written instructions.
Pro Tip: For any discussed changes to your planned iteration stories, if done over Slack or Zoom meetings, make sure to keep minutes and quickly write down the changes on the actual story tickets to make sure it’s not lost in translation, so keep written transcripts of verbal comms in your project management tool (we recommend using Trello)
This could also be helped by limiting vocabulary and avoiding metaphors and cultural references that a person from a foreign culture would have a hard time understanding.
Communicate to the point and state the obvious with very clear directions.
5. Minimize Impediments, Including a Secondary Task
There may be times your remote worker gets stuck and/or needs help from someone else. Ideally, a clear roadmap and epics well broken down into stories, and stories broken down into tasks would avoid such times, but in case you’re not on top of your game with project lifecycle management, read on, or skip to best practice number 6 if you are.
There are countless reasons that developers get stuck in the middle of their work. From compilation/bridging/interpretation issues caused by another branch in git to business logic questions, lack of clear requirements, etc. so it’s always good having multiple work items in their queue so if they get stuck, they have another task they can work on. If they get stuck on task number 2, make sure they have a third or fourth item they can work on in lieu of the original impeded task.
6. Have Lots of FaceTime
Doing daily scrum meetings by phone or over Slack works ok but video adds the real human element that can help with team building and sharing company culture over time. It is important that you really get to know your remote members and build a real relationship with them.
Pro Tip: Try to regularly pair staff working remotely, ask them to take, let’s say, a break for 15 minutes, once a week between two random employees (there’s a slack plug-in called Donut that does this precisely, they prompt people to get coffee, which can be a zoom chat in your team’s case)
Video can also help better identify staff’s emotional status or mood. It’s of utmost importance to make sure the whole team is happy and functioning together as a single unit. It is easy to really ask them how they are progressing at a personal level rather than just on the project they’re currently working on.
I do love building a real relationship with the team, joking with them, and establishing rapport. Video conferencing via Zoom, Google Hangout, or any other platform is a good way to do it, but it’s also good to, say as the product owner or VP of Engineering or CTO, travel there and spend time together with the whole team on social activities.
I liked taking my teams out for pizza and bowling nights, for example, every 3 months (every 3rd time I visit considering I visited monthly), which really helps make that deep connection when you see them laughing about having fun!
7. Give them Real Work To Do
Being able to find remote developers for a much smaller fee than your local team demands doesn’t mean you can get away with only giving them trivial work to do. They make less money per hour due to the cost of living where they live being a fraction of Silicon Valley (or London etc), not because they are less capable developers. Just as workers of any skill set hate doing repetitive monotonous parts of a project, so do they. If you want to recruit and retain top talent on your remote team, make sure they get to do authentic and creative work and feel like part of technical decision-makers and not just as “drones”.
Set your expectations high as there are tons of highly skilled devs all over the world so do treat them as they are.
8. Don’t Micromanage Them from Afar
Everyone hates to be micromanaged. It is hard to scale your development team if you can’t hire people you can trust, and also empower them by trusting them.
Pro Tip: It usually works well to keep lead talents in-house and have your remote team as an extension of them. With this type of setup, it’s easy to maximize your capacity on mid-weight and junior developers who are full of passion to simply implement at very fast rates, while making sure your more senior in-house developers keep an eye on quality by extensive code reviews, enforcing lint rules, keeping an eye on unit test code coverage, etc.
Another pro tip is to mix in QA engineers, usually at a rate of 1 to every 2 or 3 developers, as TDD or e2e automated UI testing can’t replace the old-fashioned manual testing, especially for catching UI/UX issues, so best hire QA staff with an eye for design and UX along the mix.
9. Get Your Point Across with Pics, Videos, and a well-defined Lifecycle
Effective software development management comes with great communication. A picture or a screenshot is worth 1000 words or a video representation is worth 10000.
It is rather quick to take a screenshot pic of a feature request and doodle on it. That little scribble on top of a pic can help remote workers instantly get the gist of what the feature request’s demands are. Also, wireframing and full-fledged end designs can save a lot of time.
Pro Tip: It helps everyone to understand the importance of design, by adding extra steps to your project cycle, we use and recommend the following stages:
Backlog (design proposal) -> Design (visuals ready) -> In progress (TDD) -> Code Review -> Test (QA test) -> Integrate (CI/CD or merge to Dev branch) -> Done
Pro Tip: It is of super-duper utmost importance that you define done criteria, extra steps above can help define flatter done criteria but if you have a simple three-staged lifecycle such as Task -> In progress -> Done, you should have checkpoints before a done task is accepted as really done, like “has it been code reviewed?, has QA approved it?, did the code change since QA tested it? is it merged to dev branch? is it merged to staging branch?” etc.
Also for the design proposal stage, it’s OK to have wireframes, usually made by someone like the product owner or QA, but it really does help frontend developers to have end goal visuals readily designed by UX/UI designers to get pixel-perfect implementations. We can even elaborate on this stage by adding animation designs, video representations of animations expected, etc. to get that MLP (minimum lovable product) instead of MVP (minimum viable product).
10. Treat Them Like Your Team, Not a Remote Team
The mistake to make is to create an us vs them mentality. Make them feel like they are part of your team, as they really are, they just happen to work from a remote office.
- Avoid antagonizing them by treating them as “them”
- Don’t exclude them in comms — work and none work related comms
- Include remote workers in all company-wide and immediate team meetings
- Have face time with them regularly online and even in person
Companies, including but not limited to Xapo, Zapier, Kraken, and many others (especially silicon valley firms) leverage an entire remote development team, where numbers can be hundreds or even thousands.
Hire the Correct Remote People
I worked with remote developers all over the globe (like India, Argentina, Ireland, Poland, Hungary, Ukraine, and Romania). There are talented software developers everywhere, and there are more bad offshore agencies than bad developers.
From our experience, we prefer working with developers in Bucharest, Romania. Here are some of the reasons why:
- High level of English fluency
- Low Cost — You can find excellent developers for as little as 500 euros per month
- Strong Communication Skills — They are excellent communicators and aren’t afraid to speak up or challenge you. They want to do a good job and succeed.
- Highly Talented Workforce — We’ve hired developers who previously worked at companies like Electronic Arts, Accenture, and others.
- Security of EU legislation — We tend to feel safer knowing Industrial Property rights and human rights are actually enforced by an established lawful government, and the system simply works
- Friendly tourist destination — Visit your team in Romania, it is a great place to travel to, they have a lovely and friendly culture and everyone speaks English.
TLDR: Make sure to share your company culture, mission, and vision, with your remote team and over-communicate in a simple manner, overlap your work schedules, manage projects thoroughly, have lots of face time, give them real work and don’t micromanage, and treat them as part of the team while using technology to stay close.
Ping me here to start a conversation, if you’d like to learn more.
Comment below to share your own experiences.