Lesson Learned: Working With Teams Across Borders

More and more companies are working with diverse teams and customers across the globe. This used to be exclusive to multinational corporations who had budgets to fly people around in business class, provide hotels or use expensive video conferencing solutions. But nowadays any startup can do it with simple strategies and (mostly) free online tools. I want to share with you some tips & tricks for what we’ve discovered in the last few years about working with teams across many borders.

I'm one of the cofounders and CEO of a dev company called netguru. We have a team of 100 people. We offer web and mobile development services to clients in more than 15 countries on 4 continents and in 5 different timezones (not including daylight savings time that confuses everyone twice a year). We run more than 30 projects concurrently and almost all of them are with clients from outside of Poland.

Our lessons learned are by no means complete. I'm sure we'll be learning a lot more of those lessons and some of them probably the hard way. But here are the ones we’ve got expertise in:

Trust

The main thing I want to focus is trust. It’s one of the most important yet trickiest parts of running projects in international environments. In more traditional relationships, we establish trust by spending time together, by looking for visual cues about the people we work with, their personal priorities, strengths and weaknesses. With distributed teams, we don't have this opportunity. I often say that life would be much easier if people would be a bit less like ....people. Unfortunately (or rather fortunately I'd say) people are people.

We have emotions, we like and dislike certain things or certain other people. We have our personal and national histories, religions, political beliefs, customs and traditions. Most of us like to spend time with people who share those. In cross-border teams this is not possible.

Trust

A lot of the times (and we have those experiences as well) we tend to forget that we need to build trust across ALL of the stakeholders of a project. This means:

• obviously the team
• project managers

but also

• product owners
• managers, CxO, VPs
• actual shareholders and investors
• consultants

This is a so often overlooked. Having people on "your side" (and by "your side" I mean "the projects side") can go a long way in times of crisis - and I can assure you - there will be times of crisis.

Let’s look at some basics of building trust through communication:

Language

If you have at least one person on your team that does not speak your native language, switch to English and never look back. It may be hard and awkward at first to write email, documentation & all the other materials in English, when most people speak your mother tongue - trust me - it’ll pay off.

Shared Tools

Just like we need to speak the same language in a “human” sense we also need to speak the same language in terms of the tools we use. There should only be one project management, time tracking tool, one code style guide, one chatroom, one wiki page and so on. There is nothing more confusing than people assuming that we are using a certain tool just to realize half of the team was assuming something else. And please stop using paper / whiteboards / post-it notes. It’s 2014 (almost 2015!), and while you are free to use whatever you want for your personal need make sure that whatever needs to be shared is in electronic form.

Open Communication

Everyone should have direct access to anyone. Have a shared address book or a wiki page where all people are listed along with their responsibilities, contact information (email, skype, facebook, phone - whatever makes it easiest to communicate with them). Don’t introduce gatekeepers - again the technology is now in a place when everyone can set up proper filters and guard against information overload on their own.

Trust

Face to Face Meetings (informal ideally)

I’m a huge fan of remote work but as much as possible, we try to get all appropriate stakeholders in one room at least once, get them out for lunch or dinner together, go out for beers (if they drink) and maybe even sing some karaoke ;) While working remotely and without seeing each other everyday is absolutely possible and productive we found that having a face-2-face kick off meeting (right at the beginning or sometimes a few weeks into to project) can have great positive influence on the team.

Frequent Videoconferencing

Sometimes meeting face to face is not possible or not practical. The next best thing is videoconferencing. Some people are not comfortable with webcams, but they’re going to have to be. I encourage you to convince them (peer pressure works very well - if everyone shows their face it's hard to be the outlier). Make sure you have decent hardware & software that supports it well. We use almost exclusively macbooks - one of the reasons is the quality of sound and camera - it just works.

Delivering Quick Results & Quick Wins

When starting a project with a distributed team it's very important to be able to deliver the first deliverables (no matter how small) as soon as possible. I don't think I can stress this enough. We've seen this so many times. Lack of results in days, week or even (it sounds insane even when I say it) months is the best way to loose any kind of trust you might have very very quickly. Every small milestone counts. You've set up a project management software - make sure all the stakeholders know it and have (even if only read-only) access, filled up a backlog for next iteration - again - everyone should know. Send emails everyday until someone says "Thanks - I don't need to know that - I trust you guys".

Be Proactive In Communication From Day 1

This is a good segway to another best practice which is over-communicating from day one. You might think everyone should know all the details of the project goals, milestones, tools, etc. But It's worth reminding all stakeholders about those little things often. Especially in the beginning asking followup questions, being very diligent in collecting requirements goes a long way - until people feel comfortable with each other work & priorities it's better to ask twice than not to ask at all.

Trust

Once we establish some basic level of trust, we need to constantly maintain it and build upon it. The tools I've already mentioned work great also as a way to maintain trust. I want to add a few more on top of it.

Transparency

This is something that we believe in very strongly. The bigger the team and the more spread out, the harder it is to keep up with the changes and project progress. This is why it's important that all stakeholders can see the status of a project on their own at any time. We have a group email which goes to the whole team and we CC most of the emails related to the project. It's easy enough to set up appropriate filters on the client side and not worry about email overload.

Weekly Planning & Releases

It's hard to find a piece of software these days that cannot be improved within a week. All of our project have weekly iterations - this means that every week the team is able to show progress. Some weeks the progress is more visible, some weeks perhaps less, but small iterations have proved to be a very important tool in "maintaining trust”.

Staging Server

We go a step further than most - we give access to a weekly build, and also encourage stakeholders to play with an unstable daily or even "realtime" builds. It will have bugs, and it will crash, but it's another way for everyone to see the current stage of the project.

Status Reports

Not everyone has time to track the changes themselves (this is usually true for upper management, shareholders & investors). We believe they deserve to know what's going on at a higher level. A lot of the times we'd send monthly status reports to all stakeholders including the ones that are "highest" in the organisation.

We’ve gone through a good number of tools & strategies for building trust in diverse teams and distributed teams. You’d probably ask - how is it different from working in a less international team? It’s not. Two biggest differences are that

• it’s much later that you’ll realize that you’ve made a mistake when you make one
• and the price you pay for not following those best practices are much higher when the team is not collocated & international.

This is why we found that one needs to be especially proactive, conscious & systematic in their approach to teams across borders, as its the only way a remote team can achieve success.