Remote teams have become the norm, rather than the exception, for many companies requiring software engineering services (and not only).
They used to be just a small addition to the core, in-house team, but it is not uncommon for them to now represent the bulk of the development force.
It's not always the case of a company hiring a third party to do the job, sometimes it's just having to coordinate multiple teams of the same company, operating from different locations with different time zones.
There are multiple reasons for this choice: cost, multiple company locations to manage, strong talents availability in less competitive markets, strategic choices and so on.
Hewlett-Packard (HP) uses these teams to meet the demands of local economies across the world, and as an HP executive states
We are very dependent on working across the world. It’s our survival, the key to our success. We cannot be a U.S.-centric organization… It’s very common for us to have one project team made up of folks from all of our regions
“No Borders” 2005, p. 37
While having remote teams usually brings down the cost considerably, it comes with its own set of everyday challenges that can outweigh the benefits if not properly handled.
Distributed teams are the subject of active research that questions the extent to which face-to-face and in-person communication is necessary for distributed teams to function effectively and why: empirical tests show that the answer may depend on which team processes and outcomes one is exploring and how distance is measured (Geographical? Cultural? Time zone?).
Essentially, the challenges of distributed teams fall in one of the following categories: degree of virtuality, degree of distribution, history of the team, degree of (im)permanence, degree of task complexity. Following are a few points that I found helpful in my experience with working with multinational multicultural (MNMC) distributed teams and that directly or indirectly address the aforementioned categories.
Listen, listen, listen. Then act
Communication in a co-located team happens as a result of people sharing the same room at the same time: a side effect of sitting together is feeling more comfortable in sharing ideas and raising issues.
Working from the same office means ignoring a whole set of issues around distributed communications that can bring productivity to a halt when working with people in different locations.
The key point in this scenario is to make everyone feel empowered to report problems that would otherwise affect everyone. One way of doing it is to show how serious we are in tackling those issues: listen carefully, then act effectively. Showing care builds trust.
If the microphone is not working during a meeting and it is being reported by the people on the call, stop and fix it, change it, or change room. Do not resume the discussion until the problem is fixed: losing input from a whole part of the team is much worse than stopping the meeting for a few minutes (or even moving it to a different time).
Choose your communication tools wisely
The first step in setting up to work within a distributed environment is to have the right tools in place.
It is vital to make it easy for people to communicate: you don't want to add any additional barrier to those already created by the distance.
Whether people sit in the same office or not, you need a tool to organise and track the work: Jira and Trello are the most widely used solutions nowadays, pick the one you and your team like the most, no big deals here. I love physical boards and sticky notes, but they are just not practical with distributed teams.
Slack, Teams, Skype are all valid chat/conference call tools that given a good internet connection, will do their job: it's just a matter of preference. Choose only one tool though, so the chances of discussions getting lost are minimised.
Make sure you invest in good headsets: I found Sennheiser PC 5 CHAT to be cheap and work perfectly for internet calls.
Buy the right hardware for your meeting rooms: if you work with Macs, I found Apple TV to be very helpful when it comes to sharing your screen/audio during a call. Another option may be to use Chromecast. Also related to setting up your rooms, having a conference speakerphone can really make a difference when many people are sat around a table and far from the laptop: Jabra Speak 410 proved to be effective for this in my experience. And don't forget a good 1080p webcam!
In my experience, I found that meetings with everyone in the same room sitting around a microphone are not as effective as meetings when everyone dials in from his/her desk with their headset on: you always end up having issues with people sitting too far from the table and not being heard. My suggestion is for everyone to dial in from their desk, regardless of how many people are involved in the call.
If your employees are not co-located, then treat every meeting as remote and strive for:
- frequent communication: frequent, spontaneous communications mitigate the effect of distribution on both interpersonal and task conflict and are also linked to highest trust
- face-to-face communication: perceived as critical early on in a team’s development and seen as a behaviour that will enhance MNMC team effectiveness (although as time goes on and team members become more familiar with each other, non-face-to-face communication don't seem to hinder team's dynamics)
Communicate early, communicate often
With distributed teams, it is important to learn the value of over-communicating: when decisions are made, they need to be communicated immediately to everyone, along with the reason behind the decision. It's important that everyone has a vision of what is going on in the organisation and the role they can play in making that vision become a reality.
The risk of teams around the globe working on outdated/wrong information is too high to delay the communication process: make sure everyone always have the latest updates and can adjust their job based on that.
Hire a developer advocate
A developer advocate is someone who makes other developers' lives easier: too often developers are busy shipping feature and can't spend time improving their development experience, that's when a developer advocate comes in.
They can:
- automate tedious tasks
- prepare "Getting started" guides for new hires
- prepare guidelines for bug reports and troubleshooting how-tos
- help with the definition of Done and Ready
- structure code reviews
- define coding standards and find tools to enforce them
- improve the deployment process
- the list goes on
All this with the aim of increasing productivity and improving the developers' lives (which leads to better retention, btw).
The above points become much more important with distributed teams: given that fast communication is not always possible, having tools and guides in place can make the difference between getting stuck for a day or being able to progress to the next task.
In general, embrace simplicity and automate whatever possible: the simpler your projects are and the easier it is to work with them, the more productive developers will be. You want to keep the cognitive load as low as possible: co-locate documentation with code, create standards for all teams to follow, enforce and document them and let everyone know, organise workshops and "sell" these concepts to everyone.
Clearly define and document roles
You can expect people from different teams to have never worked together before so it is important that everyone in every team know exactly the complete hierarchy with names, photos and ways of getting in touch. This way everyone will always know who to get in touch with depending on the issue they're having or the information they're seeking.
This diagram would also outline a clear escalation path if an issue arises.
Write everything down, always
This is a rule that everyone should follow, whatever the team nature, but it becomes vital when people are not co-located.
Important discussions don't (can't) always happen during conference calls, decisions are made during a quick lunch, ideas have the tendency to reveal themselves to us at the most peculiar times, but we need all the team to be involved and everyone to know: that is why comments in Jira/Trello are so important as they give everyone visibility over the work that's being done.
Use the comments, update stories/cards often and use your product management tool as a source of truth for everyone.
Enjoy the pleasures and pains of time zone differences
Multinational multicultural distributed teams present opportunities and challenges to organisations: having teams working in different time zones is usually seen as a problem because people have a hard time organising meetings where everyone can attend and issues are resolved slowly because of lack of quick communication.
Although this definitely represents a challenge, it can also represent an opportunity to prolong the work cycle and increase velocity. In such an environment, blockers can be passed to a fresh pair of eyes at the end of the day and possibly get resolved by next morning, something that would be impossible when following the same working hours.
Of course, it all comes at a cost, and teams situated in different time zones require more preparation.
To remove all possible issues and blockers, make sure you:
- spend time during your day (and before their day start) to organise work and detail everything to limit the unknowns and make every team a self-sufficient unit
- review code or designs as soon as possible
- leave actionable feedback in the comments
- ensure they can be as independent as possible during their day and always plan more work in advance so if anything comes up they can progress to another task without getting blocked
- find the golden time when everyone is online and move stand up to that time. If the time difference is really relevant, you may only have a small window of time: use it to make everyone meet and have at least standup all together
- structure your teams as if the whole team was remote: there are not first-class citizens working in a central location, everyone is a remote worker
- Alternate time zones: if you need to have meetings at inconvenient times, make sure you make it "inconvenient" for a different team each month
- have people from different teams having informal 1:1 once a week: this helps to build relationships and trust, making it easier in the future for everyone to communicate issues and blockers without fear. Make a rule to not cancel them because of a "more" important meeting
Respect and embrace cultural differences
Globally distributed teams will be effective vehicles for knowledge sharing in an organisation as long as individuals learn the cultural logic of others’ divergent beliefs. If not, culture is constructed as something which divides individuals.
Multinational and Multicultural Distributed Teams: A Review and Future Agenda
When working with people living in other parts of the world, there is so much more than a cold colleague-to-colleague relationship to be experienced: I am always impressed by the differences in the way of working and living that I get to experience whenever I work with a new team.
I always make it a priority to get to know and experience their culture as much as possible: be it food, architecture, history. Every country has something peculiar that can spark my interest and that enriches not only me as a person but gives me a common ground to create a better environment at work. Just by looking at specific traits of a country can reveal so much about the people I am working with and, needless to say, helps a lot with the daily work relationships.
Knowing people personalities, habits and needs will help you with the daily organisation of work in a way that can improve productivity and boost team morale: people that see their culture respected will inevitably be happier when working with you. This may mean adjusting your communication patterns to use/avoid words or phrases that may be offensive, moving meetings to avoid specific parts of their day.
If you're interested in finding out more, Managing Cultural Differences in Your Distributed Team is a good read.
Experience their culture in person whenever you can, aka invest in airfare
There is something unique in meeting someone in person and breaking that electronic barrier.
Interactions that happen when working in the same office are impossible to reproduce when teams are distributed, so you should try to get all your teams together as often as possible, not only to talk about work, but (mainly) to have fun and get to know each other: common experiences are the building block of trust and the return you get from it far outweighs the airfare to get everyone in the same place (well, maybe not for big companies).
The simple act of tapping someone on the shoulder releases oxytocin and improve a person's feelings (reduced stress, increased happiness, improved communication).
Make sure to budget for travel and you'll experience increased productivity from day one.
It's not all about work
Thanks to Hugo Raymond for the help on this paragraph.
Think about all the micro-interactions you have on a day-to-day basis that make where you work an enjoyable place to spend the best part of your day: how do you replicate these when working with distributed teams?
The first, obvious answer is to try and spend time together, in person, but this is seldom achievable for companies with multiple teams.
Another way, that can work every day and build lasting rapports is to use your communication tool (Slack, Teams, whatever) and create a safe place that everyone can access: create a "Fun" channel and let people create sub-channels with things that interest them. It could be a book club, where every week people from around the globe share the book they're reading, review previous ones and give suggestions to other people. It could be a photography channel where photos are shared and commented, the latest gears discussed, tips are given. There could be weekly or monthly assignments like "Still life" or "Autumn leaves" where people from around all the offices share their pics: a wonderful way to show the diversity and beauty of different countries.
To some this may seem like "organised fun" but you only need a few passionate champions for those who are interested in the social part, to engage, for it to then become a success.
If you read until here, may as well watch this!
Jilanna Wilson keeps the love light burning for a team that is spread across 5 continents and 8 time zones and shares some of her knowledge in this video from the DesignOps Summit 2019:
Good luck, and ❤️ your remote teams, they're good for you!
References
- https://www.atlassian.com/agile/teams/remote-teams
- https://djangostars.com/blog/how-to-manage-a-software-development-team-across-time-zones/
- https://pdfs.semanticscholar.org/e3b9/57e8c1f6a286ce3b8876c12701a073a8f0c5.pdf
- http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.452.8295&rep=rep1&type=pdf#page=239
- https://onlinelibrary.wiley.com/doi/epdf/10.1002/j.1681-4835.2002.tb00040.x
- http://www.ineer.org/Events/ICEE2004/Proceedings/Papers/430_ICEE_2004_final_(1).pdf
This article was originally published on onefiniteloop.io
Top comments (0)