Follow Your North Star to a Successful Content Engineering Team

I maintain a very simple definition of content engineering: a content engineer ensures that content has the right metadata and is in the right format to support customer needs on their chosen platform. 

In reality, content engineering is often anything but simple. How do you know when you’ve reached the point where you need a formal content engineering team? What does that even look like? And how do you build an organization that will ensure successful delivery of content to the customer for every project? Here are some lessons I’ve learned along the way.

Recognize Your Tipping Point

Content engineers are responsible for making content “work” in digital—and print—channels. This job is often handled informally in smaller organizations, when working with small volumes of content, or when content is only expected to perform well on a single platform. In these cases, some responsibility for content engineering is often naturally assumed by business analysts, software developers, systems architects, or content strategists. As an organization grows or its needs change, you may start to recognize you have a content engineering gap from the following signs:

• Content delivery meets editorial standards but requires frequent manual tweaking to get it to present well on your platform(s). Fixing one problem often creates another.
• There is constant friction between the content strategy team and software developers.
• Content presents well on your native platform but displays or behaves poorly on other platforms.
• The file system or content management system you’re using does not allow you to easily find, edit and version content for updating or reuse. You use file-naming conventions and folder structures to know what content was used where, when and for what purpose. It’s often difficult to determine what version of content was last published, and for which purpose.
• The content team spends more time managing their content than creating it.
• A project has failed or resulted in sub-optimal outcomes because the content delivered didn’t integrate well with the application (or, viewed the other way, the application didn’t support the content requirements).

If these symptoms are familiar to you, you might consider adding a content engineering role to your organization. Here are a few skills to look for during the hiring process.

Technical Skills are Important

Content engineering is inherently technical, so there are some technical skills that content engineers can’t live without. At minimum, content engineers typically need to have experience with relational databases, one or more query languages, Boolean logic, a thorough understanding of search and retrieval concepts, common structured data formats (XML, JSON, XHTML, etc.) and presentation markup. Depending on the organization and the roles of other project team members, they may also need to have experience with a specific programming language or query language, a background in user experience or systems analysis, or data science/artificial intelligence/machine learning. Certain types of content may require specialized skills, such as experience with file format, closed captioning and transcription standards for video content.

Technical Aptitude - Soft Skills = Ineptitude

Content engineering is all about building bridges between content strategists, product management and technology teams. Technical skills are not worth much unless they come alongside excellent communication skills, an empathetic and curious mind, and the ability to influence and lead a team with a healthy balance of confidence and humility.

Why are these soft skills so critical for a content engineer? Consider these scenarios:

• Presenting a business case to executive leadership to adopt a new CMS. The executive team is inclined to see technical complexity and expense. A skilled content engineer can tell the value story and demonstrate the connection to the bottom line.
• Facilitating discussions between content strategy teams and software engineering teams. The software team may roll their eyes at the outdated workflow the content strategy team uses to publish content, while the content strategy team pushes back on changes to their workflow. An experienced content engineer will empathize that the teams have unique needs and will work toward a solution that addresses those needs while keeping everyone focused on their common larger goal.

The User is Your North Star

A good content engineer will keep in mind what user need the business is working to support with each feature before they try to address how to accomplish it. A great content engineer will also ask why the user needs to do something.
 
Let’s say, for example, that a product manager for home furnishings e-commerce site asks for a feature to limit products by color. He points out that color is already stored about each product in the marketing CMS. He provides a wireframe showing the new limiter which will expand to show a list of colors, and that a user can select one or more colors.

The outcome and the product manager’s experience will likely be very different if he works with a team without a content engineer vs. working with an experienced content engineer.

Experience Without a Content Engineer

Product Manager: Wait, this isn’t what I wanted. The limiter includes hundreds of colors, many of which are similar, and no user is going to scroll through that many colors. It’s useless.”

Tech Lead: Well, that’s the data you told us to use.

Product Manager: I’m not going to approve the feature as-is. We need a more manageable list of colors.

Tech Lead: I guess we’ll have to refactor the feature. We could map individual colors to color families, but you’ll need to provide the mapping. It’s going to cost additional dev time and will delay the release by two weeks.

Experience With a Proficient Content Engineer

Content Engineer: The sample data the software engineering team is using in their development environment is from sample records from one product type, which includes a range of 12 colors. I’ve done some analysis on the product database, and there are well over 100 unique color descriptors across all products. Once the application is pointed to the production database, the list of color options presented in the color limiter may be overwhelming for users.

Product Manager: You’re right, that won’t work. We’re going to have to do something to roll those up.

Content Engineer: I can work with the marketing team to create a standardized vocabulary of color families and map the product colors to those families. Then we can update the database to include a color family field and add the color family to each record. I’ll notify the software team that we want them to use that field for the limiter rather than the product color field.

Product Manager: Perfect. Thanks!

Experience with a Great Content Engineer

Content Engineer: Why do the users want to limit by color?

Product Manager: They want to pick their favorite color; they want something that complements other items they have, that sort of thing.

Content Engineer: Tell me more about how a user chooses something that complements other items they have.

Product Manager: Once a user limits to products in a color family, they need to rely on photos to verify the color. Unfortunately, online photos are terribly unreliable sources because individual users’ screen quality and settings vary, so this is very unreliable.

