One year ago I took the most challenging decision of my software development career. I quit my daily – 40hr/week job and joined a company as a remote freelancer. That change was even more radical because I made the switch from a hands-on developer role to a “software engineering manager” role. Although I don’t like the term “engineer” for software development, that’s my current role/job description. My key responsibilities are around managing many development teams by focusing on automation and quality. What’s really awesome and at the same time extremely challenging is that all team members are located in every possible place around the world.
In this post I will share my so far personal experience and some things I learned the hard way when it comes to manage global teams.
Let’s face the truth. Remote working is an increasing trend for several startups and ‘traditional’ companies. Personally I think that in the near future more and more companies will switch to this new model of recruiting. Hiring people globally decreases costs but it hides a lot of risks and difficulties, especially when it comes to manage all those remote workers. Here are some of the most important challenges I faced:
Different cultures
Everything I knew – or I believed I knew – about human relationships and the way that people handle common situations in a software development team collapsed from one day to another. You don’t know how people react when they hear something that you consider normal but to their ears doesn’t look the same way. The fact that you don’t speak your mother-tongue make things even more fragile. Words have different meaning in some languages and many phrases are not fully understood. To be honest, in the beginning I struggled a lot! After some time I found out that one of the keys to overcome this problem is politeness and clearness. Whatever you want to say, try to be polite, calm, confident about the message you want to pass and as much as clear you can. It’s very likely that even if people are somehow offended from what you said, their reaction will be less hostile and they will be more willing to cooperate. You want also people to understand the full details – not just the general idea. We don’t write software by understanding the general requirements, right? We need the details!
Absence of face-to-face communication
One of the biggest problems I faced, especially in the beginning, was the fact there was no direct communication, no face-to-face meetings with the team members. How the heck was I supposed to manage all those guys? Fortunately the answer was in front of my eyes and I quickly realized that you can perfectly replace real meetings with virtual meetings. All you have to do is use the proper software, have a very good internet connection – this is very important for video calls – and finally setup periodical meetings. Daily meetings to catch current activities and remove possible roadblocks, weekly meetings for planning and demoing internally the progress and one meeting every month to demonstrate the status to stakeholders, product owners or whoever has interest on the product/project the team is working on. Yes, you are right, It seems to be a typical scrum meeting schedule with some adjustments. I made also very clear from the first day that everyone should attend the meetings, otherwise the team will not have the minimum level of communication.
Time-zones
One of the teams I manage is composed of a developer located in Latin America, another one in China and another one in India. And me, I’m somewhere in the middle – Europe! Things can ge get even more complicated if you consider the fact that some of these developers have a “daily” /office job that reduces their availability to certain hours. Like I said, I needed to setup daily and weekly meetings. No silver bullet here. When you work remotely you have to accept the fact that some meetings might not be during the typical working hours. It’s one of the prices you have to pay for getting the flexibility of a remote worker.
Performance evaluation
People, by nature, lose easily focus. It’s even worse when you work in your home instead of a typical workplace environment. To avoid such awkward situations and make sure that all team members are productive you need to set goals. Team goals and individual goals. Weekly, monthly and quarterly goals. Goals should be clear to everyone. But the most critical part here is that goals should be quantifiable and objective. The way you measure them is shared to all team members and it cannot be disputed by anyone. Then you will be able to rank your developers and maybe replace the worst one ;)
Collaboration Tools
Meetings are good to keep team members synced and focused on their goals. However they cannot completely replace work at office . It turned out that in order to allow people to collaborate – just like the do in the office – we need tools. Fortunately we have a plethora of them. To be honest the tools that we use in a typical working environment perfectly fit in distributed teams. Starting from the typical ones : Issue tracking system, wiki platforms, code review systems and…. chatting rooms. The choice of the correct chatting / collaboration tool will probably make the difference. What I strongly recommend is slack. The reason? You can do exactly what you can with traditional chat systems like skype, msn etc. and additionally you can integrate with numerous external systems like google docs, jira, jenkins, github just to mention a few. Cool features like channels and private chat rooms with full search capabilities make it even more attractive. After working with slack for more many months I can’t imagine my life without all these information that can be found in one single place.
Well, that was only the beginning and I could write a series of blogs for each challenge I faced or even a whole book – hey that’s a good idea! Who knows. Now that I’m a flexible remote worker I might find the time to write another book!
| Reference: | Managing Global Teams – Lessons Learned from our JCG partner Patroklos Papapetrou at the Only Software matters blog. |
