Some thoughts on attending tcworld India 2015

by Tom Johnson on Mar 22, 2015
categories: technical-writing

I just spent the last week in Bangalore, India. The tcworld India 2015 conference took place on a Thursday and Friday, and I spent Saturday and Sunday exploring the city. This was an eye-opening trip for a number of reasons, and I wanted to capture some of my thoughts and experiences here and share them with others.

Understanding tekom

tcworld India is the name of a company that puts on the conference. There are two associations that organized it: tekom and Technical Writers of India (TWIN). tcworld also puts on a larger conference in Germany every year that attracts 4,000 plus attendees. tekom as an association has many thousands more members than the STC.

The German tech writing scene

I have always wondered why I don't have more German readers of my blog, and this trip helped me understand why. In Germany, about 80 percent of the technical writing jobs are in manufacturing engineering, such as for companies that produce automobiles, medical devices, restaurant machinery, and other physical machines. Apparently, there are very few software companies in Germany.

Despite this division, many manufacturing engineering products involve software to control the machines, so it's not as if software is completely absent from these products. It's just that they are primarily manufacturing engineering companies instead of software companies.

Most of these companies have developed their own XML schemas in order to process their content. DITA is relatively new and not adopted by many of these companies — they prefer to develop their own flavor of XML to custom fit their company's product and business.

Many companies must comply with regulations that require them to meet certain standards in their documentation, such as documenting safety requirements. (Perhaps a regulation may require disclosure of certain risks up-front during some procedures.)

Finally, many German doc shops translate their material into a number of languages.

In summary, in Germany the tech writing scene emphasizes the following:

• Manufacturing engineering products
• Custom XML schemas
• Standards and regulations
• Translation

In the United States, all of these characteristics are much less common. Most of the technical writing jobs are in the software industry, not manufacturing engineering. Few companies develop their own XML. Apart from some regulations in the financial or medical industries, most technical writers don't have to worry about regulatory standards. Finally, since English is spoken in so many countries, translation is not nearly as common.

Because of these vast differences, I can see why my blog may not be so relevant to many German technical writers.

Enter India

Most technical writers in India work for large multinational companies such as Cisco, HP, IBM, Tibco, and many other companies. Many of the companies are software companies based in the U.S. Someone estimated that at least 60% of the technical writing jobs in India are in the software industry, not in manufacturing engineering.

Many of the writers working for multinational companies are using DITA or other XML. Some of the jobs do involve API documentation, though not as many as in California's Silicon Valley.

India is young

What took me by surprise in India is how young the Indian technical writer population is. If I were to guess, I'd say the average age falls between 24-28 years old for Indian technical writers.

With 1.1 billion people, India has the largest percentage of young people of all countries. Additionally, technical writing is somewhat new as a profession here, so the generation of technical writers is younger by default.

In contrast, when I attend a conference in the U.S., at 39 years of age I'm still looked upon by many of my colleagues as "young."

Youth brings a number of characteristics and advantages: eagerness, open-mindedness, ambition, idealism, adaptability, technical familiarity, and more. Many of the technical writers I met at the conference were eager to improve their documentation. They were forward-looking and ready to embrace and follow web trends and other innovations.

In contrast, many U.S.-based technical writers are more resistant to change; they're satisfied in sticking with the tools and methods they know. Once they learn a tool, they're often fanatical about sticking with it.

However, being young and eager for change doesn't fit so well in a multinational company where the documentation processes are usually heavy DITA or XML implementations with little chance of ever changing course.

Even so, I had people from big companies tell me that different doc teams had autonomy to be flexible. One writer at IBM said her group, which focuses on developer documentation, was actually using Markdown instead of DITA.

If you listened to my keynote, you'll see that I painted a picture of an open doc road with startups, where you can choose your tools, define your processes, and try out different documentation experiments. The picture I was describing might have seemed a bit surreal to many of the audience members locked in multinational companies with heavy, fixed doc processes.

Even so, many of the tech comm professionals in India connected with this message. There are some startups in India, and the number is growing, but startups aren't the norm.

