The Content Management Team

Primarily, members of the content management team can be divided into:

• Editors
• Site planners
• Developers
• Administrators
• Stakeholders

Note that these labels are roles, not people. It might be discouraging to look at this list – you may think that your project is somehow deficient because you don’t have all these people milling about. However, understand that the lines between the roles are not absolute, and it would be rare to see a project where every single role described here was staffed by a separate person.

Members of the team usually fill multiple roles, and commonly overlapping roles will be noted in each section. In the meantime, just know that for a very small project, the entire team might consist of a single developer and a single editor (and a developer hobby project might be an entirely one-person show).

That said, the content management team is usually comprised of some combination of the following.

Editors

Editors are responsible for creating, editing, and managing the content inside the CMS. We’ll talk about editors a lot throughout this book, as this is the role that will interact with the CMS most intimately after launch.

Editors tend to get lumped into a single group, but the “editor” role is a crude generalization: all editors are not created equal, and they might have a wide variety of capabilities.

What characterizes a “normal” or “mainstream” editor is project-specific. Therefore, it might be helpful to discuss how editors can be limited in their capabilities to refine their subroles:

• By section/branch/location: Editors might be able to edit only a specific subset of content on the website, whether that be a section, a branch on the content tree (we’ll talk about trees in Content Aggregation), or some other method of localization. They might have full control over content in that area (the press section, or the English department, for example), but no control over content in other areas.

• By content type: Editors might be able to edit only specific types of content (we’ll talk much more about content types in Content Modeling). They might manage the employee profiles, which appear in multiple department sites, or manage company news articles, regardless of location. In fact, some editors might be better defined by what content types they are not allowed to create – some editors, for instance, might not be allowed to create advanced content like aggregations or image carousels.

• By editing interface: Editors might be limited by the interface they’re allowed to use. In larger installations, it’s not uncommon to channel certain editors through specialized, custom-built interfaces designed to allow them to manage only the content under their control. For instance, if the receptionist at your company is responsible for updating the lunch menu on the intranet and nothing else, then he doesn’t need an understanding of the larger CMS interface and all the intricacies that go with it. Instead, it might be appropriate to build that person a special editing interface to manage the lunch menu and nothing else.

In contrast to these limitations is the so-called “power editor,” who can perform all content operations across the website. This person sometimes performs multiple duties as a site administrator, trainer, subject matter expect, and all-around CMS champion inside the organization.

Several other specific editorial roles are common:

• Approvers: This role is responsible for reviewing submitted content, ensuring it’s valid, accurate, and of acceptable quality, and then publishing that content. That is, approvers perform steps in one or more workflows. Many editors are also approvers, responsible for vetting content submitted by more junior editors. These editors may also have the right to approve their own content. Some approvers might have the ability to edit submitted content prior to publication (an editor-in-chief, for example), while other approvers might only have the ability to approve or reject (those in the legal or compliance department, for example). This role might only need to understand the content approval features of the CMS.

• Marketers: This role is responsible for reviewing content for marketing impact, and managing the marketing value of the entire website. It requires an understanding of the marketing and analytics features of the CMS. For some sites, this is the dominant role because new content isn’t created nearly as often as existing content needs to be optimized, promoted, and analyzed.

• UGC/community managers: This role is responsible for verifying the appropriateness of content submitted by users (user generated content, or UGC), such as user profile information and blog comments. These managers are similar to approvers, but they only have control over UGC, rather than core editorial content (in some cases, this might be the majority of the content on the site). Additionally, given that the submission volume of UGC is often high, it’s commonly managed post-publication – inappropriate content is reviewed and removed after publication (or after a complaint is received), rather than holding it from publication until review. This role will only need to understand the CMS to the extent that allows them to moderate UGC. In some cases, the CMS provides separate tools for this, while in others this is handled as normal content.

• Translators: This role is responsible for the translation of content from one language to another. Translators only need to understand the editorial functionality of the CMS to the extent required to add translations of specific content objects (perhaps even of only specific content attributes, in the event that content objects are only partially translated). We will talk about localization issues much more in Other Features.

Not all roles in this list will be filled. Sites without UGC will not require a role to manage it. Organizations managing product documentation or library content might not have a marketing/optimization role. An editorial team of one has no need for approvers. Content presented in a single language will not need translators.

Some roles might also be filled externally. UGC/community managers might not be employed by the organization. In community sites, it’s common to depend on the community itself to self-monitor, empowering specific members to moderate content. In these situations, site users will hold a quasi-editorial role, usually enforced with permissions or perhaps a completely separate user and management system.

Content translation is often handled by third-party organizations. In these cases, the translator will be remote and might not work with the CMS at all, instead moving content in and out via a translation-specific workflow and exchange format, such as XLIFF .

Site Planners

Site planners are responsible for designing the website the CMS will manage. Most of their involvement will be prior to launch, with sporadic further involvement as the site develops and changes over time.

Several subroles exist:

• Content strategists: This role is responsible for designing content, both holistically and tactically. As a byproduct of the content planning process, content strategists define the content types and interactions the website must support. This role will require knowledge of how the CMS models and aggregates content in order to understand any limitations on the design. Additional knowledge of the marketing features will be necessary if the content strategist is responsible for optimizing the marketing value of the site prior to launch.

• User experience (UX) designers and information architects: These roles are responsible for organizing content and designing the users’ interaction with the website. They will need to understand how the CMS organizes content, and what facilities are available to aggregate and present content to end users.

