Common Mistakes When Working With A Remote Developer

January 1, 2016 | Fyez Ahmed (Editor)
Boss screaming

Being a manager in charge of a team of remote developers requires a specific set of skills. Managers working in a conventional office setting are used to their teams being housed in the same building in most cases, so what is a manager to do when their developer isn’t even in the same time-zone? How does one stay up to date with pending projects? How does a project manager communicate with a remote developer from a background that is unfamiliar territory? With responsibilities piling and paradigms shifting, how does a manager make sure that their remote developer still feels involved and engaged?

Managers need to understand that shifting paradigms have created the need for a shift in the way progress is tracked as well. From the manager’s point of view there than can be few things more frustrating than a project that seems stagnant, whereas the developer can feel under-appreciated for work that is meticulous and, by its very nature, appears to be difficult to track. Here are a few mistakes a manager might be making when working with a remote developer, and tips on how they may be avoided:

Throw stereotypes in the trash

Since a team of remote developers hail from a variety of backgrounds and regions, it’s imperative that managers don’t have any preconceived ideas about their workers based on generalizations, myths or racial stereotypes.




Open communication is vital here, and language barriers must be overcome to ensure that the manager and remote developer are on the same page. Try not to think of different time zones and backgrounds as a hurdle impeding progress but as a great resource for ideas that you would otherwise not have come up with.

Diversity has always been hailed as a necessary component for any company and multi-nationals are unified in their approach of creating a workforce consisting of professionals from all over the world. Not only do they promote innovation but also offer a unique insight on shifting global trends.

A different background means a different thought process in most cases so try and maintain an environment that promotes free speech, even if that speech requires a bit of help from Google Translate to decipher.

Prioritize on recruitment and training

An important thing to remember is that a remote developer should be treated just the same as any other employee. This means that managers should not assume that developers should automatically have all their tasks completed around deadlines with only the occasional email being exchanged on how the project is getting on. Remote developers need to be trained with the same consistency as all employees, with different personality traits being taken into account. Managers should take the time to make an effort in getting to know how best to bring about the best work from their remote developer. This is where good recruitment choices matters most.


Having a manager who is comfortable in working with a team of remote developers would be your ideal situation, but what exactly does that entail? It means hiring and training managers to communicate with their subordinates using a variety of methods to ensure time is not wasted in ironing out issues that would not have existed in the first place had there been an understanding between both parties. It also means recruiting a manager who can assume a variety of roles on the fly.

Sometimes snap decisions need to be made to meet deadlines so a manager who can undertake a different role for the overall success of a project is a key factor. This is asking a lot from a single individual, therefore training managers to tackle problems with a certain degree of flexibility goes a long way.

Treat micro-managing as a cardinal sin

Of-course managers have a vision of what the finished product should be. But so does the remote developer and chances are that you will stifle your developer’s natural tendency towards creativity and innovation if every minute detail is tailor fitted to the manager’s specifications.


Instead of highlighting the problems that need to be worked on, the manager might find themselves habitually providing implementation details as well. This is applies most for managers that have a background in coding themselves. Pretty soon your remote developer will just be writing the code that the manager is writing, resulting in the developer feeling undervalued and pretty much redundant, and the manager taking on a burden that was meant for your remote developer when you hired him in the first place.

Use simple tracking mechanisms

Having a team working on a single project from different parts of the world means implementing an information system that tracks the progress of your remote developer. Try to keep your tracking system as simple as possible to avoid problems arising just because your issue tracker was too complex. You as a manager might be comfortable with a specific system, but remember that your remote developer may be more at ease with a completely different program, even more so if you are working with a freelancer who does not have the time to learn an entirely new format.


Implement a Source Code Management (SCM) system, a simple issue tracker and maybe a few wiki pages where ideas and proposals can be documented. A reliable project management application that is worth checking out is Redmine. This platform is very simple to configure and is open-source, cross-platform and cross-database.

If you would rather do without the hassle of maintaining a Ruby server and starting from scratch (something that you will run into with Redmine), then another favorable choice is GitHub, which features the git CMS, as well as Git Issues which can be used to manage your commit requests, pull messages etc. Once your information system is up and running you can begin training your remote developer on how to use it effectively.

Leave a Reply

Your email address will not be published. Required fields are marked *

Follow Us