Content Strategists Must Become Engineers of Content-Driven Customer Experiences

It’s amazing what you can learn by hanging out in airports. If you pay close attention, you’ll find airports are loaded with valuable business lessons waiting to be discovered. For content strategists seeking to prevent themselves being trapped working in a web silo, airports illustrate why it’s not enough to focus our content strategy efforts on the web.

When I visit a new airport, I notice the architecture, the lighting, the sound, the colors, the signage, the availability of services, and increasingly, the way technology is used to improve efficiency. During a recent visit to London Heathrow, I marveled at the way computer technology is used to move passengers through check-in, baggage drop-off, and security. Equally amazing is the interchange of information between people and machines.

Facebook

Twitter

LinkedIn

Pinterest

When you first arrive at British Airways terminal 5, you encounter self-check-in kiosks — touch screen devices akin to automated bank tellers — that allow passengers to check-in, select seats, upgrade, print boarding passes and receipts. The kiosks read information from credit and debit cards, passports, and sometimes, data entered by the passenger using a touch-screen keyboard similar to the one on the iPad I’m using to author this article. They also display content on the screen, and deliver printed receipts, boarding passes, and itineraries.

Facebook

Twitter

LinkedIn

Pinterest

Once you finish at the self-service kiosk, you proceed to baggage drop, where your luggage is checked-in by an agent, and moved through an ‘automagical’ system of conveyor belts and screening machines until it is eventually loaded by humans onto the airplane. Paper plays a critical role in the process. You complete a hand-written identification tag and attach it to your luggage. A printed ‘claim check’ is provided to you by the agent that corresponds to bar-coded identification tag affixed to your bag. Not only is this information used to route your bags to the appropriate airplane, it’s also used to reunite you with your bag when you reach your destination.

Facebook

Twitter

LinkedIn

Pinterest

After you drop your luggage, it’s time to enter the security line, where technology again takes center stage. To enter the queue, you scan your boarding pass. Boarding passes may be digital (displayed on your mobile device) or printed on paper. If your pass is valid, you are allowed to move through the security queue. This automated admission process speeds things up considerably. It relieves the airport staff from having to check your documents. And, it creates a searchable digital data repository that improves the airport’s ability to track your movements; useful in a variety of situations.

Automated technologies are in use throughout the airport to help minimize (even eliminate) bottlenecks, improve process flow, reduce waste, cost, and errors. When created with usability in mind, technology-assisted solutions (even those involving paper) can deliver awesome customer experiences — in airports and beyond.

But, humans always seem to find ways to screw things up.

Facebook

Twitter

LinkedIn

Pinterest

Conflicting rules of the road: The need for standards

You need only look past the airport security lines to find the problems technology has yet to be able to solve. For instance, traffic flow. London Heathrow is an international airport that serves just under 70 million passengers a year, from nearly every country in the world. While passengers may indeed share some common traits and characteristics, they don’t share a common understanding of how to avoid colliding into one another as they walk through the airport.

Why is this?

My guess is it has something to do with the lack of a universal traffic flow pattern.

Facebook

Twitter

LinkedIn

Pinterest

According to Wikipedia, “66.1% of the world’s people live in right-hand traffic countries and 33.9% in left-hand traffic countries.” In the United States (and 163 other countries and territories) automobiles drive on the right-hand side of the road. In the UK (and 75 other countries, territories, and dependencies) automobiles drive on the left-hand side. If you watch closely, most people in the airport tend to walk on the same side of the road as they drive. In an international airport, the lack of a standardized walking traffic flow creates significant navigational challenges. Passengers accustomed to walking on the right side of the road are fighting for the right of way with approaching passengers accustomed to walking on the left. In addition to the inefficiencies introduced by the lack of a universal understanding, passengers also experience confusion and frustration. The passenger experience suffers as a result.

The need for content standards

This situation is an excellent illustration of the need for standards amongst those of us responsible for creating content strategies. Without standards, the World Wide Web wouldn’t be as universally accessible. Web browsers in one country might work differently than web browsers in another. Email apps might handle messages differently. Machine translation systems would be unable to understand other alphabets and encoding systems. And video and audio files might work on my computing device, but not on yours. Luckily, the founding fathers of the web created an architecture based on standards. And, subsequent efforts to enhance and improve the web — make it mobile, social, and location-aware — are also made possible because of universally agreed upon standards.

Facebook

Twitter

LinkedIn

Pinterest

Some content strategists have yet to grasp the importance of content standards. And even those who have, tend to limit their knowledge of standards to those they deem relevant to their content strategy ghetto. Anything outside of their area of speciality is seen as “irrelevant” or something “others” do.

But, as we can see from our real-world airport example, boarding an airplane involves interactions with all sorts of content. It involves a complex web of technology, people, processes, and standards. At the airport, printed collateral, signage, forms, passes, receipts, and other printed documents must work in tandem with their digital content counterparts (websites, kiosks, scanners, and displays). Braille signage, audio announcements, and person-to-person communication are also in the experience mix. Content strategists whose focus is primarily the web (and by extension, mobile), may lack the broad understanding of the technologies, methods, and best practices involved in orchestrating a solution that involves omni-channel content choreography.

Facebook

Twitter

LinkedIn

Pinterest

The need for content engineers

The field of content strategy is relatively young. It’s full of professionals that come to content strategy from a variety of disciplines. As such, our experiences and skill sets are different. This variety of experiences enriches our profession, especially when we share our lessons learned, best practices, and use cases with our peers.

While differences are often good, our inability to communicate an agreed common definition of what content strategists do is damaging our brand. Our differing views on content strategy (what it is, what it isn’t, what’s relevant, what’s not, who is right, who is wrong) make it challenging for businesses to know what to expect when they hire a “content strategist.” Is a content strategist someone who is a master of the English language, someone who can spin snappy marketing content into a flexible web design that responds to the screen real estate and capabilities of a mobile device? Or, is a content strategist someone who examines your current content lifecycle in an attempt to optimize it (automating manual tasks, eliminating unnecessary and expensive processes, designing workflow)? Or, is it someone who helps an organization deliver the right content, to the right people, at the right time, in the right format and language; someone who understands a little about a lot of things (technology, standards, methods, tools, processes, etc.) Or…

