In the closing keynote of the 2013 LavaCon conference, Ann Rockley talked about the rising importance of content engineering in content strategy. A content engineer, Ann explained, is someone with one foot in the technology world and one foot in the content world. Last year I wrote a pair of posts on my hesitation about taking on the label of content strategist (Am I a Content Strategist?, I Am a Content Strategist). I have no such hesitation about the label of content engineer. I am a content engineer, and I have been one for many years.
Indeed, in a professional sense, I am a content engineer in my bones. It is what I am, not simply what I do. We all play many roles in the course of our careers, but these roles, and their responsibilities, are temporary. Who we are as a professional is permanent and affects how we approach all the roles we take on. Some people are managers in their bones, even when not in a management role. Some people are programmers in their bones, even when they are in management roles. I am a content engineer, no matter what role I play at any given time. If I am a content strategist, it is because I am a content engineer.
But what exactly is a content engineer. As so often, any attempt at definition must begin by looking at what it is not.
- First, a content engineer is not simply someone who is an expert with one or more authoring tools or publishing systems. Being a FrameMaker expert or a Flare guru, while these are very useful skills, does not make you a content engineer. The use of tools is not, in itself engineering. Engineering is about the selection, application, and creation of tools to implement a process that achieves a business end. Simple use of tools, with whatever degree of competence and sophistication is not engineering.
- Second, being an XML expert does not, in itself, make you a content engineer, though XML will often be part of the content engineer’s tool kit. Content engineering is about content as much as it is about technology, and XML expertise is not in itself content expertise. Even if you understand both content and XML, you may not understand the applicability of structured data format to content engineering problems.
- Third, being a publishing expert does not make you a content engineer. By the time we get to the publishing stage, content is in its fixed and final format. A content engineer probably includes publishing in their practice, but technically they could hand off the publishing part of the process to others with particular expertise in publishing, and given the current variety of publishing platforms to be accommodated, that handoff might be wise.
- Fourth, and perhaps most important, content engineering is not content management, anymore than manufacturing is warehousing. Content management is about the management of content after it has been created. Content engineering is about how content gets created. Content management systems often make very poor platforms for content engineering because they have such lame facilities for content creation. Web CMS, in particular, tend to offer little simplistic in-browser WYSIWYG editors that can’t even produce decent HTML. (Don Day has gathered a list of complaints about the current state of CMS editors under the title Browser Editor Primal Scream.) But content engineering is not about building better editors, though it may do so, as part of a larger content engineering effort.
The fundamental difference between content management and content engineering may be summed up like this: Content Management takes content as an input. Content engineering produces content as an output. A content engineer is someone who understands the computability of content: how content can be generated, derived, and manipulated by algorithms.
Most content today is not engineered, it is simply written (or drawn, or photographed, or acted) ad hoc and by hand. Most content management systems are designed on the assumption that content will be created ad hoc and by hand, and loaded into the system as finished units, one piece at a time, using a manual process. They are designed for a craft process of content creation, not for content engineering.
Component content management systems are an example of a content management platform with some specific content engineering capability. They support the composition of content outputs from pre-written content components (that is, content reuse). This is one, though only one, application of content engineering.
Another example of content engineering comes from the software world where API documentation is commonly generated by systems like JavaDoc. These systems extract information about an API routine from the Java code itself and combine it with text written by the programmer (or a technical writer) to create an API reference document. This construction of content from data, and the combining of generated and written content into a usable whole are both cases of content engineering.
Structured writing approaches that guide and validate the content that writers produce to ensure greater consistency, compliance, and quality are instances of content engineering.
Approaches such as the soft linking that I described in More Links, Less Time, which generate links automatically from metadata embedded in the content, are examples of content engineering.
Narrative Science, a company which creates software that can generate narrative content from raw data such as sports scores or sales figures, is an example of content engineering.
More advanced applications of structured writing may involve abstracting formulaic content from the author’s text and having the author instead enter fielded data which can then be turned into narrative text by an algorithm. This approach can be used to achieve consistency in expression which would otherwise be enforced by style guides and (human) editors, and allow subject matter experts to supply the data from which content is derived without the help of a writer.
But content engineering is not about removing the author from the equation. Creating better, simpler, and more reliable ways for authors to enter content, and to provide the necessary semantic metadata to drive downstream processing, with minimum interference with the author’s thought process, is also an important part of content engineering.
Content engineering is not about putting authors out of business, but about empowering them to deliver greater value and have a greater impact on the bottom line. It is not about putting them out of work, but of increasing their value so that their jobs are less likely to be off-shored or outsourced to the lowest bidder.
Content engineering is also not about removing creativity from the authoring process, though in many cases it involves redirecting that creativity into new channels, and into the imagining of new types of information products that can only be economically produced by content engineering processes.
Nor, finally, is content engineering about centralization of processes or uniformity of methods and formats, or about driving variability out of content creation. It is about generating more value through the production of superior content. Content creation is a design process, and as product design guru Donald Reinertsen comments in his book, The Principles of Product Development Flow: Second Generation Lean Product Development, (emphasis in the original):
[W]ithout variability, we cannot innovate. … If a design does not change, there can be no value-added. But, when we change a design, we introduce uncertainty and variability in outcomes. We cannot eliminate all variability without eliminating all value-added. … [W]e can actually design development processes such that increases in variability will improve, rather than worsen, our economic performance.
I will be talking much more about Reinertsen’s book in future posts, and about how his critiques of the current approach to product design apply equally to many current approaches to content creation and management. These matters are the very stuff of content engineering.
Content engineering, then, is about the application of an engineering approach to the whole cycle of value creation in content, which involves not simply the automation of content processes, but the optimization of value over the entire content life cycle.
PS: Against my personal inclinations, I am experimenting with the oft-recommended practices for writing for the Web through the increased (and, honestly, superfluous) use of headings (in some posts), highlighting (in this post), and graphics (in other posts). Does this make my posts anymore attractive of effective for you? Let me know.