4 worst mistakes in managing distributed developers.
Even though the work seemingly remains the same, there’s a lot that changes when a project manager makes the switch to work remotely.
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.
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.
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.
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 remote developers, 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.
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, are 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 organise 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.
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 is better for video calls, but has 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 to 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’ which 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 on-boarding. 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.