Content Engineer: Would it help if we apply a standard color rating system, like Pantone, so that the color name means the same thing to every user?

Product Manager: Well, going back to capture that information for existing products would be prohibitively expensive. The colors of the hard goods sold on the site are inspired by our company’s paint colors, but again, our products aren’t tagged with that information.

Content Engineer: If we could find a way to map product colors to paint color family, would that be useful?

Product Manager: Sure it would--it would ensure that the items customers are selecting are color coordinated.

Content Engineer: I’ll talk with the design team to see if we can tap into their design database to develop a mapping from product ID to paint color family in the e-commerce platform. 

Product Manager: This will enhance the user experience and I’ll bet we see an increase in sales because customers will like the reassurance of shopping on a site where products are guaranteed to coordinate.

The lesson: don’t dive so quickly into implementation that you lose sight of what you’re trying to help your user achieve. Be more interested in your user than yourself, and be inquisitive enough to really understand the user’s needs.

Keep It Simple, Stupid (KISS)

When considering who you want on your team, look for people who seek the simplest way to solve a problem. This means focusing on the current problem at hand and the known variances rather than accounting for every scenario imaginable. The KISS principle is not, however, an excuse to ignore the need for extensibility. In fact, it makes extensibility more important, not less.

Imagine you’re tasked with developing an XML schema that includes support for providing image metadata (title, image size, image format, etc.), and you create the following XML structure:  Yet you can envision a day on which your organization might want to use videos.  Well, don’t spin your wheels developing a schema that handles all of the additional metadata that might be required for video (such as duration, transcript, etc.), but do consider that your schema is very clearly image-focused.  Can you make it more generic? Certainly! It’s still simple, just more extensible.

Engineer Your Team as You Would Your Content

Well-engineered content is standard enough to be used programmatically, but flexible enough to be used in multiple ways. Likewise, a high-functioning content engineering team should have a standard but flexible tool kit that can be applied to any project. A content engineer’s tool kit includes:

• Templates that inventory the envisioned content, map metadata to requirements, outline content workflows and define data models. 
• A problem-solving methodology you can apply at the project level and the individual requirement level. There are numerous problem-solving models: McKinsey, PDCA, DMAIC, 8D, etc. The important thing isn’t which model you use, but rather that your team has a standard approach to problem solving that can be applied in any context.
• Structured analysis capabilities that enable a content engineer to propose, define and explain data structure, flow and data-system interactions. In particular, content engineers will be most successful when literate in data dictionaries, schemas, entity relationship diagrams, data flow diagrams and system context.

Furthermore, the team structure itself needs to be flexible. In a small organization, a single content engineer may be responsible for the entire content engineering effort. In a large organization, a content engineer may define the “what” and “how” but rely on many others—software engineers, taxonomists, quality assurance engineers, data scientists, content architects, etc.—to do much of the implementation. 

There is no one-size-fits-all model for building a content engineering team, and furthermore, as soon as you optimize your team for your organization, you will find that technologies and business needs have changed and you’re already looking to refine your team in terms of roles and skill set. Whereas you may have relied heavily on manual tagging of content yesterday, you may find that now you’re looking to rely on machine learning to accomplish some of that work, and that requires a new skill set. 

Think about building and growing a content engineering organization as a wheel with spokes. At the center is the content engineer role. If the team is managed in a way that encourages continuous learning and an open dialog about the team’s constraints and limitations, the content engineer(s) will be the key to identifying what needs your organization has in terms of other content support: They will know if they need programmers to automate content processes, they’ll recognize when taxonomy requirements have become so complex they’re in way over their head, and they’ll identify areas where machine learning expertise will provide significant lift. In this way, content engineering principles are at the center of the organization, but the team may grow to include members from other disciplines.

A Good Sketch is Better than a Long Speech

Content engineers should be very with comfortable whiteboarding and diagramming. An effective picture can reduce a conversation from hours to minutes and can quickly create alignment across multiple functions.

For example a written out migration plan: As opposed to a visual migration plan:

Get Your Head Out of Your ASCII

Content engineers need to know how to sell the value of their work—and the way to do that is rarely by throwing around technical jargon.

For those who don’t work in content disciplines, the concept of content engineering can seem vague. Yet executive leadership is not going to approve a new position or fund a content engineering proposal if they don’t understand the value it provides. Further, other teams are not going to engage with yours if they don’t know what you bring to the table.

It is critically important that content engineering leadership and their staff always relate their work to its business value. Prefer statements like, “We’re enhancing our CMS to enable our content developers to create more relevant content faster, and drive more traffic to our site through links to related articles, with an anticipated result of a 15% increase in qualified leads,” over statements such as, “We are enhancing our CMS so that it can handle more scientific character entities and assigning metadata to our articles based on a new topic taxonomy.” (Unless you’re asked how you’re doing the former, of course!) They may both be true and accurate, but the first statement is not only readily understandable by a wider audience, but it demonstrates why the effort is important to the business.

Putting It All Together

A content engineering organization can be a powerful asset to any organization when it reaches a tipping point in the complexity of its content-system interactions. As it may be a new concept to your organization, it is important to socialize the intent of the team, get buy-in from other teams content engineering would interact with, and base the team’s practices on solid engineering principles with an underpinning of strong technical and soft skills. Most importantly, never lose sight of your north star: the user.