4 worst mistakes in managing distributed developers

Lyudmila Kucher
Lyudmila Kucher

I specialize in outstaffing and staff augmentation, and I have extensive experti...

40 posts

Even though the work seemingly remains the same, there’s a lot that changes when a project manager makes the switch to work remotely, especially when it concerns the resource and staff augmentation industry.

Watercooler conversations are replaced by sharing memes in off-topic Slack threads, tasks move from whiteboards to project management tools, daily commutes turn into doing work from home, work hours become more fluid, and other team members can’t distract you from tasks as easily as in an office.

This transition usually goes smoothly, but it can be even smoother if you know what to avoid. So today I want to outline 4 small mistakes that can turn into project killers if you don’t fix them early enough.


Issue #1. No documented procedures

Business documentation is what gives you a point of reference whenever you want to check whether you’re on the right track. If you’re going to achieve any goals, you need to sometimes remind yourself what those goals are, and how you initially planned to achieve them.

It also allows you to manage more effectively regardless of whether your whole team is working at one office, or everybody is working remotely. But while you might be able to run software development teams in-office without documented procedures, it is virtually impossible to do so when you’re managing remote employees. Even hiring offshore programmer should be a well-documented process.

What type of documentation should you have? It depends on your situation, but there are certain things that 99% of remote teams will need to develop at some point:

  • On-boarding guide – a document that will outline what new developers should do when they join, the basics of team culture, basically a “how-to” guide for working on your team
  • Workflow – this should contain all the information about who manages whom, who’s responsible for what, who to inform about work issues, who to call when work gets stuck, etc.
  • Rules for communication – you can’t expect your team to communicate in a certain way if they don’t know what your desired communication process is, it needs to be documented
  • Contact information spreadsheet – a useful tool, especially in case of emergencies

While these are the basics, you might want to extend this list depending on what your project requires.


Issue #2. Hiring too many people, too fast

Sometimes it might seem that it’s a good idea to quickly scale up your team, but in most cases, it really isn’t. It’s usually only a great way to burn through your budget too fast. When you’re hiring developers online, you need to have an airtight screening process or use the services of a company that screens potential candidates for you.

Thorough screening requires time if you’re doing it by yourself, so it’s inadvisable to rush this process. Once you do decide to hire somebody, you should be confident that it is the right person with adequate skills for the job. Hiring remote freelancers, for example, can be a tricky decision, but investigating Toptal company reviews and other competitors to Upwork can help you handle this task.

Issue #3. Neglecting cultural differences

Culture is one of the most precious parts of national identity, and every country is different in this aspect. Just like cuisine varies from region to region, so do the typical business practices that people are accustomed to.

It is unwise to completely disregard these differences, and go about pretending that they don’t exist. If you’re hiring people from different parts of the world, you need to ask about their background, and show respect for the customs that they’ve been absorbing since childhood.

Another thing, which might not be a cultural difference per se but is still related, is different time zones. It’s not only an issue of finding the right time to schedule vital online meetings so that the whole team can attend – although this can become a pretty huge problem by itself.

It’s also an issue of making sure that whenever something bad happens and fires arise, for instance, your infrastructure going down due to a configuration bug, somebody with the right skillset is quickly notified and ready to put the fire out.

What’s more, time differences can affect production in a big way. Most software development teams nowadays use Git, or git clones, for version control and a collaboration tool like Jira to track progress. But tools don’t have the power to organize your workflow – it’s on you to make mission-critical decisions as to how, and for what reasons, new code is going to be added to the codebase.

If you don’t have a unified workflow and don’t factor time differences into the production process, you might end up having developers in various time zones doing the same tasks or fixing the same bugs. It’s unlikely to happen and easy to avoid, but a horrible time-waster if it does happen.


Issue #4. Wrong collaboration tools

Skype can get laggy, especially on video calls, so it might not be best for team meetings if you don’t have great internet. Hangouts are better for video calls but have other limitations. Slack may have taken the tech world by storm, but it doesn’t have to mean that it’s the right chat for all distributed teams. Google Drive is awesome, but it might not be the right cloud for you.

I’ve written a bit about the communication tech stack before, and I continue to mention it because it’s important. As a project manager, you don’t get a myriad of notifications from different apps all day long – it’s a mess, it’s hard to control, and you’ll lose track of things. For a developer, this is even more disruptive, as constant notifications make it very hard to enter a state of ‘flow’ that allows programmers to do their best work.

This goes back to the point where I described procedures. Your communication tech stack can be a part of your communication rulebook or your onboarding. You just need to get the key information in there – which tools are for what purpose, and how to use them in order to avoid unnecessarily distracting other team members (a classic rule is not to use “@all” mentions in chat-rooms unless there’s a very important reason for it).

Final note – be flexible

Even though I wrote a lot about creating rules and procedures in this article, it’s not about making arbitral decisions as to what’s best for your team, and standing by those decisions even when everybody else hates them.In modern software development work, especially while managing virtual teams, it’s always good to maintain an open mind, listen to your team, and adapt to new circumstances when it’s necessary.


Read also

More Arrow right

Calculate the costs of hiring top developers with our free estimate.

No obligation to hire. No commitment from you.

Photo manager
George Fironov
Co-founder & CEO
  • Skype
  • Linkedin

This 20-Minute Call Will Change How You Hire Developers

Discover how Talmatic can help you solve your hiring headaches. In this personalized call, learn how we match you with developers that fit your technology and team needs.

In a short call, we would like to:

  • Learn about your development needs
  • Explain our process to match you with qualified, vetted developers from our network
  • Share next steps to finding the right match, often within a few days

Not sure where to start?
Let’s have a chat