Friday, October 3, 2014

Building an English Speaking Culture - Up and Down


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.


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


  1. I’m not sure why my previous comment does not display, anyway I will re-post the summary…
    Sorry to hear that your English policy was discontinued. I used to apply the same for one of my project though it’s a less strict policy, it failed too. I keep asking why and seems like I find something.
    *Most of technical guys (in this case your developers and in my case my testers) believe that technical skills (hard skill) is enough for them to do the work. I admit that technical skills can help do most of the cases but not always. Those developers need to learn a skill how to articulate their work to customers. If they can write brilliant line of code but they fail to communicate their values, how come people can value them.
    *Developers/Testers are really smart guys and I believe they have no problem with English, it’s just they don’t want to practice because they don’t see the value in doing that. Many people tell me that it’s the problem of mindset. I don’t agree. Most of programming languages are in format for human/communication English. If a developer can write a clean/clear and readable code, I believe they can learn and speak English as well.
    I can do something from my end to motivate them but the working part lies in the other end, their end, their self-motivation.

    1. Not sure why the last comment didn't make it. This is the only comment made its way to my mail box (and I don't apply any moderation on this blog).

      The English policy didn't discontinue when I was the head of the company, it did half a year after I left. So I don't think the problem at Coder, Inc. was beyond saving, but certain bad seeds needed to be let go.

      I think it is actually easier to enforce an intensive English speaking culture, than doing a less intensive version, like a few days a week, or during official meeting only. As I mentioned in the post, given an opportunity, people natural tendency is to fall for the easier thing.

      I also believe having a small in influencing core team who share the same vision with the policy maker is very important, they ARE the culture.

    2. I see your point and your strategy sounds like "do things the hard way". It seems that both intensive and less intensive ways do not work out. I'm curious to know if there's someone out there succeeding in building English speaking culture professionally and naturally.

    3. It managed to last for 3 years in Coder, Inc. haha. But yeah I haven't seen any other team manage to push thing further than a couple of months.

    4. 3-years is impressive to me. I consider it a success.

    5. Many years later and you know what works? I had a French girl joining as developer and everyone started speaking English one way or another.

  2. Is there a reason why you just copy and paste Dilbert cartoon without citing the source you got it from?

    1. Because everyone know it is Dilbert? Anyway I updated the source and made a mental note to myself

  3. "Because everyone know it is Dilbert?", that is your assumption, and even if everyone knows that still do not allow anyone to just use it. Just because someone said/did great work don't mean you can use it without proper citation/credits/sources with this assumption that everyone might know who it is from. But I am glade that you are a man of understanding and rational, you changed it without being offended.