The many disciplines of content strategy

The customer experience game transcends the roles of the players. And still, the practices and disciplines of content strategy matter because by not defining the missing expertise many organizations are leaving engineering completely out of the picture. The result is failed projects, lumpy stale content bolted to one place, and content assets left undervalued in an organization’s priorities.

Ann Rockley (@arockley on Twitter) recently wrote a piece entitled Why You Need Two Types of Content Strategist for CMI.

It’s a helpful article highlighting the continuum between strategy, technology, and implementation.

She starts with, “I don’t deal with front-end experience. I make the content sing and dance by managing it behind the scenes. A front-end strategist tells me what’s needed, and I develop the back-end strategy to support those needs.”

And continues, “Front-end and back-end roles require different mindsets, each important. In some cases, an individual may play both roles, but most content strategists develop one skill set or the other.”

Ann’s article expresses something many content strategy, IA, UX, CMS developers and other practitioners encounter all the time: ‘The stack doesn’t end with my unique skills. It keeps going.’

The practices, disciplines, roles, and relationships of intelligent content, and digital experience management in general, are very much still being defined.

But it’s an important discussion for us to be having.

Ann breaks front and back-end strategy like so:

Image for post
Image for post

This Venn diagram does a nice job of demonstrating that strategists of all stripes must work together from the front end to the back end of the stack. Isolated efforts at the front end fall short, as do technical implementation efforts without good structure and model from which to work.

It is encouraging to see solid discussion about the back-end and front-end cooperation needed to deliver excellent customer experience. Digital teams face challenges every day with workflow and the different types of mindsets it takes to address the strategy side and the engineering side at the same time.

Image for post
Image for post

From content strategy to content engineering

I fully embrace and advocate for the concept of “engineering content,” originally coined by Joe Gollner, because it indicates the systematic application of scientific discipline in order to influence an outcome.

Engineering bridges from pure strategy to implementations. Building engineers move the ball from the renderings to the electrical and plumbing schemas. We wouldn’t build an office building without engineering first. But all too often in digital projects, IA and UX folks hand renderings to developers…without an intermediary engineer. Digital needs engineering.

So, the ‘back-end strategist’ might be called an engineer.

Content strategy and content engineering are two distinct practices. Each have multiple disciplines of their own. Practitioners learn about the whole continuum, but specialize in one track or another.

Content strategy and content engineering practices work together to create, structure, and deliver intelligent content across channels.

I define the primary disciplines of content engineering as: model, metadata, schema, and taxonomy.

Image for post
Image for post

The 5 Primary Disciplines of Content Engineering:

Model — Content modeling creates a representation of types of content, their elements, attributes, and their interdependent relationships.

Metadata — Metadata is content that provides useful, but generally not visible information about other content. Metadata helps applications, authors, robots use and relate the content in smart ways.

Markup — Markup broadly is everything wrapping content that’s not the content itself. Markup describes and presents content and can include XML and content transformations.

Schema — Schema is a form of metadata that provides meaning and relationships to content. Schema often involves published standard vocabularies, such as, for describing concepts with standardized terms. Robots use schema to understand and relate ideas.

Taxonomy — A map of related concepts which are applied to content, often as tags. Taxonomy shows content relationships by enabling dynamic collections of content items. Enables and supports features like related content reuse, navigation, search, and personalization.

Each of these is key to content reuse and getting the most from our content assets. Sure, they overlap. But as disciplines, they can be studied independently and the concepts are useful to segment for training and focus purposes.

Just because we’re specialized doesn’t mean we are myoptic. On the contrary we share tools and artifacts. The content model and the prototype are two key places where content strategists, content engineers and content marketers can meet, but there are many.

Image for post
Image for post

Where does content engineering fit?

Teamwork alone isn’t enough. Teamwork must be coherently organized, so the fruits of the work can be used. Especially when we’re mixing things up between marketing, IT, operations, vendors and partners — organizations need structures that facilitate and retain the the work products from digital teams.

I’m a fan of a chartered, budgeted, cross-functional project management infrastructure that houses the content strategy and content engineering practices, which I like to call a Digital Management Office (DMO).

Image for post
Image for post

I see the DMO functioning at the level of governance where the content strategist and the content engineer can operate independent of silos like IT and marketing, working for the benefit of fluid content across an enterprise. And ultimately working to build the economic value of content assets. For organizations with a Chief Digital Officer (CDO), the DMO is a natural fit as a key part of the CDO portfolio.

It’s good increased discussion about valuing content as an asset and dialogue about structures which support the tremendous teamwork and collaboration needed to create scalable, personal and intelligent customer experiences.

I see the content strategist as the CEO of content, and the content engineer as the CTO of content. Both are needed to deliver value.

The content strategy practice addresses the who, what, when, where, and why of content.

The content engineering practice addresses the how of multi-channel content publishing.

Everyone works towards the common goal of facilitating valuable and quality customer experiences. The game is the same. The players are talented human beings with different skills and viewpoints. It’s time to organize the field.


In my downloadable book “Content Engineering for a Multi-Channel World,” I examine how content strategy, content engineering and content management fit together, the differences between them, and why ultimately you need all three.

For a brief overview of content engineering, see “What is Content Engineering” at Simple [A].

For those at ICC or following from home, I’ll be speaking at the Intelligent Content Conference on Tuesday morning. My session is titled: “Making the Case for Content Engineering and How to Integrate Content Engineering into the Enterprise”. Tweets from the conference at #intelcontent .

Founder of [A] (, content engineering author & speaker. Topics: content systems, customer experience, strategy, digital transformation, AI

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store