As a developer and small business owner, I’ve had insights from both sides, I’ve worked as a remote developer and managed remote developers for different projects and with different teams.
In this post I’ll share some of my experiences in the hope that it will make life a bit easier for all parties in remote projects. When it comes to do’s and don’ts of remote team management, I tend to focus on “don’ts” – because unlike “do’s” they tend to apply to practically every team.
When entering the remote developers’ world, the biggest obstacle that managers must overcome is to change their mindset by accepting that the developer will not be in plain sight, and where they can manage and follow the work being done. This new paradigm requires businesses to implement a number of mechanisms to track progress and avoid a redundant workload. Such mechanisms will help both manager and developer be more productive, which is in everyone’s best interest.
To make it clear, all these mechanisms should not be used to control or micro-manage the employee.
Don’t Believe In Remote Team Myths And Misconceptions
Let’s take a look at the pros and cons of managing remote teams on a single project, by starting with communication.
Business has gone global, and the advent of vast, multinational organisations has created new challenges for millions of professionals around the world. The complex and intertwined nature of global teams demands a more thorough and thoughtful approach to internal communication.
In such organisations and teams, many individuals don’t have the luxury of working in familiar surroundings or speaking their native language. Teams working on the same project might be separated by oceans, rather than offices and cubicles. Team members come from different cultures and work across the globe.
These professionals shouldn’t have to worry about communication, but they must be able to cooperate with multinational team members. All parties need to be proactive. Corporate culture must reflect this paradigm and help foster a productive environment in which remote, multicultural teams can thrive.
Our own Scott Ritter busted the top five myths about remote teams in a recent blog post, which you may find useful if you are interested in the subject. Toptal CEO Taso Du Val also elaborated how our network operates and how we stride to create the ultimate remote team culture.
Don’t Forget To Embrace And Encourage Diversity
The first step toward a sound remote-team communication strategy begins with the acknowledgment that multicultural teams transcend national and cultural borders, putting them in a unique position to offer insights hard to attain with centralised, monolithic teams.
But don’t worry; diversity is good for business!
According to a survey carried out by The Economist Intelligence Unit, multicultural teams are favoured by big organisations; many executives believe they help foster innovation because of their broader knowledge of global trends. Further, they are less likely to suffer from “group-think” mentality; their diversity helps them tackle problems from different perspectives, thus producing a better range of solutions tailored for specific regions and markets.
It can be argued that managing remote employees may be more productive by virtue of not being at the same place. It may sound counterintuitive, but such remote teams simply spend less time chatting, socialising and discussing trivial matters.
While physical separation can lead to more productivity, it can also create misunderstandings, tension, alienation, and greater stress and anxiety. Consequently, it becomes necessary to mitigate these negative side effects with initiatives that foster positivity and collaboration on a personal level. Improving communication in remote teams can be a daunting task, and building personal bonds among team members tends to be challenging. That’s why a human touch is necessary.
Finding something that can improve engagement, regardless of background, is a relatively simple way of boosting morale and cooperation. This effort can take many forms, depending on the size and composition of your teams. Ideally, it should be centred around a stress-free, leisurely activity that team members will enjoy, ranging from work-related competitions, entertaining projects, or discussions that are not work-related.
Taking part in such activities, at the organisation’s expense, may sound like a less than ideal allocation of financial and human resources, but bear in mind that rallying teams around a common cause usually leads to a better work environment, stronger personal ties and improved productivity.
Don’t Take Recruitment And Training Lightly
In order to make the most of managing remote teams, you need to be mindful of cultural differences and compensate with adequate training.
Improving language skills is just one piece of the puzzle since communication skills are affected by cultural differences. It starts with good recruitment policies that favor individuals, especially those who will be in managerial positions, prepared to work in multinational environments. Experience in remote projects obviously comes in handy, but should not be a prerequisite. Just because a remote developer won’t be in your office every week doesn’t mean that recruitment should not take personal traits into account. You and your team will still have to communicate with remote developers on a regular basis, so ask them the same questions you would ask any on-site worker – remote or not, they still have to fit in.
While it is possible to address some issues with additional training, it may not always be practical, but in any case, good training is the next logical step. Training should develop existing positive traits, while at the same time mitigating shortcomings and addressing previously identified weak spots.
Managers dealing with remote teams routinely have to assume new roles on short notice, take over projects they are not necessarily familiar with, and spend a lot of time catching up. In such situations, internal communications do not tend to be high on their list of priorities, even though they may now be leading teams that have spent years collaborating on one or more projects. Time is a valuable asset, but so is good teamwork; managers must take time out of their busy schedules and learn more about their teams, individual team members, and problems likely to crop up.
Emotional distance between remote managers and their subordinates can also pose a problem, since team members may be reluctant to confront new team leaders, or even approach them in either formal or informal settings. A good remote employee manager needs to recognise this and insist on more personal engagement – as I said, “Be proactive.” – what’s the point of having a team of talented remote developers if they don’t share their thoughts with you?
Don’t Use A Complicated Information System
Do not miss a chance to implement an effective information system that includes a Source Code Management (SCM) system, issue tracker (not too complicated, please) and possibly some Wiki pages where all parties can document things, or sketch ideas and proposals. All these collaborative tools will make development-and-release management much easier to achieve.
It is important to keep things as simple as possible here, because this information system will be used on a daily/hourly basis. If it ends up too complicated, it will take time that should be used on implementation and/or design. The process may also need to be simplified for new team members and freelancers who do not have time to learn the ins and outs of an organisation’s policies.
My long-time favourite project management application is Redmine, an open-source, cross-platform and cross-database system. This platform is highly configurable and you can integrate your own SCM, different plugins, and service hooks.
If you don’t want to go through the trouble of maintaining your own server with Ruby and setting everything up yourself (Redmine can be complicated for inexperienced sysadmins), another good choice is GitHub, which features not only the git CMS but also GitHub Issues, which integrates well with your commit messages, pull requests, etc.
Once we have our information system set up and ready, we can start integrating our remote developer into our project.
Many managers have a hard time letting go of their responsibilities, especially if they themselves come from a developer background. Instead of focusing on communicating the problems and project goals, they find solutions for those problems and provide implementation details, so the only work left for the developer is to code what he has been told to code. This is not a good practice when managing remote employees.
On one side, managers lose too much time on stuff they hired the remote developer to do. The developers may be unsatisfied with this situation, either because they feel undervalued and left without a chance to be creative and innovative, or simply to prove themselves. After all, problem solving is exactly what developers study for years, so taking it out of the equation and turning developers into automatons does not make sense!
Like everything else in life, it is all about finding a good balance.
Don’t Worry About Time Zones, Use Them To Your Advantage
Good remote developers tend to be self-sustaining and independent by nature; they need freedom and responsibility to organize their time. Overlapping working hours are useful, though not mandatory, when you have a good information system and good communication with your developers.
Working in different time zones can be of benefit to the business since you may be able to achieve “round the clock” efficiency when developers in different zones take over various aspects of the project. If your developer is ahead of your time zone, it gives you the opportunity to review his work the same day and you can immediately assess and coordinate the next big thing. On the other hand, if you are ahead of your developer’s zone, this gives you the opportunity to prepare everything the developer needs in order to complete the task.
Remember, a good manager is nothing more than a service to his employees enabling them to get the work done, not the other way around!
Don’t Force Day-To-Day Goals, focus on Mid- Or Long-Term Goals
Day-to-day goals are a form of micromanaging the project. Instead, try to communicate the overall picture to your developer and, together, set clearly-defined priorities. If you get the developer to understand the project as well as you do, the developer is likely to be more useful.
For example, the developer may have insights into the newest technologies, or implementation details that affect the prioritization of different tasks, or the determination of the Minimum Valuable Product (MVP). Both of you need to define clear goals and milestones, and get work done step-by-step. It is your responsibility to make sure that all these milestones fit into the big picture.
In my opinion, the Agile manifesto (methodologies) is the best thing that has happened in project management over the last few years.
It enables you to do exactly what is needed, to delegate responsibility to those who actually implement things, and to force common sense into every party involved in the process. You define your mid- to long-term goals and tasks with some high-level estimates on difficulty, and in those weekly (or bi-weekly) sprint planning meetings, you let the developer determine the exact workload and difficulty for completing those tasks.
Like every good thing, it takes time to build good Agile teams. Don’t expect to have a working team within three months. Agile is all about learning by doing, and growing together as a team.
Don’t Hide Business Details
Well, this one is tricky. Some projects are sensitive by nature, and leaking information can be harmful. Non Disclosure Agreements (NDAs) may address the problem, but they are not bulletproof.
However, the more the developer knows, the more effective he can be, not only in solving predefined tasks but also in solving, on the fly, all these annoying small issues and hiccups. In the end, this will make the developer more productive and make your life easier.
The Agile development process comes in handy here, as well. It enables knowledge-sharing between parties (stakeholder, tester, developer, etc.) by removing any hierarchy and by considering those parties as equal team members, with the same responsibilities, and thereby encouraging them to work as transparently as possible. Another benefit of transparency is that problems are “escalated” quickly, and can be picked up by any part of the team.
Don’t Ignore Remote Team Members
Remember, when managing remote workers, you are a service to your team, and if the team needs your input, you should not be too busy to support them. If the developer can’t solve something on his own, he will get stuck and lose valuable time.
As a developer, usually when I ran into a dead end, I turned to my SO for advice, plus, I tried to offer advice, as well. Do not totally ignore the developer’s advice, since it could be insightful, or it could solve a problem you weren’t even aware of.
If something is unclear, or if you think it’s not necessary to address the problem, argue your position while being open-minded and allow the developer a chance to convince you that he is right after all.
Again, this will build communication skills and improve trust.
Quick Remote Team Management Tips
Since I’ve already summarized the main points in tweets and illustrations, here are a few more quick tips and thoughts.
- These general rules can be applied to remote and on-site developers.
- If you micromanage, you will miss the opportunity to learn and let learn.
- Be open-minded and trustworthy, as this is the only way to build a good remote team.
- Keep in mind that an estimate is just an estimate; you will encounter under- and over estimates.
- All who work make mistakes, and if you don’t forgive other’s mistakes then yours won’t be forgiven, either.
- Most importantly, the greatest motivation for any developer (besides the satisfaction of accomplishing a difficult task) is money. So, do not delay payments and consider instituting bonus policies, as well.
This article is originally posted in Toptal.