I believe it’s time we started thinking about these issues and how to grow the discipline of content strategy so that it is a valuable profession in which to foster a rewarding career; one that doesn’t end up going the way of the dinosaurs or the webmasters.

Facebook

Twitter

LinkedIn

Pinterest

Laurence Dansokho, Tools and Process Manager, Digital Content Management, eBay Europe, says content strategists need to be prepared to do the heavy lifting; the engineering work she says is required to connect content to customers in a global, mobile, connected world. Dansokho believes as I do: Big, expensive business problems worthy of being solved will be solved by content strategists that understand that content strategy is about connecting content with those who need it in order to solve business problems or achieve business goals. These problems are just as much engineering problems as they are anything else.

And, Dansokho adds, “strategy” is an ambiguous term, whereas “engineering” is not. Engineering is the application of science and mathematics applied to design and manufacture of complex products. It’s well-understood and respected. It’s not a word that makes you wonder. As a title it commands respect. What we need, Dansokho says, “is more talk about engineering content to solve business problems and less talk about strategy.”

One thing is clear; it’s not enough for content strategists to craft brilliant copy, free of errors, in compliance with a style guide. That’s copywriting.

Facebook

Twitter

LinkedIn

Pinterest

It’s also not enough to structure content or make it responsive to the device on which it is being viewed. That’s information architecture and information design. Content strategy is more than that.

It’s also clear that while specialists exist in every field, you wouldn’t expect a general practitioner (a medical doctor who is trained to provide primary health care to patients of either sex and any age) to say she doesn’t know anything about how to treat the infection on your foot because she’s not a podiatrist (doctor who specializes in foot care) or a dermatologist (doctor who specializes in skin care). Sure, she may need to refer you to one of these specialists should your problem be difficult to cure, or extremely unusual. But, because all physicians have a common understanding of how the body works, a general practitioner could be expected to have sufficient knowledge to talk to you intelligently about the infection, and offer immediate treatment (if warranted). Of course, if she found that her education and experience did not prepare her to help you overcome your medical challenge, as a professional, she would seek guidance from a specialist.

Facebook

Twitter

LinkedIn

Pinterest

I believe that all content strategists should be knowledgeable about the entire content ecosystem, the content lifecycle, content tools, technologies, standards, and methodologies — even those that fall outside of their area of specialization, or are tangentially-related to the project on which they are working. Content strategy problems are seldom problems with content alone.

What do you think? Is it time for content strategists to think more like content engineers? Is it acceptable for someone to specialize in content strategy for the web, but be ignorant of all the other places content exists, all of the technologies, processes, standards, methods and tools involved? And, what about paper? Braille? Audio? Video? Shouldn’t content strategists be less like copywriters and more like business consultants who solve complex content challenges?

About The Author

Known affectionately as "The Content Wrangler," Scott Abel is an internationally recognized global content strategist who specializes in helping organizations deliver the right content to the right audience, anywhere, anytime, and on any device. He writes regularly for business and content industry publications, is frequently selected as a featured presenter at content industry events, and serves on the faculty of the University of California, Berkeley, School of Information. Scott's message is clear: Content is a business asset worth managing efficiently and effectively. His firm, The Content Wrangler, exists to help content-heavy organizations adopt the tools, technologies, and techniques they need to connect content to customers.

56 Comments

1. That foot image should come with a NSFS (not safe for the squeamish) warning.

2. I have a story about those delightful BA check-in kiosks. A flight booked on American Airlines code-sharing on British Airways has two different flight numbers: a BA flight number and an AA flight number. Only the former works at the check-in kiosk. If you booked your flights with American, your reservation shows ONLY the AA flight number. Therefore, you will be unable to check in at the kiosk unless you figure out that AA flight xxxx is actually BA flight yyyy (not shown on any of your travel documents) and use yyyy to check in.

The user experience on the kiosks is highly problematic if you do not know that you must map your AA flight number to the BA equivalent.

“Is it time for content strategists to think more like content engineers?” Absolutely. But beware of falling into the trap of assuming all problems can be solved by acquiring the right tool, and that simply structuring content will solve all your problems.

The word “strategy” is the critical part of content strategy, and arguably the reason why this is an important discipline. However, just as creating a military strategy requires an understanding of how the military works and what tools it has at its disposal, so a content strategy requires an understanding of the tools and techniques available to practitioners.

I didn’t take this as an implication that all we need to do to become “content engineers” is understand and find the right tools, although I suppose some could take that away from it.

I see content engineers as being able to not just identify the paths in which content can reach its ultimate destinations (see me sticking with the airline analogy?), but to know how to critically analyze, measure, and bring automation to (where effective) the process by which it does that. Content strategy is also a super-appropriate analogy to engineering in that the best engineers design any product in the most simple way possible. They cut the fluff to make a fluid, logical system in which every element meets a very specific need in the final product.

A content strategist is just a person who is qualified to advise you on your content strategy. If your content strategy is to chip away at stone tablets, the advice that you need will deal with tool sharpening and the use of abbreviations and contractions.

A modern content strategist certainly needs to sty up-to-date on current trends. If your content strategy is simply to draw eyeballs, the advice that you need will center on SEO.

A content futurist needs to anticipate upcoming trends and leading-edge technology. The hypertext link was first conceived in the 1940s, but it was its realization in the HTML that made it a technology upon which we could build information architectures and the semantic web.

I agree that Engineering is an apt term to use, but I am not sure whether or how we have to balance our depth versus our breadth. Engineering types and editorial types rarely intersect, and they tend to ignore each other’s concerns at times.

Certainly, we can no longer expect editorial competence alone to suffice.

I hear what you are saying. I’d like to think that I’m a budding content “engineer”–or at least I’m working to become one. I think part of the problem is that there is no single way to become a content engineer, because one would need to know a little bit of everything, and that’s not easy for many people to do. I do agree with you that rather than being glorified copywriters, content strategists should be business consultants who can solve the bigger challenges. But what path does a person take to become a content engineer? Is there only one kind of content engineer? I think you present some good questions that raise a few more in the process.

