My company has asked me to spend six months helping to start a software development group in a place halfway around the world from where we are based now. I did not get this assignment because I have seniority with the company; quite the opposite—they seem to be sending me because I am one of the youngest people and one of the few developers without a partner or children.
I am told the developers I will be working with are fluent in English, which I would expect in technology, but outside of work, I will need either an interpreter or lessons to learn the local language. I was never good at languages in school, except for the ones I programmed in, and I worry I have no ear for them. I figure since it is a relatively short period of time, I can just work a lot, talk to friends at home over the Internet, avoid the whole language-learning problem, and then return home at the end of six months (with a promotion and better pay).
Have you ever had to manage a group where the developers spoke another language, or, perhaps, done a stint outside the U.S.?
I have been lucky enough to work in several places outside my home country, and each time I have found it to be at equal turns challenging, frustrating, and rewarding. Let me first disabuse you of the idea that the language classes you took in middle or high school had anything to do with language learning. Human beings do not learn languages by studying a grammar book or reciting the conjugations of verbs; they learn languages by listening and speaking. Have you ever seen a two-year-old with a grammar book? Forget everything you thought you learned about whatever language you took in school and start fresh when you get to your assignment.
Human languages also have a built-in reward system: Say the right thing and you get breakfast; say it incorrectly, and you may be eating a dog's breakfast. Yes, you should learn the language of the locale you are planning to live in, and here are a few good reasons why. The first is that you will not always be at work; something might happen—a car might break down, or the metro; or there could be a fire in your apartment building—there are always going to be situations where handling the local language is important. Emergencies aside, you will have a much more interesting experience if you can at least get by in a language, rather than constantly pointing at picture menus. Finally, it has been shown that learning languages increases brain function, which, as scientists and engineers, must surely be something we all want.
Apart from the differences in language, every place—not just different countries, but also cities, provinces, and all the other possible delineations on this planet—has a different culture, both at and outside of work. You cannot insulate yourself from the culture by becoming a robot that only goes from home to work and then back. Even if you hid in your house, eating expensive imported food and consuming entertainment from home over the Internet, you would still have to go out and work with this group that you are supposed to be managing. How can you hope to manage people whose lives and motivations you have made no effort to understand? Don't answer, because the answer is easy: You can't.
How can you hope to manage people whose lives and motivations you have made no effort to understand?
If you think you find different ways of working when you switch companies, that is nothing compared with the differences you will find every day when you arrive at the office in a different country. What time do people arrive? Do they stay late? How late is late? How do they see their work? How do they solve problems? In software and computer science, we like to think our common language is that of algorithms and math, and while that is, in part, true, it is nowhere near the totality of what it means to be working together.
KV has always made the point that software is a collaborative, human endeavor, and that the things we do to make computers (mostly) do what we say are actually only a small part of our work. Most of the work of software is building systems we can explain to each other, and even if everyone on the team, or in the room, or whatever, is speaking the same mathematical and even human language, the culture of the people involved comes into play time and again.
A simple case in point: There are places where certain features can or cannot be built into software, not only due to varying forms of regulation, but also because of cultural expectations about what is and what is not acceptable practice. These vary from company to company, as I pointed out, but they vary far more widely among cultures. Not only do different cultures treat different features differently, but they also treat each other differently. How people act with respect to each other is a topic that can, and does, fill volumes of books that, as nerds, we probably have never read, but finding out a bit about where you are heading is a good idea. You can try to ask the locals, although people generally are so enmeshed in their own cultures they have a difficult time explaining them to others. It is best to observe with an open mind, watch how your new team reacts to each other and to you, and then ask simple questions when you see something you do not understand.
KV's advice—whenever asked about a gig in a different country—is always the same: Learn the language, meet the people, eat the food, and only be rude on purpose; never give offense by mistake, which is why you need to learn at least a bit of the local language. People don't speak Java, for which we should all be eternally thankful.
Advice to a Newbie
Ground Control to Architect Tom …
The Digital Library is published by the Association for Computing Machinery. Copyright © 2023 ACM, Inc.
No entries found