DocOps: Interview with Jim Turcotte

by Tom Johnson on Oct 21, 2014
categories: technical-writing • web-design • wikis

The following is an interview with Jim Turcotte, a senior vice president for CA Technologies and business unit executive for the Information Services team. Jim recently posted several articles on LinkedIn Pulse about something he calls DocOps, so I asked him some follow-up questions.

Can you explain DocOps in more detail?

First, let me start by explaining the application economy. Customers today decide whether or not to do business with you based on your software. Your new façade is now your mobile application and online presence. A good example is the ability to take pictures of your check to make a deposit. Any bank will now say they are really a software company in the finance vertical market.

In order to remain competitive in the application economy, Agile and DevOps methodologies are a must. DevOps provides an extremely agile development approach through a combination of collaboration, automation, continuous integration and analytics. The end result is the ability to change software in minutes rather than days, weeks, or months – or worse, such as with the next product release. DevOps is quickly becoming the development standard in the application economy.

DocOps is the content sibling of DevOps. It's about having a highly-collaborative content platform that allows product information to be continuously developed, even after the product release. Most tech companies have a team of writers who publish PDF/HTML documentation at the release date and then move on to the next release. As support encounters bugs with the content, they fix the content by writing hundreds of standalone support articles. The end customer is often forced to search both the original PDF/HTML content as well as hundreds of support articles to find the assistance they require to solve a problem.

At CA, our writers will constantly “curate” content throughout the lifecycle of the product. If Support realizes we have a doc bug, they will work with us to address it in the original content topic. In essence, the content will continue to mature throughout the product lifecycle. The days of publishing hundreds of Support articles that customers have to crawl through are over.

In addition, the DocOps platform has analytics that reveal how well the content is meeting customer needs. For example, we can watch content activity to determine the languages, browsers, and operating systems that customers use. We can see which topics are being viewed most often; we can also read and respond to customer feedback in real time. DocOps is content agility at its best.

For continuous updates to content, about the only viable platform is a wiki. Are you saying that technical communicators need to publish on wikis to stay agile and to keep up with the lifecycle of a product?

A true DocOps platform requires dynamic collaborative properties. That can be a wiki or another tool that may deliver those properties.

By "mature the content," do you just mean that technical communicators need to update and republish help content based on logged support requests each day? Once the help is updated, do you then remove the Support article?

The goal is to NEVER have the Support article in the first place, but rather update the original topic in the DocOps platform. We know customers don't want to search multiple flavors of documentation to get the answers they need.

Beyond increased vigilance about doc usage and continuous updates to content post-release, is there anything else about the DocOps approach that is unique?

Yes. One great example is its ability to drive lead generation by executing targeted marketing with tools such as Linkedin Pixels or Marketo Munchkins. Another is highly automated localization. DocOps enables automated cloud translation during the authoring process. But even more importantly, DocOps presents customers with content in their choice of language based on the language specified in their browser settings.

How have you managed to close the gap between support teams and tech comm teams? These groups tend to work very isolated from each other.

DocOps, like DevOps, is about changing culture, not just tools and processes. We are making steady progress toward moving from a culture of silos to high collaboration across the enterprise. Having been the Support executive here prior to my current role in Development helps bridge that gap. The key is to put the customer experience ahead of business unit wants.

How do you manage your wiki content to make sure that pages added by numerous groups are kept up to date and maintained?

We like to say our writers (or information engineers, as we call them) are curators of the wiki content. They are alerted when topics are updated and are able to make appropriate changes to ensure we deliver crisp, relevant content. We find we end up with less duplicate content and therefore, fewer words. This new platform has reduced word count by 25% already with more to come.

How are you monitoring real-time usage of documentation based on demographics, countries, search queries, and other metrics?

The DocOps platform provides analytics for each product. In fact, we are also building an overarching dashboard that allows a global view with drill-down capability. Ultimately, the global dashboard will be used by product management (monthly hits, country usage to better determine translation needs, operating systems and web browsers being used, etc.) as well as the content curators.

Does your Support background influence your approach in tech comm? Should these two disciplines have more similar authoring and publishing processes?

My Support background provides awareness as to just how important it is to have solid, maturing content. There is a clear correlation between good content and issue volume/customer satisfaction. My background has also made me aware that tech companies spend too much time having Support Engineers writing content vs. fixing customers issues. Move the writing to the writers and let engineers focus on the issue-resolution work they do best.

How do you enable real-time publishing while also pushing content into multiple channels (which is often accomplished through structured authoring models)? In other words, if you use Atlassian's wiki to make quick and frequent updates, how do you push that same content into different outputs and channels for different audiences?

Once published, wiki content is available to our customers real-time either via their product UI or by accessing our website using mobile devices or PCs. Once in the wiki, they do have the option of creating an ePub, PDF, or Word document in a matter of minutes. We are also starting to use our DocOps platform for partner enablement and technical content.

How do you avoid the redundant, outdated, trivial (ROT) content syndrome that is so often associated with wikis? For example, most wikis I've been involved in have hundreds of pages, many of them out of date, their original authors having moved on or left. The result is often a content junkyard, with almost no way to find anything or know if what you've found is current.

Actually, this is the issue many companies have with PDFs using Content Management Systems. No one can see what's inside all those PDFs. By moving content to the wiki, we threw away about 25% of our words because we had a better visual. It's critical that the lead writer of a product becomes the overall wiki curator/gardener. By having other teams such as Support, Services, and Education author in the wiki, the writer is alerted via notifications about new content and can ensure that duplicate content does NOT occur. A wiki, like a newspaper, needs an editor so that the DocOps platform does not become a free-for-all.

As the world moves to being an application economy, what does that mean to software companies?

With applications being developed and released continually, content must also be developed and released in lock-step with those applications. Software companies can no longer afford to wait for code freezes or perform localization drops at the end of the development cycle. Product information has to be developed using an agile approach with tools that enable collaboration, agility, and continuous release.

How does the content supply chain need to change?

It starts with agility. There's no time for the “hand-off” in the old waterfall cycle approach. To develop content in an agile manner, we need a platform that supports collaboration, integration, and continuous delivery. That platform needs to automate key processes like translation and Search, and it needs to collect better data to facilitate decision-making.

Were there any challenges with moving to a DocOps approach at CA?

Whenever you introduce change, there are challenges. The biggest challenge was getting people to think differently. For example, asking writers to move to more of a curator role or asking Support to write articles using a different tool.

What's your biggest challenge in providing help content to customers, and how does DocOps solve that?

I always say that we did not have one silver bullet. It was death by a thousand cuts. But in the end, our former content supply chain could not sustain the business agility we needed. DocOps, at its core, solves that. It provides a single source for all product related information. We can easily link topics to product UIs to provide contextual help; additionally, DocOps also offers further sources of information like education courses, community discussion threads, and so on, all from the same source, so customers no longer have to log into multiple systems for that same level of detail. DocOps was conceived and built around the need for an improved customer experience with product information.

---

Jim Turcotte is a Senior Vice President with CA Technologies and the Business Unit Executive for its Information Services team. For more information about DocOps, follow him on LinkedIn.