The Content Revolution

Since the Great Recession of 2007, several trends have affected corporate thinking and particularly the way we work in IT. We're only too aware of downsizing and outsourcing, as well as expansion of responsibilities, as in "test your own code" and "edit your own docs." But there are more subtle trends that, if well understood, can be used to our advantage.

In the steady but anemic economy since that recession, companies have been rather cautious. They're reluctant to invest in anything that isn't a core revenue contributor. In the software industry, roles branded with the scarlet letter 'O' for 'Overhead' have been purged: localization, writing, editing, even product support and QA.


It's ridiculous to think that testing isn't an integral part of a software release. Yet in tough times, such thinking can prevail. In the same way, it might be tempting to think that content is merely an enhancement tacked onto software, but the fact is certain content is an integral part of the product. What we need to do is figure out what that critical kind of content is, and train ourselves to develop it.


Social technology, particularly comments on web pages and web feedback, have exposed certain traditional of content as useless. We're all too familiar with long-winded conceptual discourses and procedures for trivial or obvious tasks. Such content used to be seen as adding value to a product, then necessary for completeness. Now it's generally skipped over as worthless.

Search technology has seen tremendous advances. We used to index online docs, but now readers use long-tail searches on Google and Bing to find answers to a specific question rather than slogging through an index. We used to create massive directories of website URLs (Yahoo, Excite, WebCrawler, and AltaVista). We used to think the key to discovering information was a vast interconnected web of hyperlinks (viz. the Hypermedia Era of the mid 90s). Or carefully organized TOCs. All of these strategies relied on teams of people trained in technical communication. In other words, major overhead for content that required a lot of slogging through.

A strange thing about technology is that we tend to see the current model as Shiny, even when it isn't even very efficient. Brick-sized cell phones were cumbersome, but the advantage of calling from the road was attractive. Massive web directories like Yahoo were likewise cumbersome to maintain and use, but we clicked through blindly because that was the way to find stuff on the web. So when efficient search engines came along, the Shine immediately faded from the directory sites.

What never changes is perceived value. Readers have always wanted to get directly to the answer they need at that moment. Content that provides a better way to do that is attractive and valuable.

Content is never going away, but the definition of critical, valuable content has changed. It must directly enable the customer to use the product now and quicken adoption. For example, a classic question in designing doc sets has always been, what's the first thing the reader needs to see?

It's been well known the first thing developers like to do when they download an SDK is to run the sample app and tinker with the source code. Thus the focus of "Getting Started" content has shifted from the general (conceptual overviews or development scenarios), to the specific: step-by-step procedures, including code, that when followed, actually build sample apps.

This is the revolution in content. Modern developer content must be text and code that shows a reader how to create and run a meaningfully functional application.

So what does this mean for a programmer/writer? What core skills do you need to create this new kind of content? Let's break down the definition of modern developer content:

• It must be code-rich. It might be a demo app. It might be text with example code. It might be procedural text that shows a reader how to build a sample app or perform a meaningful task. Whatever it is, it will need to provide code and show by example.


• It must be meaningfully functional. Whatever form it takes, the sample or procedure must work and demonstrate a task or procedure useful to the reader. You must show how to deploy and run it. It's not a proof of concept nor just a Hello World; it must target scenarios that are useful to customers.


• It must be contextual and scenario-based. It doesn't help readers simply to upload a demo app or sample code with no explanation, nor are how-to articles with no background. You owe it to the reader to explain why this scenario is useful in the framework of the product.


• Ideally, it should be end-to-end, meaning it provides complete setup and follow up. You need to consider all the setup steps and prerequisites, as well as any follow-up steps necessary for the sample to work. Run it yourself, as many times as necessary, and provide clear direction on each step. Customers are alienated by vague or missing directions, or omission of configuration or installations needed to make the sample work.

The standard for writing modern developer content is higher then before, and your skills will need to rise to meet the bar. But because modern content enables customers to use a product and quickens adoption, it's a provably valuable part of the business. By writing modern content, you become a critical part of your company and less of a commodity.

In times when many roles seem expendable, you need to become indispensable.