Some of the TWIN organizers told me that they want to encourage innovation and startups in India. There's a need for more out-of-the-box thinking, rather than just being a cog in a large multinational wheel.

Visiting Capgemini

The day before the conference, I had the opportunity to visit Capgemini, a large technical services consulting firm that offered, among various services, documentation. Capgemini has about 500 aerospace engineers writing documentation for an airplane company called Bombardier, one of the largest manufacturers of planes and trains in the world. Bombardier is based in Montreal, Canada.

Capgemini literally has multiple floors filled with hundreds of engineers sitting in front of computers creating documentation from highly technical engineering specs for airplanes, addressing all aspects of the engine and aircraft. They use Arbortext from PTC, a number of illustration/graphics applications, and home-built systems to manage change orders, processes, communication, and other workflows.

I toured the facility with about 6 Germans from tekom. When we entered the workplace, women dressed in colorful traditional Indian dresses put lays made of shaved, fragrant sandlewood around our necks. Then using matches, we lit some wicks sticking out of a tall brass lamp. (Lighting a lamp is a tradition for good fortune/luck?)

The floor was an open office setup with aisle after aisle of desks, each divided from the next only with a short 18-inch glass wall. The color of the glass differed by section, so you could see a mix of orange, blue, and green throughout the workspace (which seemed about 75 yards wide and 75 yards long).

I'd never seen hundreds of technical writers working so closely together. What was more impressive, most of the technical writers were aerospace engineers, and many had previously worked as engineers on aircrafts, literally designing and creating machinery for airplanes.

In the U.S., although you can find some engineers who have turned to technical writing, it would be rare to attract hundreds of them. What's more, without question, most of the aerospace engineer tech writers were happy to write documentation. They said it presented its own set of interesting challenges. One person noted that the documentation roles offered management positions, and allowed people to scale up the corporate ladder more quickly than in an established engineering firm.

Cost of licenses

I asked if there were any challenges with their existing doc setup, and one person mentioned that the cost of licenses was steep. This is an interesting topic that popped up in multiple contexts.

