Perspectives: Creating a documentation team in India

If your team is like mine, you constantly face the challenge of doing more with the same or less staffing. We need to be flexible with finding quality employees, wherever that road might take us. In the case of Dassault Systèmes SolidWorks, that road took us to the 3DPLM offices in Pune, India.

In February 2014, my colleague Lyn Amidon and I traveled to India to greet and train our new technical writer, and to learn how to create and grow a SolidWorks documentation team there.

I manage the SolidWorks documentation team based in Waltham, Massachusetts. SolidWorks is a computer-aided design program and as such, it requires a fair amount of technical documentation. We had a staff member resign this past summer and could not backfill the position. Then, unexpectedly, my manager mentioned the possibility of hiring a writer in India and actually visiting India too.

After originally saying no, I rethought the situation and said yes. I realized that we needed to embrace the new reality of expanding our documentation team to India, particularly because we have many development teams there now.

Traveling to India requires some preparation. We wanted to travel in February because it’s still relatively cool and dry, with no conflicting holidays. We were advised to stay two days in Mumbai before going to Pune. We needed business visas, various vaccinations and other medicines. For basic preparation, I watched several Bollywood movies and read a Dummies book about doing business in India.

 

Getting there

We arrived in Mumbai at around 11:30 p.m. and immediately knew we were no longer in the winter of Boston, but the “winter” of India. It was about 75 degrees Fahrenheit. We noticed that two gentlemen were trying to assist our driver, who was rolling our baggage along just fine. Upon reaching our car, one of the gentlemen put out his hand, and I shook it. Both men quietly walked away. Our driver said that they would appreciate any help we could provide. That was a recurring weeklong theme.

Driving in India is an experience everyone should have. Indian roads are not in great condition compared to, say, Boston. The cars drive on the left as in the United Kingdom. There are hardly any lane markers. There’s a mixture of cars, trucks, motor bikes, pedal bikes, three-wheeled taxis and people crossing the road amidst a cacophony of constantly honking horns. Drivers use their horns to signal others that they are passing or to alert them. Many trucks actually have words painted on their rear bumpers, such as “Honk OK Please” or “Horn OK Please” (Figure 1). The Indians were very polite, even with their honking.

We also tried one of the inexpensive, open-air, three-wheeled ubiquitous black and yellow taxis. You get to experience the journey up close and personal — sometimes too close, like within inches of the surrounding traffic. There are no other really viable forms of public transport in Mumbai.

The next morning we walked on the esplanade around nearby Powai Lake. People invited us to play cricket at one of the ad hoc games taking place throughout the city. We returned to our hotel, met our driver and took off for Pune.

The trip from Mumbai to Pune is about 125 miles, but can take four hours because driving out of Mumbai and into Pune is difficult. In between is a fairly modern expressway, complete with tolls. The expressway driving experience has less honking, but we still saw people walking across the road. We saw billboards advertising beautiful apartment complexes with green lawns, with random signage urging you to Observe Lane Discipline.

Pune is a city of about nine million people. An American-born Indian friend explained the high tech industry in India so I could understand it from an American viewpoint. He said to think of Bangalore as Silicon Valley in California; Mumbai as New York, not as much high tech but more finances; and Pune as Boston, with a decent amount of high tech and many good universities.

Our partner company, 3DPLM, is located in Hinjawadi Industrial Park, along with many other high tech companies. Our hotel was about a 15 minute walk from the offices. Pune appeared to be a very safe city, except when you tried to cross the roads. Every morning we had to cross a dangerous traffic circle. We saw sandals strewn about the circle, and wondered what happened to the people who had been wearing them. One morning we saw a shepherd herding his flock of goats around the circle.

There were two main goals of our trip. Lyn was to meet and train our new writer.  My main goal was to understand what 3DPLM was, how the company worked, and what I needed to do to potentially expand my 3DPLM documentation team.

 

Training the new writer

We hired our new writer two months before our visit to India. During those two months, Lyn spent about 1.5 hours daily doing training over the internet. For the trip, Lyn prepared a training plan ahead of time and sent it to our writer. Lyn concentrated on processes that are difficult to demonstrate remotely, such as how we use our graphics tools and our internal editing procedure.

Normal working hours at 3DPLM are from 9:30 a.m. to 7 p.m. or later, to try to interface with Europe and the United States. We were in the office by 9, and Lyn spent a solid eight hours daily training the new writer. Although we were given individual “cabinets” (closed offices), Lyn preferred to work beside our new writer in her cube. This made it much easier for our trainee to do the tasks herself with Lyn looking on. Lyn frequently referred the new writer to our internal tools and process guide so that she can find answers to questions when Lyn is not available.

