Building an English Speaking Culture - Up and Down

Source: http://dilbert.com/strips/comic/1996-06-01/

Build an English speaking culture, because why not?

One of the most controversial decisions I made during the time I served as the head of Coder, Inc. was to use English in all forms of communication within the company. And it was so controversial that, until today, I keep questioning the correctness of the decision. Hiring people who are fluent in English and making them use it in their daily communication is unconventional, and in fact I believe that this idea rarely crosses the minds of the executives of companies in Vietnam. At the same time, I gained personally and professionally from the choice of language. Let me tell you my story.

When we first started Coder, Inc., we did not use English. After the first 2-3 months, there was a time that we were on a conference call with a client and we were all surprised by how rusty our English had become. Just like how people work out to keep themselves in shape, we started looking for a way to strengthen our communication skills. And as we were all RMIT alumni, the idea of speaking English all day long came naturally. We thought, "Hey this is cool, I don't think there is any other company doing this" and we decided to keep doing it as part of the tiny little organization we were building.

The pros

Because the decision was made at a very early stage, speaking English had extended itself into various aspects of the company, even before we'd fully realized it. The following points explain the impact of speaking English on our culture.

• One of the things we had been discussing was how working at Coder, Inc. helped an employee increase her personal and professional values. If fluent communication in English is not valuable, I don't know what is!
• Speaking English eight hours a day was not easy. Firstly, we all had these funny Vietnamese accents. Secondly, people hard learned a pretty academic version of English so they were not familiar with actual daily conversation (try describing how your favorite dish tastes -- I still have problems with that now), or slang (who knew what "klam" in klamr meant) or jokes (yo mama jokes, anyone?). This was a part of the learning process for everyone joining us, which, I believe, embraced the core value of the constant pursuit of growth and learning.
• Employing someone without sufficient English skills meant we needed a buffer layer between developers and clients. Those who spoke directly to client would have more insight about a project than those who didn't. This eventually would lead to hierarchy and compromise the flat organizational model we were applying. I was not a big fan of hierarchy as I saw it preventing people from operating at a higher level then where they currently were, which was yet another selling point of working at Coder, Inc..

Most importantly, it gave us a distinct brand. We were a small team of fresh graduates doing outsourcing in a country where the main revenue of software industry was, well, outsourcing. Building an English-speaking culture was an easy way to differentiate ourselves and give people something to talk about. With that under our belts, we managed to compete with companies that had been around for longer and had spent more money on recruiting. There was a semester at RMIT when out of 20 students we got 18 internship applications (we ended up picking 2).

The cons

You might be telling yourself that hiring only fluent English-speaking developers is nuts, these people aren't public speakers, they are programmers, their job is to code, not to communicate, and by doing so, I restricted myself to a smaller pool of talent. And that is true. But the small talent pool was not the problem for me. Coder, Inc. was not a gigantic multinational consulting firm, it was a twenty-something-developer outsourcing shop. The number of applications I received every month was between so many that screening and interviewing time alone ate up my entire day and too few that I had to desperately look for new sources of talent.

As it turned out, the blessing of working directly with clients was also a curse. Coder, Inc. clients were mostly entrepreneurs looking to get their ideas implemented at an affordable rate. Under the name of lean startup, fail fast - fail often, and responding to market trends, entrepreneurs had the tendency to conceptualize, change and twist the project vision in every possible way. While this energy was exactly what was great about entrepreneurship, it placed an incredible demand on software engineers, who were asked to write, test and re-write the code, all over the course of a few days.

Many engineers Coder, Inc. employed at that time were talented, energetic, and passionate. They engaged in discussions with clients with both curiosity and eagerness to build something great. But as time went by, unstable requirements, code reconstruction and midnight calls drained the energy out of these youngsters. They got burnt out. I personally at the peak of a high-demanding project, got to be very grumpy and thought about dropping everything more often that I would like to admit.

In this case, the thing we tried to remove was the very thing we needed: a buffer layer that shielded the developers from the clients' whim, allowing them to focus on their work and be productive.

The second problem with the English-speaking policy was rooted in my own voluntarism. It didn't occur to me that what worked well when we were a group of 5 wouldn't work when we scaled up to the size of twenty. And I thought what was good for me was good for my employees. An act that in retrospect was naive, conservative and stupid.

As we grew and sought diversity, we hired new people who still had great English abilities, but had little experience using it as a primary language. They would study English in a center two or three times a week, but had never spoken the language for an entire day. And it was hard. When confronted with such a challenge, it was natural to switch back to the language they had practiced for decades and knew inside out: Vietnamese. Rules are supposed to guide people to what they want, not prevent them. When that happens, rules will eventually be broken. Gradually, within the team, Vietnamese gossip groups formed and became the source of much unwanted office politics. So in an attempt to remove a formal hierarchy, with title, scope of responsibility, and everything corporate, we found ourselves in an informal and intangible hierarchy of politics where the flow of information was blocked, twisted or altered to serve personal interest. The rest is history.

Conclusion

Though it is painful for me to look into the past and see things that I had done wrong, it is extremely important to learn right from where I failed. In my opinion, Coder, Inc. would have been in a better state if either:

• A suitable process had been set up to manage projects and find balance between client's interest and engineer's sanity.
• The pace of recruitment had been slowed down to ensure one new hire had time to adapt to the new culture before hiring the next one.
• The English-speaking policy had been removed when the team decided to scale up.

What has been done cannot be undone. I learned that building an intensive English speaking company is hard, and requires the right people and the right process.

There's a different between knowing the path, and walking the path. - Morpheus