Content Engineering is an exquisite term, Scott. The wayfinders you saw at Heathrow are modern equivalents of the Polynesian stick chart, the mattang–a device that encodes knowledge about a domain in a way that guides you to the successful conclusion of a task or quest. It is a combination of observation and the paring away of non-essential details, designed for usability and aesthetics. Both information and physical representation are present in a way that helps you get to your destination. Without both, in the right balance, then “what we’ve got here is a failure to communicate.”

I agree with Dick that the tool does not make a solution; however, determining the content strategy based on a knowledge of what a tool can do to support the strategy is important. This means that a content strategist must understand the power and weaknesses of the tools, but not necessarily know how to set up/configure the tools.

I believe that content engineering as you descirbe it is in fact a new role that complements the role of a content strategist. Content strategists understand the customer, the content and how best to ensure that the content meets customer needs. And they should know how that strategy can best be supported using technology. The content engineer understands the technology and determines how to configure or set up the technology to support the content strategy. I do not believe that every content strategist needs to know how to code, but a content engineer does.

This role of a content engineer would become a vital member of the team in implementing the content strategy. This role is becoming more and more necessary as successful content relies more and more on the power of the technology (e.g., adaptive mobile content using such technologies as XML or APIs).

“Content Engineering” is a phrase that I have some familiarity with, as some might know. It is a phrase that was given the most serious early attention by my colleagues at Stilo Corporation and before that OmniMark Technologies. During my tenure at Stilo, one of my side activities was to torture the concept of “content engineering” unrelentingly. The focus was very much on applying the discipline of engineering to large scale content challenges. Now the discipline of engineering entails a good deal more than the application of mathematics and science to the business of content, but they are indeed too important components.

I have since come to use the phrase “engineering content” which applies a slight turn to the idea but the general thrust remains the same

On the relationship of Content Engineering and Content Strategy, I do agree with the basic point that you are making Scott and that the others are reinforcing. The technical side of the equation, and perhaps more importantly on the side business completeness and long-term sustainability, there is definitely a role that needs to be played and that is not typically played by the Content Strategist. The strategists tend, at least in current manifestations, toward the editorial side of things. And while I agree that this is not sufficient it remains necessary and those on the engineering side can rarely if ever cover this side off. I think that Murray hits on this same point. And I do admire practitioners from the editorial side of things so I don’t think it works to counterpoise the two domains of practice as I believe that both are needed and that they need to work together to make substantive progress.

I wrote a little about this a while ago when I started to think about the steady rise of content strategy, and in particular on the web side of things and the shallower end of the content pool.

As I monitor the ongoing evolution of the practice of “content strategy”, more or less from the sidelines or perhaps from deep within projects where the content runs deep, I am still pretty sure that in most uses of the phrase content strategy are not connected to any definition of “content” that will help move the stakes forward. Hopefully the phrase “content engineering” at least encourages a little more depth and precision in how the root term is used.

Here’s my very basic thinking. We need to come to an organizational and temporal understanding of how this stuff works.

1. How can content contribute to meeting business goals?
This is big-picture, noneditorial stuff. For example: We want to ship a product in all our markets within 2 months of the first market launch. Our current workflow has a lag of 12 months. Our content strategy must streamline localization to support near-simultaneous shipment. -OR- We want to increase our market share by xxx and to do so, we need to win the online conversation about why feature X is better than our competitor’s inferior feature Y. We need to make sure that our content is optimized so that potential customers find it and understand our offering. Currently, only 10% of potential customers actually know about our fabulous feature X, but of those 10%, 90% buy our product. Increased awareness of feature X will drive sales.

2. Given a content strategy (see step 1), how do we execute on the strategy? This is where content engineering comes into play. We need XML content because it will streamline localization. We need to publish HTML (and not just PDF) to help with SEO. We need a CMS to manage authoring. We need web analytics. And so on.

3. Given a strategy and an engineering solution, how do we create the needed information? NOW, we can talk about editorial calendars, voice and tone, and other aspects that are (incorrectly, I think) described as content strategy. These are not strategies…they’re tactics.

4. How do we sustain this effort for the long haul?

5. When do we reassess our strategy, engineering, and tactics? What changes in the business would lead us to reevaluate the current approach?

Exactly, Sarah. That’s why I think all this attention on tactics is damaging to the “content strategy” brand. Anyone in upper management with an understanding of the word “strategy” knows that “editorial calendars, voice and tone, and other aspects that are (incorrectly, I think) described as content strategy” are tactics. They’re not strategic, at least, not within the context of the engineering.

When a ‘content strategist’ tells a client: “What you need to do is create compelling content…” I ask, “And, how exactly, will the compelling content be delivered to those who need it? How will you ensure it’s in the right language? That they’ll get the piece they need and not something you think they need? How will it be created? How will it be published? Will the new approach be slower than the old one? How much will that cost? And, what about personalization? Or, localization? Or, machine translation?” Most of the time, without a knowledge of much more than what is labeled ‘content strategy’ buy the most vocal in the herd, we get nothing but generalized advice about content. That’s got to change if we want to be on the radar screens of the folks with the money…the ones who want to solve the business problems (see examples from Sarah) that are keeping executives up at night.

I think we are making progress by having these discussions and by challenging others in our discipline to think more broadly. Once we each step outside our comfort zone and learn about how technology, processes, people and content work together, we will command much more respect and be in great demand for some time to come.