Lyn was able to cover most of the items in the training plan, though not necessarily in the intended order. Sometimes events provided opportunities to do training that was more than an exercise. The biggest obstacles were development issues with the software being documented and the fact that some of the equipment and software that the writer needed was not yet available to her.

We had hired our writer in December by leveraging 3DPLM’s local knowledge. We coordinated our candidate search via a well-respected 3DPLM documentation manager and the 3DPLM director for SolidWorks. They reviewed approximately 30 to 40 résumés. After we reviewed a handful of résumés they sent us, one candidate stood out because of her prior experience working with 3DPLM.

I was impressed by the strict 3DPLM recruitment and employee review processes. There are seven levels for 3DPLM staff. Candidates take a general intelligence and aptitude test, two rounds of interviews and an in-person interview. In our case, there was an additional two-hour writing test, considered a special skills test, that rates candidates on their English language knowledge, including structure, grammar, writing for users, editing and essay writing. Once candidates are hired, depending on their experience, they may take up to three months of training on core skills, company products and tools.

3DPLM has discrete criteria on which each employee is graded in three different sections such as meeting expectations, providing enhancements and training taken. The local manager sets employee goals and evaluates the employee twice a year, collecting additional input from the reporting manager. The process seemed to be much more transparent than any process I’ve ever seen in the United States.

From discussions with the 3DPLM documentation manager, his manager in operations and the head of 3DPLM recruitment, I learned that there are good technical writer candidates in India, but you need to have a very thorough search and vetting process.  Many engineers apparently want to work for 3DPLM, so 3DPLM can be selective in hiring only the best staff. This up-front effort results in a low attrition rate. You therefore must allow sufficient time to find the best candidates. If candidates are hired from another company, they might be required to give up to three months of advance notice.

I met other key personnel who all seemed keen to help me expand our documentation team in Pune in the future. We were impressed by the general level of technical knowledge and the interest in how we do things in our US offices.

 

Measuring results

Since our visit to Pune, Lyn reports that she now meets with our new writer twice per week for 45 minutes each time. She still spends support time building her environment to test the product and reviewing specifications, along with technical review and copyediting. Lyn provides insights that only she can have because of her years of experience with the product.

Our goal is to have the new writer become independent so Lyn can take on other tasks. We are meeting soon with the product team to gather their help in supporting our new writer, especially for technical reviews. We anticipate that we will achieve our goals over time. If we can expand our documentation team in Pune, they can develop their own knowledge to independently answer questions instead of relying on Lyn. A local Pune team would also be better equipped to do self-editing, which should reduce our overall editing
load, improve quality and hopefully improve our localization team’s efficiency.

Regarding the quality of documentation from India, Dassault Systèmes invested time developing English language training for our India-based technical writers. I need to coordinate with the local documentation manager to see if our new writer would benefit from this training. Dassault Systèmes is also investigating potentially purchasing an authoring assistance software product that could enforce our corporate style guide and provide a baseline copyedit to improve quality for all our writers globally.

About 50% of our documentation staff work in the United States, and 50% work in Europe and India. Many writers know English as a second language or speak a different variety of English. Various Dassault Systèmes acquisitions may introduce more writers from different countries. This global makeup makes it even more important to have an authoring assistance software product, or even a simplified technical English option with a restricted vocabulary. Both products would reduce our localization costs, with a quick return on investment time of less than one year.

Longer term, we should work toward creating a centralized content management database hub to share content globally across departments and brands. The optimal solution would be to share all content sources across all departments that generate content (training, sales and marketing, technical support and education) for all Dassault Systèmes brands. That solution would leverage shared content to the maximum and reap huge localization cost savings.

 

Final thoughts

India is a land of huge contrasts. We saw extreme wealth next to abject poverty. We visited some beautiful natural sites that were next to pollution and waste. Construction is everywhere, but the roads to get anywhere are in bad shape. Providing basic services gets harder as more people flock to the cities for jobs. Air pollution and water pollution are problematic. While boarding our flight out of Mumbai, we chatted with an ex-pat Indian who said that the rate of growth in India, much of it from booming technology like ours, is not sustainable. He said his son was coming to work for a time in southern India to start working on researching solutions to the problems facing India.