In 2013, I set up a company in Ho Chi Minh City, Vietnam. It started with about 30 people as a subsidiary of a Japanese web development company, and eventually grew into an organization of 50 to 60. Here I look back on what I made my top priorities in those first few months.
Starting a Company Where There Is No Shared Context
When I worked in Japan, I was a player-manager. I did hands-on work myself while also giving instructions to my team. As in many Japanese companies, I was both a player and a manager.
When I started the company in Ho Chi Minh City, the first thing I faced was the reality that the assumptions Japanese people implicitly share with each other - the context - simply did not exist. "This is urgent." "This can wait." "In this kind of situation, I want you to speak up." Those criteria for judgment and that unspoken atmosphere had to be built from scratch. To them, I was a foreigner and a boss they had only just met.
On top of that, we had hired 30 people all at once. There was no time to slowly build a relationship with each person. Even if it meant moving quickly, I had to create a state where messages got through, as a system.
First, I Decided Not to Take On My Own Clients
This story begins with a lesson learned.
Right after the launch, I had clients I handled myself. Naturally, client work came first. But the company had only just started. We were in the middle of building our workflows, and neither the employees nor I knew what took priority and what could wait. Things that were actually urgent got reported or raised late, because employees held back and because I had no time to spare.
When context has not yet formed, employees cannot judge whether they should say something right now. "The boss looks busy, so I'll wait" happens. But no one yet knows the difference between "matters to raise even if I look busy" and "matters that can wait." Since those criteria did not exist yet, the person at the top always needed to have time to spare.
At first, I felt fear and guilt about not having "my own work." I was restless if I wasn't doing hands-on work. But in a newly founded company, I was the top. I had to make the decisions. If the top has no breathing room, employees become unsettled, and serious risks can be overlooked.
I wouldn't say you should never have your own clients or projects, but I felt that at the very least you should leave yourself some capacity. Listening carefully and making decisions was more important than anything else, at least until workflows and structures were established.
I Insisted on Communicating in My Own Words - Learning Vietnamese
As I expected, I realized: "Unless I say it in my own words, it won't get through."
Even among Japanese people, something heard directly from the person leaves a completely different impression from something heard through someone else. Even if the information itself is not distorted, context such as facial expressions and the person's character is lost. When it goes through someone else, the meaning can become unclear or leave a bad impression. All the more so in an environment where relationships have not yet been built.
Even if it was halting, I communicated important things myself. It was fine to ask others to fill in details. If speaking was difficult, text was fine. I didn't have to aim for perfection. But I communicated things myself as much as possible. That was what I valued.
Many Vietnamese people can use English, but English is a foreign language for them too. Even for Japanese people, halting Japanese can be easier to understand than fluent English. The key was to say it myself. Whether through an interpreter or in my own Vietnamese, getting the message across perfectly every time is extremely difficult. That is exactly what leads to the next point.
I Kept Sharing My Thinking Every Day
This connects to learning Vietnamese: in a company that has just started, no context is shared at all - even more so between people of different nationalities. To get a single instruction understood, I thought it was important to share my way of thinking on a daily basis and build common context.
You may think, "If you give specific instructions, isn't context unnecessary?" If that were possible, I would do it. But whether through an interpreter or in my own Vietnamese, getting the message across perfectly every time is difficult. In many cases, what needs to be done is not clear-cut. In web development, there are frequent situations that call for case-by-case judgment that is hard to put into a manual.
If employees understand what I value, and my everyday feedback does not contradict it, the employees receiving the feedback can accept it. And, perhaps partly because many of our employees were young, when I routinely put my own thought process into words and shared it, some people began trying to think in a similar way. I think this happens naturally as they trace my thought process in order to understand what I say.
Once this happens, even short everyday instructions and feedback get through. "I'm not angry about the result itself; I'm pointing out the process." When that gets across, people are less likely to repeat the same mistake.
We Created a Slogan and Code of Conduct
In the early days, "I did it because I was told to" and "I didn't do it because no one told me to" happened often. How do you convey the "responsibility" of the person receiving instructions, which is hard to define? I replaced it with the words "I want you to act as professionals."
Japanese quality standards for deliverables are high. But most of our employees were young, and their attitudes toward work varied. That is exactly why the standard to aim for had to be made explicit. However, I reframed it not as "because it's Japan" but as "pride as a professional."
One of the slogans was "a mindset of preventing failures, rather than fixing them after they happen." If you do your best and still fail, that can't be helped. But "was that failure really unpreventable?" Creating manuals and check systems as a risk hedge is the company's job, but at the same time I wanted them to think for themselves. Rather than having a boss blame them for failing to prevent a preventable failure, I wanted them to feel ashamed of it themselves.
The other was "communication that makes clients forget it's offshore development." In overseas offshore development, where language, location and culture differ, smooth communication is difficult. But that is the very challenge we were taking on. I knew what I was asking for was difficult, but we would aim for it as a goal. This also served to justify my everyday feedback.
We created the code of conduct in both Japanese and Vietnamese.
- Be able to think from the other person's perspective, not just your own position.
- Be able to say thank you sincerely.
- Always show respect to colleagues, whether they are older or younger.
- Be able to give your best effort to everything.
- Be able to cooperate with others, even on things that don't concern you.
There is a background to the last item. Some employees began saying, "Testing is not the developer's job." I don't deny protecting one's own scope of work, but if people are too rigid, a project cannot function. More than that, at a time when workflows were still unclear, if people didn't work flexibly, we would have had to hire dozens more. I can't deny that this was partly for my own convenience as a manager. But for some people, being "needed" is enough of an incentive to act. Even if not everyone agreed, I wanted to win over as many allies as I could. That was how I felt.
I used to think corporate philosophies and slogans were nice-sounding words for attracting new graduates and investors. Once I actually created them, I realized that was not the case. They were practical tools for letting everyone know what I wanted them to do.