The term “content engineer” sure seems to be gaining traction. For example, Joe Pairman (whose newish blog is called “The Machinery of Content”) moderates a thoughtful Google+ community called “Content Engineering for Humans.” Joe Gollner has a fine preso called “Introduction to Content Engineering” (http://www.slideshare.net/jgollner/introduction-to-content-engineering-cci2008). The term has merit, and it may even be “exquisite,” as Don Day says.

But your closing point hits on something important: “Engineering types and editorial types rarely intersect, and they tend to ignore each other’s concerns at times.” To me, the term “strategist” (as opposed to “engineer”) has value in part because it implies an integrative level of thinking. The ideal strategist looks at the big picture, including both the engineering and the editorial.

Quite a thought provoking post!
On the face of it, a strategy appears to be more about analysis, planning and roadmap and engineering appears to be more about its execution. However, many technical communicators are doing both-strategy as well as execution.

Although there is an overlap and in specific cases, engineering involves planning and strategy as well, I agree with what Murray M says as “…but I am not sure whether or how we have to balance our depth versus our breadth. Engineering types and editorial types rarely intersect, and they tend to ignore each other’s concerns at times.”

Scott, I agree with you that the term content strategist is very broad in its use and interpretation. Independent of what it’s called, I think the term “strategy” is appropriate. One of the things often overlooked by companies, and consultants, is the willingness to take the time to step back and understand the company’s business strategy (e.g., 3-5 year plan, key objectives, business drivers and pain points, growth plans through acquisition, extension into new geographies, customer experience management, etc.).
Without understanding the overall strategy, how can one ensure the content strategy and solutions being architected and implemented will deliver on the necessary results to contribute to the company’s overall goals?

I fear that in our zeal to develop a content strategy approach, we have found ourselves focusing more on the strategy process and its details instead of the content itself. Few projects really look at the underlying intellectual value that must be communicated before launching into selection of formal protocols, syntax, software approaches… and tools, and the other detail components of what should be preceded by a thorough and highly functional look at what content is supposed to do in the particular effort.

While the content itself (as distinct from its representation as data) gets some lip service, most “content engineers” are really technologists who find content the least interesting part of what they do, so they can’t wait to get to the fun stuff.

It seems to me that we need to develop a class of professionals who understand and focus on the intellectual value that will become content and the ways it can best be captured for management, location and use. Back in the brick and mortar library days, the professional cataloger at least partly represented this class, but they have sadly fallen by the wayside in today’s connected world (partly the library world’s own fault, but sad nevertheless.) We need to go back there and build again, toward our current and future technological world.

Interesting question. My sense is that, like medicine, there is room for both generalists and specialists. True, we should all know enough about the various facets of the field, but we need to continue to define and develop them. People have the aptitude and experience to be specialists at different things; I’ll always be on the linguistic/cultural/design side more than the engineering side.

I like how Steven Johnson looks at the subject of innovation. Often, it occurs because someone who knows a fair amount about multiple disciplines or because multiple specialists from different disciplines are trying to solve a problem. You could become a specialist because you put disciplines together that haven’t been combined before.

“I believe that all content strategists should be knowledgeable about the entire content ecosystem, the content lifecycle, content tools, technologies, standards, and methodologies”

I couldn’t agree with this more. And looking at the big picture is what separates a strategist from an engineer. Like others mentioned before, these are potentially two different roles. Though, as with any position, a single person could fill many roles (copywriter, engineer, strategist, IA) – or there could be an entire content team made up many people in all the various content-related roles. Therefore, it is important that we in the field of content strategy do define what it is that means – along with all the other content roles and where they intersect with other disciplines and roles.

I’m glad to see more of us writing and talking about this. As you say, the field of content strategy is young and the people who are in it bring a wide variety of skills, knowledge, and tools to it. We do need to fully define what a content strategist does (and yes, that goes beyond just the “web”) so that we can start training people to become effective content strategists. Most of us currently practicing content strategy came to it accidentally – and did it before it had a name. But that can’t go on forever. Maybe once we practitioners come to a consensus about what a content strategist is we can get universities to create programs that build the right base of knowledge for students to enter the field AND let them know the field exists.

Thanks for sharing the links and your views. I agree, it’s the bigger picture I’m trying to get us to aim at. If we do, I believe we’l have continued success and a long future as strategy consultants for business content.

The discipline of information management (including content management) has often tried to connect to a more ‘substantive’ metaphor/discipline to gain better traction. Unfortunately, the raw materials we work with every day and the context in which we do that work are much less grounded than, say. construction or automotive design and manufacture. The single word ‘architecture’ in your article, for example, is loaded with ambiguities – some of which you mentioned. I believe this ambiguity is what your article is trying to address by substituting a relatively abstract term (strategy) with one that is less so (engineering) thereby strengthening the perception that what we do is on par with what takes place in the ‘real’ worlds of bridges and cars.

The problem is that information – and the multiple human and mechanical dialects used to manipulate it as a raw material and a finished product – does not as readily lend itself to engineering principles. This is largely because, again in my humble opinion, we do not yet have the correct ‘geometry’ in place to achieve our objectives in a predictable and measurable way.. By that, I mean that while engineers live and work in three dimensions, information – and the tools like indexing, taxonomies, hierachies of all stripes and even well-established ones like set-based (relational) databases – are simply missing the dimensionality required to elevate IM (and by extension CM) to the level of stability required to make it a concrete/operational undertaking,

I hear you and agree that there are complexities and challenges that prevent us from achieving what is indeed technologically possible. And, you are correct. I am hoping to help us avoid the ambiguity of “strategy” and replace it with something upper level managers with budget can understand: Helping them to achieve actionable business goals.

Is all content ready to be engineered. Well, I can’t speak for the content itself, but the answer is likely to be “no”. But, are there many types of content that would benefit from a touch of engineering? Clearly, the answer is yes.

I’m going to challenging some of the best-and-brightest to show us example of how engineering and content strategy can work in action. I’ll try and lead the way on a future project (announced later this year).

Thanks for your contribution to the discussion. Much appreciated. Spread it around.

Great point, Scott. I like to think of myself as a bit of an intersection between editorial and engineering types (wishful thinking?). I’ve recently found myself engineering my way out of a future-vulnerable approach to documentation — trying to future-proof our docs in advance of changes I see coming to our idea of what a software “product” is, and how people will interact with these things. A long story…

The point is, while approaching it as an engineering problem, it seems hard to distinguish this kind of planning for the future from a content strategy. So which is it — engineering or strategy? I think there’s a lesson in this. Textual content at least is opening up to more and more processing. We know how to combine passages on the fly, how to measure the environment for contextual cues, how to adjust output in responsive ways. Further, we are blending content with product — embedded docs, GUI design, etc. In short, we know how to engineer content and we know how to add content to engineering. So yes, the notion of a content engineer feels right.

I don’t see any one individual embracing both editorial and engineering disciplines to an exquisite degree. But the kind of individual we’re talking about needs to know enough to recognize content *engineering* when he or she sees it.

Agreed, Chris. It’s more than wishful thinking. It’s the way of the future and you are right square in the midst of it. Keep making progress and fighting for the ‘future-proofing” of your content. That’s where the value lies. And, we’ll get there. It’s just going to take some time to break the addiction to old ideas and to get folks from editorial to better understand the technologic and business issues, and vice versa. It’s going to take a while to get there, but at least we have fully-functioning exampled from technical communication and marketing to help others learn and grow.

Great article full of ponderable points.You clearly identify a communications gap aching to be filled for those who would hire us to solve their content issues.

(To any non-native English speakers who are reading the comments, “Dick” is a common familiar or short name used for and by people named “Richard”. Scott was answering Richard Hamilton, whom many of us know as Dick Hamilton.)

I love the term content (or information) engineer. It is content strategist that I am unsure about. I feel like a ‘content strategy’ would be just one responsibility of an information architect (built in consultation with the executive staff or project stakeholders). I know over the years IA has been slanted toward web design, but that seems like an unfortunate and inappropriate view of what IA really is.

One of my favorite quotes is “Engineers know the answers, Architects know the questions.” With that in mind I believe it is the role of an information architect to design a solution and engineers to figure out how to implement that solution. Graphic designers, UI designer, technical writers, videographers, etc (what I would consider domain specialist) bring the solution to life.

Architect – what to do
Engineer – how to do it
Domain Specialist – do it

It would be great to see the term information engineer take hold. And a standard body of knowledge or certification created for both information architects and engineers would help legitimize those fields and offer guidance to executives and practitioners alike. It would also help more architects rise to enterprise level and claim a seat at the table.

I’m a big proponent of balancing the editorial and technical sides of content in order to design and engineer content. Focusing on only the technology side, you can use technology to speed the process of distributing poor-quality content. Focusing on the editorial side, you can have compelling content without the “legs” to leverage it well. So you’ve hit the nail on the head here. It’s about the elegance of the content and the technology to support its use, and standards are the way to make the magic happen.

Your Heathrow experience made me think of points made in Wurman’s “Information Architecture,” e.g., “…information structures that allow others to understand.” I especially like your analogy to a medical practitioner. And I agree that the core task is to connect the right content to the right person at the right time.

Fundamentally, every organization has objectives, and it has capabilities. Strategy is about optimizing the use of your capabilities to achieve your objectives.

The problem, most of the time, is that the people who set the objectives do not understand the capabilities, and the people who understand the capabilities do not understand the objectives.

It is not enough for the the engineers and the executives to sit down in a room together, because they continue to talk past each other. The executives ask the engineers to build the things to accomplish the objective they have already decided on without understanding the capabilities available to them. The result is almost always that they either ask for far less than is actually possible, for for things that are well beyond impossible.

The role of the strategist is to be the person in the room who understands both capability and objectives. They are the ones who can ensure that the organization does all that it is capable of, without overreaching.

At the same time, the strategist has to look beyond existing capability. Developing new capability is essential to achieving strategic advantage. Bletchley Park and Alan Turing are as important to the war effort as the navy or the air force.

How accurately Mark Baker has put it as “The problem, most of the time, is that the people who set the objectives do not understand the capabilities, and the people who understand the capabilities do not understand the objectives.” I guess this explains the whole point of where strategy and engineering do not intersect.

I appreciate the call to action for some standards in our practice. The discussion about the connection between an engineer’s methodology and how we can apply those elements to our content strategy practice is an exercise that I feel allows a budding strategist to really take root in their professional environment.

They gain the legs and voice to stand ground and not get pigeon-holed as a “glorified writer” or “just another creative talent.”

Many of my peers are civil engineers. While they share a lot of consultancy-based methodologies along with how content developers and strategists pitch, build, and govern their projects, they have something that we don’t– government regulations to meet.

Civil engineers and their clients can design all they want and create extravagant, simple, or outright nutty solutions to design problems. However, if they don’t meet city code or regulation, they don’t work.

I’m not saying we need to create a Department of Content Strategy and start writing declarations and law and whatnot, but taking the exercise of discussion, creating, and iterating upon standards is huge not just to improve our collective quality of work, but to wave a rallying cry around our profession. Many of my fellow commentators have cited works in progress that do this.

The open sourceness of the web makes it very hard to establish a sense of standardization across the different web practices. New languages spring up daily. You can code in lolcat if you really want to.

But, I believe it’s discourse like this that can lead to discovering standards, if anything, common ground, around content strategy methodologies and assets that clients across industries will find as a worthwhile investment.

Hi Scott,
Very timely article here and looks like you’ve created quite a debate. I haven’t been able to read all the comments here so forgive me if I repeat someone above.

I agree with a lot of what you’ve said here. I think content strategy does have a branding issue – why else are people still debating what we do? I think this is due to a number of reasons:

1) It’s still a relatively new field even though we’ve been doing it for ages now.
2) It encompasses a broad spectrum of skill sets, no two content strategists are ever alike.
3) There is general confusion amongst content strategists about what we do and in an age of self-publication this confusion can only get amplified.
4) There is general confusion over the term ‘strategy’ – some people think it means tactical deployment, others about defining the vision for a company.