• Visual designers: This role is responsible for the final, high-fidelity design of the website (as opposed to lower-fidelity prototypes and user flows provided by previous roles). Visual designers don’t need intimate knowledge of the CMS, as CMS-related limitations will have guided the process up to their involvement. (In some cases, this role overlaps with template development, which we’ll discuss in the next section.)

Developers

Developers are responsible for installing, configuring, integrating, and templating the CMS to match the requirements of the project.

How much development effort this takes is specific to the complexity of the requirements and how well matched the CMS is to those requirements out of the box. Deploying a simple blog powered by WordPress will take very little development (perhaps none at all), while an enterprise intranet built from scratch is a huge undertaking.

Like editors, not all developers are created equal. Under the umbrella of development, there are multiple categories of tasks that define different roles:

• CMS configuration: This role is responsible for the installation and configuration of the CMS itself, including the establishment of the content model, creation of workflows and other editorial tools, creation of user groups, roles, and permissions, etc. This work is done at a fairly high level, through facilities and interfaces provided by the CMS.

• Back end (server) development: This role is responsible for more low-level development performed in a traditional programming language (PHP, C#, Java, etc.) to accomplish more complex content management tasks, or to integrate the CMS with other systems. This developer should have experience in (1) the required programming language and (2) the API of the CMS.

• Front end (client) development or templating: This role is responsible for the creation of HTML, CSS, JavaScript, template logic, and other code required to present managed content in a browser. This developer needs only to know the templating language and architecture provided by the CMS, and how it integrates with HTML, CSS, and JavaScript. (Different template architectures and paradigms can vastly change the responsibilities of this role, as we’ll see in Output and Publication Management.)

In many cases, all three of these development roles are performed by the same person. Alternately, a very common split is to have the frontend development performed by one developer, and the CMS and backend development performed by another developer. In these cases, the frontend developer is responsible for templating content that the backend developer has configured the CMS to manage and provide.

It’s becoming increasingly common for visual designers to code their own frontend implementations. Thus, the same person might design a complete interface from a wireframe, then ultimately template the CMS to reflect that design.

The split between CMS and backend development depends on the CMS. Some systems allow an enormous amount of development to be performed from the interface, and writing programming code is considered the exception, rather than the rule (and remember that in multitenant SaaS environments, the option to write programming code might not be available).

Other systems are designed primarily as programming platforms, which means that most of the configuration consists mainly of writing, compiling, and deploying programming code. In these cases, CMS configuration and backend development are largely the same thing.

Administrators

Administrators are responsible for the continued operation of the CMS and the associated infrastructure. Within this group are several subroles:

• CMS administrator: This role is responsible for managing the CMS itself, which includes user and permission management, workflow creation and management, licensing management, and all other tasks not related to content creation.

• Server administrator: This role is responsible for the maintenance and support of the server(s) on which the CMS runs and/or deploys content. This is a traditional IT role, and the server administrator often has no understanding of the CMS itself other than the basic architecture required for it to run without error (operating system, runtime framework, web server, etc.). This role provides support when there’s an underlying server issue that prevents the CMS from functioning correctly.

• Database/storage administrator: This role is responsible for managing the database server and storage networks that hold the CMS content. This administrator needs very little understanding of the CMS, other than the file types, sizes, and aggregate volumes that will need to be stored and backed up.

The CMS administrator role is often staffed by a power editor.

It’s very common to see the server administrator and database/storage administrator roles combined in the same person (sometimes a developer even stands in for both of these roles). However, many larger organizations have separate groups of data administrators responsible for managing storage and nothing else.

Stakeholders

The stakeholders of a CMS project are an amorphous group representing the people responsible for the results that the CMS is intended to bring about. Stakeholders are normally business or marketing staff (as opposed to editorial or IT staff) who look at the CMS simply as a means to an end.

In general, stakeholders are looking to a CMS to do one of two things:

• Increase revenue.
• Reduce costs and/or risk.

These goals can be achieved in a number of different ways, a CMS simply being one of them. Stakeholders often have no direct contact with the CMS, and they might not care about the specific features the CMS enables – their only goal is the result the CMS can manifest.

For example:

• The chief marketing officer is dissatisfied with the percentage of visitors who complete the “Get a Quote” form after browsing the website. She is convinced that a personalization strategy – varying site content to target each visitor specifically – will increase this conversion rate and therefore increase revenue.

• The manager of the support department feels that the company is taking too many support calls because of the sorry state of the online product documentation. Attempts to improve the documentation have been thwarted by technical limitations, which a new CMS might solve, hopefully resulting in a lower volume of incoming support calls and therefore reducing costs.

• The editor-in-chief is trying to increase article volume, but the current CMS forces hours of editorial overhead and rework to get an article published. The editor is hoping to increase content throughput with a CMS that has a streamlined editorial workflow. The goal here is to push more content, which increases revenues, and do it more efficiently with less editorial labor, which reduces costs.

Note that, in each case, the end goal was not to install a new CMS. The CMS is simply the means to achieving a larger stated business goal.

In each of these three examples we have someone who (1) is not directly going to use the CMS, and (2) is not going to develop or integrate the CMS. So, why are the stakeholders important? Because they are usually the decision makers on a CMS purchase who control the budget from which the project will be funded.

They are included in this discussion of the CMS team because sometimes it’s easy to lose sight of the forest for the trees. The closer you get to a CMS project – as an editor, administrator, site planner, or developer – the easier it is to obsess over small details.

Never lose sight of the fact that stakeholders have little regard for anything beyond the critical question: will this expense bring about the business goal we are seeking? The specifics of exactly how the CMS does this are simply details.