The Content Management Team

From inception through launch and ongoing usage, a content management project might impact many people throughout your organization, all with different roles and responsibilities.

While a comprehensive look at web operations and governance is beyond the scope of this book , it will be helpful to discuss these roles before digging into CMS features so we can have some clarity about exactly which people a particular aspect of the CMS might affect.

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

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:

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:

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:

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:

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:

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:

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:

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.

Footnote #1

For more on this subject, I recommend the aptly titled Managing Chaos: Digital Governance by Design by Lisa Welchman (Rosenfeld Media).

Footnote #2

XML Localisation Interchange File Format, a language standard for automated import/export for content translation. XLIFF is discussed further in @linkother-features.

Footnote #3

Drupal is famous for this. You can implement a significant amount of functionality in that CMS without ever writing a line of code. Thus, some Drupal sites can be delivered without needing a backend developer at all – though, as we discussed earlier, this can lead to other complications.

This is item #6 in a sequence of 18 items.

You can use your left/right arrow keys to navigate