On that last point – my experience with business is to underplay the use of the term ‘content strategy’. It scares senior management so it’s better to talk about creating ‘user-centric content’ that hits ‘business goals’.

I think all these points just indicate that this subject matter is still in its infancy. I like the term ‘content engineering’ because it implies a more hands-on approach. As a fan of Philosophy I can’t help but see similarities between the Rationalists and the Empiricists here – both approaches (Strategy and Engineering) are fundamentally different but they both get closer to the truth, a two-pronged attack’. Maybe, we need to split the filed into ‘content idealists’ and ‘content engineers’ – but I fear that may cause even more confusion!

But back to your original point – yes we need standards but this is going to be a challenge when so many fields are merging. I think this will come in time.

Lastly, and I have to squeeze in another philosophical term here – we have to be careful about the ‘hegemony’ of ideas. I wonder if sometimes as strategists we often announce new terms without acknowledging where they first came from. The origins of content modelling is one example. When talking about new ideas we should acknowledge the past, or risk making similar mistakes – to coin someone’s phrase. Obviously, this is not directed at you.

Steven: Thanks for sharing your comments with the group. I really appreciate it. And, if you know others who might also find this discussion of interest, please share a link and encourage them to post their thoughts. I think it’s time we started having more of these types of conversations.

Content Engineer is a great descriptive title. I definitely think we should promote it so that we can differentiate this role from Content Strategist. Kudos as well to Joe Pairman for working on this. I agree that content engineering tasks are complementary to strategy tasks as part of the content lifecycle whether they are performed by the same person or multiple.

