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.
Mark,
Your extended definition of “content engineering” brings not only this term but also many related terms into sharper focus.
You ask for responses to the highlighting you’ve used here. I appreciated the bolding. I often skim blog posts before reading them (or instead of reading them). Your bolding instantly surfaced the structure of the piece and convinced me of the value I would find here, and it helped me navigate a quick read.
Marcia
Thanks Marcia,
I take the notion of information scent very seriously, so it is useful to know that the bolding is filling the purpose. It’s not the place I personally look for information scent, but hi ho. If it works, it works.
I like your summation… “Content engineering, then, is about the application of an engineering approach to the whole cycle of value creation in content…”
I especially like the inclusion of the word “value”. Not every content worker can or should be a content engineer. But every one can and should add value.
Thanks for the comment, Chris.
I have become a disciple of Lean, and so I try to place “value” at the center of everything. Engineering, in a Lean environment, is all about ensuring the flow that create value, and eliminating the waste that hinders it. It creates the environment is which writers can create the greatest amount of value with the least amount of waste.
I like the bolding, but I’m also aware that it must increase the time required to write the post (either to decide what needs to be bold, or writing so that you have bold-able text). I agree that it makes the post easier to skim.
I like graphics when they’re relevant, or at least amusing (for blogs). I think it’s reassuring to see that the post isn’t solid blocks of text, and there are some break points (even if the image isn’t replacing or reducing any of the text).
Same with headings: I use them because I’m used to writing that way, having had it beaten into my head as a young tech writer that readers need visual breaks. I agree that headings can be superfluous (most of the headings in my posts are), but they work as pause points and as transitions.
Good post, by the way. I’m not sure whether I’m a content engineer or not, but I suspect that the fact that I build doc sets and delivery systems puts me towards the content engineer end of the techcomm spectrum (even if what I’ve built are wikis or knowledge bases and not full, DITA-based publishing systems).
Thanks for the comment, Neal.
My method is definitely to write first and bold afterwards. I can’t imagine thinking in bold phrases as I compose.
I certainly would not consider DITA-based publishing systems to be the apogee of content engineering. To my mind, content engineering is all about value and the elimination of waste from the content process. That is all about right-sized solutions.
I believe that many expensive content management installations, and the disasters that frequently follow, could have been avoided by a more engineered approach to the writing process. Often, content management systems are designed and deployed to manage messy content, rather than to clean the content up.
DITA is a heavyweight systems with a lot of overhead and significant training and tooling requirements. It requires substantial reuse, and usually the multiplying effect of several languages, to make it pay off. I don’t doubt that there are organizations for whom DITA is a reasonable content engineering solution. But it is not for everyone.
Sometimes the best engineering solutions are the simplest and most elegant rather than the most complex and expensive.
Thanks for this formalization. I’ve been using the term for a while now, but I haven’t always been able to describe the role with the clarity that you’ve provided.
In particular, you make an important distinction in relating the role of content engineer to the full content lifecycle, and not just to content management. Content is an asset that flows through the system, not something that exists in isolation at several points in that system. A defining characteristic of the role is the ‘big picture’ view, during both design and implementation, that encompasses the technical expertise of several more focused practitioners.
Engineering involves finding optimal (or at least practical) solutions, which necessarily includes business parameters, usually expressed in terms of money, time, or both. Actual engineering goes beyond designing a content architecture based on what worked for some other organization, or because we know how to use some cool feature of the software or the standards. It requires a broad-based functional knowledge of software and standards, as measured against an understanding of the business drivers.
Lastly, I believe (as a student of anthropology) that content engineering must also incorporate human factors. It’s not enough to design and build based on relevant standards and the optimum software choices. Understanding how actual users will interact with the system and with the content can help us identify and avoid impractical or inefficient implementations that impede achievement of the business goals.
Thanks for the comment, Tom.
I agree that content engineering has to incorporate human factors. One of the principles of Lean is that is it a mistake to optimize individual parts of a process. All that does is create work in progress queues around the optimized process, which are wasteful. The correct approach is to optimize the whole process from beginning to end. It is more important that the whole flow smoothly than that one part run optimally.
I think that has been a problem with many content management projects in the past: they seek to optimize content management or to optimize publishing, often at the expense of the other parts of the content process.
Why do we need content engineering? Read my article, “Content Strategists Must Become Engineers of Content-Driven Customer Experiences”. It illustrates how a mastery of content strategy aimed at the web or technical documentation is not enough.
http://thecontentwrangler.com/2013/07/29/content-strategists-must-become-engineers-of-content-driven-customer-experiences/
Joe Gollner has written a lot about this topic as well. Here’s a great piece: “Architecting Information and Engineering Content”
http://www.gollner.ca/2010/02/architecting-information-and-engineering-content.html
I’m happy you have covered this topics and I look forward to reading an upcoming book on the subject by one of our peers. It’s good to be a content engineer.
Scott 🙂
Thanks for the comment, Scott.
Thanks also for the links to your article and to Joe’s, both of which I have read before, and both of which help to highlight how important content engineering becomes when we begin to produce, manage, and deliver content on a large scale.
A book is about the limit of what we can produce using craft methods. (I can say this with assurance, give the struggles I went through to complete my own book.) Beyond that, craft methods tend to end up producing what I have called Frankenbooks.
While content engineering methods can and should be applied to smaller scale projects as well, beyond a certain size of content set craft methods are simply not viable.
I was about to refer to Scott’s post and here he mentions it.
Engineering does not really include the ‘management’ aspect (may be this is in context of Indian education system), and that is why a majority of engineers opt for a management degree. And this combination of ‘engineer plus management’ helps them earn good positions in corporate, when compared to ‘only engineering degree’.
For me, engineers may not be capable of dealing with ‘abstract strategic challenges’ that businesses face, as they are more involved in ‘structural, design and functional’ aspects. And this is where management comes into play. So I am not sure if we as ‘content engineers’ includes all facets of our work, skills, responsibilities, and challenges, as comprehensively as this term suggests.
Thanks for the comment, Vinish.
I would not be comfortable with the notion that engineering does not include management. I think the two are intimately connected, and to divorce the two is to invite disaster.
But perhaps your point is that engineering is not, itself, an executive function, which I think I can agree with. Content engineering is not content strategy.
That said, however, I don’t think we can see the role of content engineering as simply subsidiary to content strategy, at least not in the sense that the content strategists job is to come up with the plan and the engineer’s job is to execute it. That does not work because the content strategist generally does not know what is possible technically.
A successful project, it seems to me, comes from a fine balance of what is desirable, what is feasible, and what is affordable. That requires multiple skills around the table, not a flow of orders from top to bottom.
Sounds like a technical writer to me.
Thanks for the comment.
If it sounds like a technical writer, then I have not succeeded in making my point clear, for which I apologize. I’ve written a followup post to try to clarify the distinction between content engineering and technical writing: /2013/11/13/content-engineering-is-not-technical-writing/
Pingback: Content Engineering is Not Technical Writing | Every Page is Page One
Pingback: Content as a dynamic resource | Story Needle
Came back to this post after reading the one about your best job. The term “engineering” is one that has different connotations in different cultures. In North America, for example, an engineer is generally someone who solves an immediately, circumscribed, sometimes narrowly defined problem – though I get the feeling this has been changing in recent years (I don’t spent that much time in NA any more).
In Germany, you could probably say much the same thing, but with an added notion that the solution should be “elegant” in the mathematical sense, or if you prefer, “high quality.”
In France, an engineer is someone who has a much broader sense of general culture than a North American engineer, and thus has a tendency to think about ramifications and consequences of the solution s/he develops. On the other hand, a French engineer will probably not find the simplest solution to a problem, since complexity is part of the fun.
The French situation proves that an engineer CAN also have a humanist education and set of references, but this is often disdained in the North American context. I’ve even heard U.S. engineers say that “humanities” education was not only a waste of time, it was the ruin of good minds.
The kind of content engineer that you are writing about, Mark, would seem, all the same, to be more like a French engineer than a North American one. Someone who shares both problem-solving ethos and humanist vision. Someone who might be called, “Jack of all trades, Master of some.” While I would have to examine closely whether I’m a content engineer, I certainly find myself at least on the fringe of this. And I have used the “Master of some” expression for myself for many years.
When I was a journalist, I always said that a requirement for that profession was “a garbage collector’s mind.” I think the same is true for technical communication. I would also say that the best of us are “connectionists” – folks who find connections between seemingly unrelated things, and make them clear, because they help people to understand and master something.
Our ability to do that equally well in a craft environment or in an industrialized process is one of the determining factors of excellence in our field, IMHO, on the content side. Knowing when to use which and how to implement it without damaging the content side, is a determining factor of excellence on the engineering side.