Forget “agile”, can a team function if its members do not speak the same language, literally?
In discussions on how to improve team communication, there is a hidden assumption that everyone at least speaks the same language proficiently.
Never had I imagined how a product team would operate if this assumption was challenged until I worked in a multi-national team with members speaking different languages.
Most of us could speak two languages. And the one language in common was English; but the proficiency level varied widely. I was concerned that we would not be able to get things done due to miscommunication.
Yet, precisely because of this language barrier, we had a unique opportunity to rethink team communication.
Requirements were broken down into smaller chunks
Previously, the product development approach was more waterfall-based. Business teams collected market requirements, then formalised them into request documents.
Product management reviewed the requests, and created corresponding product requirements, which would be reviewed by the engineering team.
However, a language barrier would make this workflow a recipe for a loss of context, missing information, and poorly phrased requirements.
As a result, we moved away from a one-directional approach to a more iterative one where requirements were handled in smaller chunks, with a shorter feedback loop.
We made less assumptions
There were a few occasions where our assumptions resulted in costly mistakes. For example, one side thought the requirement only covered this much scope while the other side thought otherwise. And we only realised this after development had already been well under way.
Combined with the approach of breaking requirements down into smaller chunks, we had become more mindful of the assumption trap.
Double clarification and regular check-ins with one another were ways to make sure we were on the same page.
Low fidelity mock-ups were frequently used
We drew mock-ups, diagrams, and had loads of screenshots in order to aid our verbal explanation. Initially, this was more of a necessity than a choice because everyone’s command of English was different.
But unknowingly, they became low fidelity prototypes that helped us gather feedback.
Want to build a promotion center where users can discover all the promotions offered? Find it difficult to explain the idea in English? Draw it out! Let other people see it.
Want to ask for comments on the user experience of a new feature, but cannot describe everything in words? Make a clickable prototype, and let other people experience it.
In fact, making visual mock-ups was no longer exclusive to the designers. Everyone was empowered to do it.
We saw strength in our differences
Having diverse cultural backgrounds gave us a golden opportunity to relook at what we thought was intuitive to us.
For instance, teammates from China who were accustomed with a more crowded app interface could suggest a visual design that was similar to what they were used to.
Teammates from Southeast Asia could offer a different perspective on how certain markets tend to favour a cleaner interface with big visual elements.
Another example is in the adoption of payment via QR code. Because QR code scanning was common in China, while it was relatively new in Southeast Asia, there were plenty of learning points in product design we could pick up from the apps in China.
Instead of being confined to one way of thinking, we had a richer collection of market references and perspectives.
Conversations were open
Given a different environment, I would have kept quiet and nodded along if I did not catch all the points being made in a meeting.
But in an environment where it was easy to have miscommunication, saying “I don’t understand this part”, “can you repeat”, “could you explain again?” or “is my understanding of so and so correct?” was welcome and encouraged.
It was unavoidable that team members would not want to speak up in a more formal meeting setup because they were afraid of making language mistakes.
This led to more frequent conversations within smaller cross-function groups where we shared our roadblocks, clarified on requirements, and chatted about new ideas. It allowed us to be more open and to get in sync with one another faster.
Last but not least, there was hardly room for politics
It was challenging enough to be understood in our work. Simple and clear English sentences were used to minimise mistakes (and also to make it easier to Google Translate).
Even if you wanted to be “extra”, to “throw shades”, or to be provocative in your words, other people might not catch on.
If anyone ever came across as rude, we always gave the person the benefit of the doubt that it was the language problem. The fact that we would not take offense easily made politics almost non-existent.
Final thoughts
My pessimism about a team breaking down over language barriers was proven wrong. That does not mean there were no missteps along the way. There was still room for miscommunication, frustration when one felt not understood, and inefficiency when things had to be repeated and confirmed multiple times.
But this experience had taught me that language was an important factor, but not the determining factor, in building a cohesive team.
If there were a desire to connect to another person, we would surely find ways to understand and be understood.