When I first read the description of the airport system, I thought that if I were designing the system I would use my software engineering skills and the software development lifecycle (SDLC). And when I read about the different pieces of customer facing content involved, I thought of the content development lifecycle (CDLC).

I recently explored the CDLC tasks (requirements, design, implementation, test and maintenance) in my article, “Learning to Manage Your Content”. And noted the parallelism and similarities of the same named SDLC tasks.

In addition, everybody’s content is different. And everybody’s processes are different. You can’t pick a tool, CMS or schema until content requirements are known and processes are designed. Sounds like a type of engineering to me.

User experiences are typically a combination of data and content, even more so today. So I expect even further integration of CDLC and SDLC tasks, Agile processes, etc. Big Content becomes Big DITA?

So the idea of using “engineer” in combination with “content” makes a lot of sense to me.

Yes, I agree. Great conversation. I think what is interesting to many who don’t come from the content engineering arena is the realization that the NPR model (COPE) was really about multi-channel delivery and those efforts were preceded by work done in the field of technical communication (think “Managing Enterprise Content: A Unified Content Strategy [2001 New Riders — http://www.managingenterprisecontent.com — revised and updated in 2012; and, single-sourcing, the practice of writing content once, and using it often) over the past 15 years or so, it’s clear that there are lessons learned and best practices that can be applied to all sorts of “content strategy” challenges that would benefit from some “engineering”. I hope we can all work together to strengthen the content strategy brand and make it something that all businesses take seriously and adopt in meaningful ways.

For those of us already involved in the discussion here, I’d like to ask that you each recruit a new person to the conversation. It’s nice that we all agree (for the most part) and see the value. But, the people who are absent from the conversation are all of the folks who aren’t talking about “engineering” and related topics when they discuss content strategy. If we are going to move the needle, we need to get some of the more visible content strategists to join the discussion and to see the value of our contributions.

Please share a link to this article in your Twitter feed and spread it ’round the web.

What a thought-provoking post. I agree that the term “content strategist” has been abused. A strategist should be able to see the big picture, taking advantage of technical capabilities and organizational strengths alike to make content really work for the organization.

But as someone who’s been trying to push the term “content engineer” (thanks for the mentions, Marcia and Mark!), I’m wary of using that term too broadly. Just as there’s not much real strategy in many people’s conception of content strategy, so the word “engineering” risks losing its power.

In the slide deck that Marcia linked to, Joe Gollner defined content engineering as “The application of rigorous engineering discipline to the design, development, and deployment of content management and processing systems”. Two things appeal about this definition. One is the focus on the technical systems. I do feel that the role of a content engineer should be complementary to that of a content strategist; while the latter should have a good feel for technical capabilities, it’s the former whose job it is to champion the system itself, including the system’s needs, hidden capabilities, and optimal content architectures.

The other important part of that definition is the focus on a disciplined process of system development from design to deployment. That ties in with the traditional meaning of “engineer”. Although the term is now often mixed up with “developer”, it has a much grander history than that. We should aspire for content engineers to be Isambard Kingdom Brunels, not bedroom hackers. They should have a deep understanding of the goal (the business requirements), the materials (the nature of structured content and the various technologies which support it), and the architectural principles that combine the technologies and their users to create a stable system.

On a practical level, this means following the kinds of processes that Mark described. Not just going through the motions, but really working and thinking through the processes. And it’s worth noting that it’s not always necessary for the roles of content strategist and content engineer to be performed by different people. Especially on small projects, it may be difficult to dedicate separate resources. What’s important is that the two roles are each given sufficient consideration and that when someone’s wearing a content engineering hat, the technical needs and opportunities are not neglected.

Thanks for the post! The idea of a Content Engineer is a good one. They have to engineer connections among readers and businesses and be knowledgeable about more than one form of strategies for posting. The marketing culture is changing and the content marketer needs to adapt and change with it.

One aspect of “content engineering” that I think is under-appreciated is the need for good testing both of processes and of use. Every workflow needs scenarios, test content, expected results, error reporting and ways to test outside the system. Don’t discuss this aspect of “how to measure success” for business after agreeing on the tools and roles – work with the client to determine who will test what, and how, as part of the partnership involved in getting a good solution set up from the beginning. Prototyping and building test suites with discrete unit tests is a very valuable part of engineering a content solution.

It would be helpful if the content engineering approach resulted in some standard test suites beyond the DITA garage example, that include every element in a standard that can be processed with standard applications – as HTML is by browsers. Just because an XML standard has hundreds of elements with thousands of possible combinations doesn’t mean that there can’t be some standard test suites developed so that every project doesn’t have to come up with its own test content.

I learned of unit testing because I once worked where we had to push XSLT to a staging server and then to live servers used by thousands of people an hour. Without a sandbox and unit tests that had to pass QA before going live, we would have had some seriously unhappy users. But even if a content system will be used by a small group of users, they deserve the thoughtful approach that will prove that they are getting what they paid for.

I think a content strategist needs to understand enough about coding practices – not how to write code per se – so that they can include discussion of the test suite early on. And a content engineer should be thinking about what the unit tests might need to be, so they can request them as part of the implementation.

I am really pleased to see what is coming out of the discussion although I know that some of you were already talking about it for a long time.

Joe, I like your definition of content engineering “The application of rigorous engineering discipline to the design, development, and deployment of content management and processing systems”. When I started the conversation with Scott, I haven’t seen it, but your definition explains very well the concept.

We live in a world where technology is omnipresent; content and technology have a symbiotic relationship. Alignment between people, technology and processes is key for business success; this is also true for the successful implementation of a content strategy.

Business macro-environment like structure of industry, political, economic socio-cultural, ethics and technological factors surround and impact upon an organization but technological changes is the only constant. Some of the most innovative organizations view technology as a primary engine of change for their companies and so, I believe, does technology with content publishing and consumption.

As content practitioners we experienced in the last decades changes in our collaboration with marketing, product management, UX and other teams, the interaction with tech/dev teams start playing a bigger role in our day to day work. We (should) start paying the same attention to editorial and technical requirements as well as to standards and processes. All are content related requirements aiming to address existing or future customer and business needs as well as to improve internal processes. And yes sometimes it involves technical development (e.g. development of a new application for a marketing newsletter ticker).
The discipline of content strategy has evolved but still does not address enough the process management and technology aspects of it; I would assume that it is different in the technical documentation industry.
The question is what can and should we do to change that, which leads also to the question: “Is content engineering” the next generation of content strategy or a subset of content strategy?

I want to pick up on Joe Pairman’s comment where he cites Joe Gollner’s definition of content engineering. “The application of rigorous engineering discipline to the design, development, and deployment of content management and processing systems”.

That’s not my definition of content engineering. Joe’s definition is about the engineering of content management, not about the engineering of content. Apply engineering discipline to the management of content is a good thing, but it is not the same thing as the application of engineering to the production of content.

To a very large extent, content engineering and content strategy both still treat content as a kind of craft product that must be acquired and managed in an engineered way. The content itself is often treated, to borrow Rahel Bailie’s recent phrase, as “the hole in the template”. We put the content in a box and engineer the management of the box.

To me, content engineering is about engineering the creation of the content itself, about replacing the craft production of content with the engineered production of content. Content management, to a large extent, then becomes a side effect, a consequence, of engineering the production of content.

I can, incidentally, provide a little bit more of the history of the term “content engineering” in the OmniMark/Stilo context that Joe Gollner mentions above. The way it entered the OmniMark lexicon was that the then head of sales, Benoit de La Selle, uttered the phrase casually in the course of a conversation and I seized on it and suggested it was the phrase the best described what OmniMark Technologies was doing. It entered our lexicon from there. I’m quite certain, though, that it is a phrase that has many independent points of origin in this space.

@Mark’s comments echo my own reaction to @Joe’s input: there’s a huge difference between designing systems for managing containers (Joe’s reality) and designing systems for managing the contents of those containers.

This may seem a heretical statement in this forum, but I suggest that the gap we see between what a content management system delivers from a technical point of view and a layperson’s experience of content management (search is a great example) is directly related to the lack of balance between the two solitudes.

Any use of the moniker: ‘Content Engineer’ had best be prepared to bridge that gap or risk being assigned to the dustbin.

Thank you Scott for providing such a stimulating and thought provoking topic. Is it time for content strategists to redefine themselves as content engineers? Although I fully embrace the idea that it is time to more fully differentiate ourselves from other disciplines where there is a great deal of overlap (e.g. information architects, copywriters, digital strategists), I see a clear difference between the role of a content engineer has vs. a content strategist. I agree with Mark Baker that there are professionals out there like Joe Gollner and a select few, whose expertise on the technical side of content, primarily in content management sort of defines for me the definition of “content engineer”.

In fact in the last year, I had reason to reach out to him and a few others to help provide technical advice for a big data project. And therein lies the challenge. Although I grasped the need to address and connect the dots between creating the strategy behind the content, how to make recommendations for the processes behind the creation of the content, and utilizing best practices for the management of the content – 1) technology is not in scope with the role I/we at the agency played 2) there were those like Joe who have the expertise and tools to really understand the complexities of the technology in order to do the work.

