This Day 10 post of Merpay Tech Openness Month 2022 is brought to you by @Tim, Engineering Manager of Merpay KYC team and Balance team.
If you manage multicultural Tech Teams in North America or Europe, you’re probably defacto opted for the usage of English. Well, that’s the computing science language after all and generally not really an issue as most people in tech speak English to a certain level.
But what happens when people do not speak the same language at all?
SOME BACKGROUND
First I have to tell you how it started. English is not my first language, but having worked in France and UK with teams composed of people from Israel, Spain, Argentina, China and basically all around the world, I got pretty used to the idea that for the rest of my career in engineering, I’ll probably only resort to the usage of English. Well, that, my friends, is called a bias and I’m still pretty much working on it.
I still remember that at the time of my last interview stage, I asked Hidek-san (Hideo Kimura, VP of Engineering) “Is the integration going to be easy for a non-Japanese speaker like me?”
The answer was brutally honest and straightforward: “No, it will not”.
I did not really realize what it meant yet and mostly relied on my experience of transitioning from a French-speaking work environment to an English-speaking work environment to assess the situation. Well, actually he was quite right.
I’m not going to go too analytical on the reasons why, but to depict you the engineering environment back in the days, Japanese was definitely the principal language in most of the teams for most of the things. By that, I mean Slack discussions, tickets and specifications, architecture design documents, onboarding material… Basically, a lot of things you would consider part of the “starting package” got out of my reach due to the language barrier.
As you can imagine, my productivity tanked “a little” and getting engaged in projects outside of my direct assignments was requiring much more effort than ever before. Thankfully to my awesome teammates and the organization itself, I received a lot of support, having the extra luck to work directly with people that pushed their limit to use English, while some other parts of the company were still using Japanese heavily.
Don’t get me wrong. This is far from an uncommon situation in Japan and actually, we were already doing pretty good compared to many out there.
Still, many in the company felt we could do more to create an inclusive environment for non-Japanese speakers, and two Engineering Managers suggested that I join them to work on fixing the issue.
START BY DOING WHAT’S NECESSARY
The first thing you need to understand is what you’re trying to achieve and why you do it. No magic and wonder over here. Our reasons are simple:
- To build a strong organization, we need to ensure that everyone can participate in the decision-making process
- We aim to be a truly global group and expand outside of Japan but in order to do so, we need to recruit more experienced people than what we can find by only targeting people available in Japan
- None of this can be achieved without an environment that takes into consideration the different levels of language of our members
Everyone is the keyword here. The purpose is not to transition to a common language by omitting the members not able to speak this newly selected language. Basically, just replacing Japanese would just recreate the same issue with another language. So yeah, we need a form of cohabitation where Japanese would exist with the newly selected language.
From here we know the what and the why but before moving to the how, we still need to understand a few details, the most important one being the current situation.
And this is why we came up with the English-Inclusiveness Evaluation System. I like long titles.
To summarize, it’s a tool to help us measure English usage in Merpay engineering teams. It shows at a glance where each team stands when it comes to communication in English and what are the areas where we could make further progress toward our company’s ideal of inclusiveness.
INCLUSIVENESS LEVEL AND CATEGORIES
This inclusiveness assessment is defined by 8 categories. The meaning of each category will be explained below, but the important thing to understand is that each different team’s overall English inclusiveness level is defined through the sum of progresses in these categories.
We decided to create three progressive levels, Bronze, Silver and Gold, in order to get a clear picture of the Team’s situation at a glance, which we can roughly summarize like this:
-
Bronze: Many necessary documents and / or communication exchanges within this team are in English. Loss of productivity for Non-Japanese speakers due to language barrier should be low but still exist.
-
Silver: This team has made great efforts to use English as a primary language. Some documents or communication exchanges might still be exclusively in Japanese.
-
Gold: This team fully operates in English. Non-Japanese speakers will have absolutely no issue of understanding or integration.
About the categories, these are the ones we use:
-
Written Communication, which is about written and asynchronous communication exchanges within the team, including Slack and mails.
-
Meetings, which is about meeting documents such as meeting minutes, type of interpretation provided and language spoken during meetings.
-
Product Documentation, which is about the domain introduction documents from a product point of view, its edge cases, the system workflows and external vendor documentation.
-
Project Specifications, which is about the ticket specifications, acceptance criteria, QA plan for each task, system architecture documentation and technical proposal.
-
Team OKRs, which is about the team’s objectives document, roadmap or milestones.
-
Technical Documentation, which is about the code documentation, project Readme, API Documentation and code comments and pull requests.
-
Onboarding Documentation, which is about the new member onboarding documentation, explaining how to participate in development, the release procedures and coding standards.
-
OnCall, which is about the team’s playbooks describing how to react to potential alerts received while OnCall, the incident reports and post mortems and what language is used in the Incident War Room and during Incident handling discussions.
I’m not going too deep in the details for each category because basically, that’s something you need to adapt according to your company tools, standards and processes. What I can tell you though, is that finding the common denominator between each team might be challenging. The bigger your company is, the more likely everyone will adopt standards freely or develop specific processes only inherent to them. Ultimately, that’s something you can find out by discussing with members of your organization. Get support, don’t do things on your own.
Once you have defined relevant categories you just need to check what’s the situation for each team. No need to gather everyone, but having a discussion with the Tech Lead for the engineering side and a PM for the product side will help you understand things better.
SOME OBVIOUS FINDINGS AND A NEW PROBLEM
Once we had this done we could already notice big disparities. Some teams were quite advanced in English usage while some teams were still exclusively using Japanese still. What we found out is that:
- The size of the team and domain were not necessarily relevant to explain these differences
- The presence of a non-Japanese member in the team helps with the situation in most of the cases
Sounds obvious but at least we were sure about it.
Nevertheless we reached a kind of chicken and egg situation:
- Having a non-Japanese speaker in a team would trigger a change, creating a more inclusive environment
- To welcome a non-Japanese speaker in a team, we wanted the team’s to be ready to welcome them, having already an inclusive environment in place
To solve this issue, we moved to the second step of this project. Purpose was to know:
-
What should we define as the minimum threshold at which we can consider a team to be inclusive enough so that any engineer joining would be proficient in their work day one
-
What steps and actions should we take to bring all teams to this minimum level with a minimum effort
This article being slightly long already, I will dig on this topic in the next part of this series about the creation of this action plan we called the “Inclusive Teams Initiative”.
Thank you for reading!