Software companies that price their licenses at, for example, $1,000 per year per seat, often do so in their main market. (I don't know what the price per seat is for Arbortext, but let's suppose for this example that it's $1,000.) Is the cost proportionate to the average wage in the country? What may be affordable in the U.S. or Europe may not be so affordable in India, Sri Lanka, Brazil, Romania, or other developing countries with strong IT talent.

I had some great conversations with Jose Serramano from MadCap Software. He said that the pricing for Flare is the same globally, which makes it difficult to sell in countries where the cost of a license is proportionally more expensive than in the U.S.

As a result, he said many people will get a hold of a specific version of Flare and stick with that version long after Madcap upgrades to the next version. For example, although Flare 11.0 was announced and demo'd, many users may still be using version 7.0 or 8.0, with little desire to upgrade to the latest version. Jose said he once worked with someone who was still using Flare version 3.0.

So although Madcap has thousands of companies using Flare, the real question is how many of these users upgrade Flare every year. This is an interesting dilemma for software companies (from Madcap to Adobe to PCT and nearly every other vendor). In order to pull in revenue each year, you need to push out a new version of the software that entices people to upgrade to that version.

When users upgrade to the next major version, there's usually a significant cost (such as half the cost of the full version), and this is how many software companies stay in business.

This kind of perpetual improvement of the software might be healthy, but it might lead to feature bloat as well. Each new version has to tack on some cool new features (for example, apparently the release notes for Flare 11.0 span several hundred pages), and after a while your product that was once lightweight and simple might become a complex rube goldberg machine.

At some point, when your product becomes unwieldy and bloated with features (many unnecessary to users), a new lightweight, simpler model operating in a lower value market might come along and replace you. (Think of the story of WordPress and Jekyll. One of the main reasons people like Jekyll is that it's not overloaded with heavy infrastructure and unnecessary features like WordPress.)

Simple ways to publish a site

During one of the conference's evening activities, one of the Indian technical writers approached me and said there was a need for simple people (for example, farmers) to be able to publish a website — without knowing any code or having technical skills.

This got me thinking. In my keynote, I promoted and encouraged people to use the tools of the web rather than the tools of tech comm. Static site generators are one category of web tools with tremendous promise. Almost every static site generator I've come across is free and open source. All you need is a text editor.

In fact, Github Pages also provides free publishing, so in this scenario, someone who earns very little could, if he or she has Internet access and a computer, publish a website online using Jekyll and Github Pages. (Of course, many other options, which are both simpler and easier, are also available, such as WordPress.com.)

Scalability might be more important than I anticipated in India. If the cost of each software license is prohibitive, a solution that uses text editors, static site generators, and code repositories to share, version, and collaborate might really be a system that scales easily.

If you can start up a documentation company and pull in 50 technical writers without worrying about provisioning a licensed seat for each writer, that's huge. And not just in India, but any country with IT talent where you want to scale.

Touring Bangalore

I stayed an extra two days in India to see the city. It doesn't make sense to spend 40+ hours on a plane (round trip) without really seeing the country. I usually feel comfortable in exploring a city by myself. I can learn the public transportation system, use guidebooks to find the sites I want to see, and get around by myself asking simple questions. Not so in Bangalore. I felt intimidated just crossing the street.

Seriously. Cars don't stop for pedestrians. You have to play frogger to cross the street. Sidewalks are broken. Street names aren't necessarily present or in English. It's easy to get taken advantage of in taxis and shops when you don't know how much things cost. And what exactly do you see in a city so vast and large (with 10 million people)?

I had a four-hour city tour through bluefoot.in on Saturday and enjoyed it so much, I did an 8 hour tour the following day with the same company. The guides showed us some amazing parts of the city, such as:

• Washerman (the lowest caste) doing laundry in empty lots next to roadways
• Kali temples where priestesses made offerings (pouring milk on the god) and purged visitors of bad spirits
• Eateries next to temples, where we ate dosas on banana leaves sitting on communal benches in a little building next to (or partly inside) the kitchen
• Sikh temples, where we put bandanas over our hair and toured their massive kitchens where they feed thousands of people daily; we also helped wash some dishes
• Bustling city markets, where you can buy nearly any type of fruit, vegetable, fish, animal, spice, or other item in an energetic, bazaar experience
• "Upcycling" centers in slums, where disadvantaged women convert trash and discarded items into products they can sell (like baskets from juice cartons, or iPad covers from discarded scraps)
• Sri Aurobindo society, where we learned about a non-religious spirituality and meditated in a quiet room with incense burning in the background

This wasn't my first time in a developing country. I spent two years in Venezuela, and two years in Cairo. (I also spent a summer in Japan and also lived in Harlem and the Bronx, if those count in terms of culture shock.)

There's an unquestionable fascination in exploring another country. From the city markets bustling with people to the tiny alleys where shops exist in holes in the wall, it's an experience in otherness.

Overall, I love cultural experiences. But there is also something that can be unsettling at times, particularly when roaming about in poorer areas. Indians are extremely friendly people, and I felt an openness and friendship wherever I went. But when traveling among the poor, I also felt like a rich American. By comparison to someone who earns 50 rupees a day (less than a dollar), I am rich. But after too many "sirs" and extreme service, I feel out of place. I don't want to be the rich American. Maybe I like my anonymity. I also dislike being faced with the reality of my privilege.

When I see so many underprivileged people, I ask, why am I so privileged? Why should I receive an education, have multiple computers with Internet access, green parks and abundant clothing and food, a good job, health and medical care and everything I need, whereas others around me don't even have a toilet? Their water is scarce and unclean. Their education is limited as well as their opportunities.

How is that I can sit here in my Hyatt Bangalore air-conditioned hotel room overlooking the city in perfect comfort while others have to spend all day in the hot sun washing clothes by hand in stone basins? That is what is disturbing — being confronted by my privilege, and how I am completely undeserving of it.

Of course, it's just this kind of shift in perspective that makes foreign travel so eye-opening and interesting — not because you get to see the world, but because in some respects you get to see yourself.

Spiritual elements of the city

I particularly enjoyed the spiritual tours through the city. I saw numerous Hindu temples, including a Black Magic temple with a voodoo-like element (people tie clothing of their enemies onto a tree in order to bring them misfortune), a Sikh temple (where I learned that Sikhism is almost like community brotherhood and service, feeding thousands of people daily), a Christian cathedral (I didn't realize that 23 million people in India are Christian -- that's just 2.3% of the population!), a Hindu temple with a natural spring in the middle, and more.

I asked our guide a lot of questions about Hinduism, and he related story after story in a complex, interrelated family of gods where, despite the 330 million + gods, they are all just manifestations of either Brahma (the creator), Vishnu (the preserver), and Shiva (the destroyer).

Having left religion myself more than a year ago, I haven't been quite sure to do with the spiritual elements of life. Our guide made an astute comment. He said (quoting someone), "Religion is for people who're afraid of going to hell. Spirituality is for those who've already been there." I liked that saying.

Hinduism is interesting because it's less a religion and more a way of life. There isn't a master guru who oversees Hinduism's doctrines and practices, like the Pope oversees Catholicism. There aren't specific rules and regulations to follow, and the number of gods and stories interconnecting them is rich and colorful and complex. At the same time, watching a woman pour a milk offering over a Shiva god painted blue with multiple destroying arms is kind of bizarre.

Namaste

One of the things I'd hoped to gain from my trip to India is a better sense of how to interact well with my Indian counterparts at work. I regularly work with Indian engineers, project managers, and others. While our interactions have always been pleasant, I wanted to understand the culture more and maybe recognize ways I could improve.

But really I didn't come away with any particular guidance. Indians are generally friendly, open people who are more than happy to talk and interact. Our tour guide mentioned the diversity of people, noting that the population in India is so numerous and diverse, there isn't one way of interacting. Instead, he said to remember "Namaste," which is a way of greeting, departing, apologizing, and otherwise interacting with people.

Namaste means "The divinity in me acknowledges the divinity in you," and when you say namaste you bow your head and bring your hands/palms together before your chest.

I liked this simple advice. Namaste recognizes that others have a divine characteristic just like yourself, and encourages an attitude of mutual respect and cooperation. No matter what the person's status or title, by acknowledging the divinity in others, you show respect for the person, and that respect is the basis for any relationship.

Here are pictures from the Bangalore trip.

English colloquialisms?

One of the conference attendees asked me if I thought Indian technical writers were behind technical writers elsewhere. Based on the conversations I had with people at the conference, Indian technical writers are neither less nor more informed than their counterparts in the U.S.

However, there is one great disadvantage to living in India. In India, you're surrounded by people who aren't as familiar with the colloquialisms and other idioms of the English language. One person said this is "Hinglish," a combination of Hindi and English. But later another person (my Bluefoot tour guide) said no, this is just bad English. (Hinglish is a mixture of Hindu words with English.)

For example, one person gave me his business card. The tagline said "tech comm beyond perception." I asked what this meant. He explained that it means to go beyond normal expectations and boundaries to imagine something new.

Hmmm, I thought, the phrase "beyond perception" isn't quite right. Maybe "breaking new boundaries," or "going beyond expectations," or "imagining the impossible"?

As another example, I saw a sign outside the Arubindo Society house that said "Children Leaving and Receiving Point." Again, that's not a familiar phrase in the U.S. More like "Child Pickup and Dropoff."

It think it must be nearly impossible to sound like a native American English speaker if you're surrounded by phrases, accents, and expressions that don't quite match what you'd hear in the U.S. Immersion in this environment will create more challenges for Indian technical writers who are writing for multinational U.S. companies and want to sound completely natural in their speech.

Even so, sticking to simplified technical English for instructional contexts is probably a good strategy, and you may not run into too many of these colloquial situations in writing.

Overall, the trip to India was a great experience and I will always remember it. (I am still, however, recovering from jet lag.)