At least in NY, it seems to me from being involved in the foundation and growth of the CS-NYC (content strategy meetup) to several hundred, since its inception a few years ago, a great deal of people who call themselves content strategists are employed by agencies. Scott, you are right – one of the problems is the lack of consistency in how we define ourselves and how those who employ us define the role. Most agencies do not get involved in the nitty gritty of helping clients develop processes and methods for maintaining content – let alone getting involved with the technology. Hence, I think there would be real push-back from those who are earning a living at this to now say – you need a whole new skill set and one that may not be supported by the industry.

Although I am not fully on board with changing my title to ‘engineer’ I do agree that it is time to differentiate our role. And most importantly from a business perspective, there is an opportunity to fill a void that exists int he marketplace to help clients not only create the strategy behind the content, but connect that with new processes, technologies, and methods to create, maintain, and promote consistent messaging through multiple channels. In fact, perhaps our greatest value as content strategists is to provide an instrumental role to the client of being the glue between technology and creative.

As this thread is illustrating, perhaps the hardest thing of all is to settle on a set of definitions. In line with Steven’s introduction of philosophy into the discussion, this is the business of philosophy which is, at the end of the day, very much about the definition of concepts. In my own pursuit of a useful positioning of the concept of “content engineering” I found that more and more I was spending my time wrestling with the definition of core concepts. So I welcome this discussion.

