A while ago when still a student I stumbled upon a great supplemental income opportunity: a friend of mine, an editor in a science journal, was looking for part time interpreters. The task was quite simple: writing summaries of technical articles. To me my French even though practically non-existent seemed strong enough to do that maybe, just maybe, with some support of a dictionary. I stopped at my friend’s office and he handed off to me a half a dozen articles on various medical topics. I was quite flabbergasted and asked – why medical? I am a technical guy. Math, engineering, maybe software, but why medical? My friend just smiled – if I give you articles in your specialty I will only get back what you know of the subject, chances are, that everything new and or controversial will be missed, and that’s assuming that you know French well… After a few nights of checking every word in a dictionary and still not being able to put the puzzles together I decided to switch to different means of making money.
I have seen the same phenomena with many technology professionals for whom English is somewhat of a struggle. They often step back and rely on their technical skills in understanding their client needs, interpreting the information inflow, often to the detriment of the project. That in particular common for advanced ESLers. When working face to face with native speakers and not communication related misunderstandings are easier to address, non-verbal language and timely feedback are of great help in this case. When you introduce the offshore factor, the time and cultural differences on the top of language handicap communications mistakes accumulate and widen the gap in understanding. Technology professionals have a tendency to bridge the gap with things they are familiar with and make decisions on behalf of the client.
Dealing with this issue requires efforts on both sides and unfortunately there is no panacea. Trying to get every assumption documented and signed off is a recipe for a productivity disaster, leaving things up for interpretation by developers is asking for even more troubles. Many of the tools I find helpful and efficient in this case come from agile development practice, in particular short release cycles and frequent demos.
Of course learning English remains to be one of the most important tasks on the provider side. But with over 600,000 words it’s easier said than done. Classes and books will only get you a fraction of the way there. What can one do to continuously advance in that utmost important skill while keeping they day job? We take our chances and use different methodologies. For me motivational tapes from Brian Tracy, Zig Ziglar, and Anthony Robbins were the main tool not only in building the vocabulary but changing my Russian gloom and doom attitude. Some people listen to NPR some watch a lot of movies. Having mentioned that lat me share with you a story I hear from Kirill (offshore development manager for a large s/w company on weekdays and my blog reader in his spare time). He told me about a Russian developer manager who took watching movies to heart; he also combined business and pleasure and watched primarily action movies. Being very gifted in terms of language he built broad vocabulary of words and idiomatic expressions, a lot of idiomatic expressions unfortunately mostly borrowed from Dirty Harry wannabes. That did not do him particular well :( If you are working on your language skills here is Kirill’s advice –
One of my guys in St. Petersburg has outstanding English and I asked him how he had mastered it. He said that he listened regularly to free podcasts at www.eslpod.com. I checked the site out and downloaded tons (close to 5G) of historical podcasts. Topics are pretty basic, but the language they use and pronunciation is very good. I wish I had something like this when I just came over here :)
Well, as the say it’s better late than never – I’m signing up …