I wanted to pick up on a couple of the threads. One is about the utility of the concepts Information Architecture (IA) and Information Engineering (IE) that Nathan introduced. This took me back. At the outset of 1998, I was forming a new company and as unrepentant SGMLers we were all agreed that what we were ultimately doing was architecting information. Hence our name became XIA Information Architecture (complete with a GNU-like recursive acronym). At pretty much the same time, the Web Information Architecture (IA) train was leaving the station and in a few years we decided we needed to bury IA a little deeper and become XIA Systems. The issue was that we wanted to focus on the structural patterns within the information products and transactions and in common parlance, aka web parlance, IA had come to be largely caricaturized as site structures and menus. On the Information Engineering (IE) there were uses of the phrase that were very soundly rooted in mainstream information technology and data processing but that were not easily repurposed to look at the larger spectrum of what is usefully, and inescapably, meant by the word “information”. Following this line of thinking has led to me playfully redefining the ubiquitous position title of CIO from being “Chief Information Officer” to “Chief Infrastructure Officer” – and then refusing to recant unless someone can produce a CIO who can provide a non-laughable definition of what they mean by “information”.

On the architecture thread, in my own work on the “content engineering” workshop that has been cited a few times here, and the working definition based therein, I have frequently situated “content engineering” very much on the technical side of the equation. In these inquiries, I would then get to a discrete phase/task/role of “content architecture” which then focuses on how the content itself needed to be represented and evolved. This was a way to say that somewhere between the “content strategists” and the “content engineers” a rapprochement needed to be forged where the two domains converge – which happens to be on the content itself. It seems to me that the thread that is most recurrent in this discussion, and that has the most potential, is the one that I see the roots of in Scott’s initial post – that content strategy and content engineering are two distinct activities and that they ultimately need to come together if a satisfactory approach, and satisfactory results, are to be achieved. Perhaps this is the “glue” that Lisa is referring to and that I agree needs, one way or another, to be found.

Picking up on another thread, laid down by my friend Mark Lewis, I agree that we can make very good use of System Development Life Cycle (SDLC) models and methodologies – harvested from well-trodden historical practices in software engineering and engineering in general. As Steven points out, it is worthwhile to explore the origins behind ideas and practices, and in large part this is because there is a lot value that can be recovered from past work. Coming in part from defense system acquisition, I was myself immersed in lifecycle methodologies so this is a very natural thing to import into discussions of content engineering and content strategy. My most recent work, and my most recent projects, have been very much focused on excavating and then modernizing content lifecycles and in this work I am continuously struck by the fact that my Content Development Life Cycle model is essentially identical to my System Development Life Cycle model. When I bring the two pieces together I wind up with a “Content Solution Development Life Cycle” model. I think that this pathway of applying Life Cycle models and methodologies to content and to content solutions holds much promise and it is a natural outcome of applying engineering discipline to the business of content. My contribution to the May issue of the STC Intercom (The Technology Side of a Content Strategy) delves a little into this.

Finally, there is the interesting question that Laurence brings up about the relative positioning of content strategy and content engineering, asking for example whether content engineering is an evolution of content strategy or a sub-set of it. As almost always, I gravitate towards two answers. In one way, strategy ultimately stays on top. In my most recent version of my Content Lifecycle Model, about which I will post something on my blog shortly, I continue to place content strategy at the center and “on top”. There is another sense though, as had emerged from my contributions here, that content strategy and content engineering approach the same challenge from two different sides – the business side and the technology side. And that shared challenge is the content itself – where a brokered agreement between the domains must be worked out. In this activity, which I tend to call the “content architecture”, it does not help to place one role above the other. Both are needed and both need to collaborate if the result is to sparkle.

There are other threads present but I think I should resist picking them up. Suffice to say that, from the foregoing, it should be clear that my continuously evolving position does not suit simple characterization for example as transfixed on only one part of the problem domain such as content management (or better still “container management”, which sounds like even more fun). As a general principle, some threads are best handled offline.

I’d like to see a ‘non-laughable definition of information’, too – from anybody!

The only comment I’d like to add to Joe’s excellend summary is that there are three sides to content: the business (which, unless it is authoring content to directly create revenue does not really care about content management); the content strategist – whose role is to help the business acquire, transform and distribute information it needs to optimize its revenue; and, a content engineer whose job it is to minimize the time and space between the first two stakeholders.

If I had to draw a picture it would be in the form of a tetrahedron with content at one point and the roles, responsibilities, principles, tools and techniques for the others on the other three.

Second, the whole people running into each other happens a lot in Chicago. Even though we are mostly Americans, people walk towards the left on sidewalks and in crosswalks. It is a mass of people coming towards another mass at large intersections and lots of dodging. If you try to stick to the right, you end up dangerously outside the crosswalk. I don’t encounter this problem in New York. But I love Chicago anyway.

None of this directly addresses content strategy, but I am too tired for that right now. Nice article, though.

Scott, I couldn’t agree more. Your point about responsive design is huge and yet some of the best content strategists don’t act on it. Much of the content out there today is not truly responsive when it MUST BE. With a fuller understanding of the content creation / consumption ecosystem, I agree that content strategists will be much better off.

I work primarily with start-ups and other small companies, and a lot of times these companies don’t have the skills and/or capacity to implement the strategies that we design. That means that my team does end up doing a lot of the “heavy lifting.”

Even so, I don’t think I would change my company from a “Content Strategy Consultancy” to a “Content Engineering Consultancy” just because it feels like choosing a title based on one of the steps of the process instead of the process as a whole.

I might, however, consider giving “Content Engineer” as a title to members on my team. I don’t think I’d take it myself, though, for the same reason I don’t take the title “copywriter” or “typist”–I have the skills to do those jobs, but those titles don’t capture the unique value I contribute. I help my clients create a strategy. If they like the strategy and need help implementing it, then we move on to the engineering part.

Having not worked with big companies, I don’t know–maybe this is a unique situation for start-ups. The business leaders I work with wouldn’t have any more understanding of “Content Engineer” than they do of “Content Strategist”…they don’t really even know what I mean by “content” until I explain it!

I think there is a need for a central body, central certification, central school on this… Opportunity or labor of love, Scott? Make this a ‘thing’ vs. a non-thing, e.g. when companies seek these skills, they have trouble describing what they seek, and rather rely on long lists of the capabilities they need vs. a job title like “accountant.”

Interesting ideas, Mary. I’m not sure who should (or even if that is a good business model in today’s world) start up a central certifying organization, but I’m certain the knowledge transfer from the experienced pros to the new entries into the field is needed. There’s nothing wrong with us all learning from each other. 🙂