A headless CMS can break down organizational silos by unifying content that had been managed by separate web CMSs. Enterprises can share content across different divisions and follow common procedures and processes. 

To achieve these benefits, various contributors must navigate the many work practices that happen outside of the CMS, especially during the design phase. When these practices diverge and aren’t understood by everyone, they can interfere with cross-organizational collaboration. 

Content experts need to work across organizational boundaries. They may be involved with projects that are marketing-driven, IT-driven, or UX-driven, each of which can follow distinct work practices. Everyone involved with these projects should be aware of the assumptions they bring to how work should be performed. 

Understanding different roles and perspectives

Consider a simple issue: How important is fixing a punctuation error? Depending on your role, the issue may seem either trivial or highly consequential. And depending on your work practices, the issue will be either easy or annoying to fix.

When content and UX people need to work together, they may discover they have slightly different priorities. On occasion, they might disagree about a decision. In some cases, their differences could be broader than a single decision. 

Content experts will also be working with other stakeholders such as product managers, IT leads, and marketing managers, all of whom have their own preferences for how to do things. The more content teams work across the organization, the greater the diversity of work practices they will encounter. 

Work practices influence numerous decisions that affect what gets done. They include a range of decisions outside of formalized processes or standardized procedures.

People in different job roles have different:

• Habits influencing how they perform their work
• Orientations shaping how they evaluate tasks
• Goals guiding what they want to achieve

These factors shape the work practices that individuals prefer to use.

At the enterprise level, four people and process issues influence cross-organizational content collaboration:

1. How people are organized
2. How work is prioritized
3. How work is divvied up
4. How work is carried out

Prevailing practices can differ in each of these areas. To maximize collaboration, stakeholders need to synchronize diverging approaches to delivering initiatives. 

How people are organized—team structure

Employees juggle several identities. They can belong to teams or squads, working groups, business units, and practices.

Many organizations have a matrix structure. They are organized around business functions such as product, engineering, e-commerce, business operations, marketing, sales, and so on. And they have job roles that overlay with these business functions. Sometimes people’s job roles are the same as the business function, and sometimes they aren’t. Not everyone who works in the e-commerce department will necessarily be an e-commerce specialist or manager, for example. Some could be writers or designers.

People working as part of a specialist role such as content are sometimes considered a central resource for the entire organization. Others in such roles are dedicated to a specific unit of the organization. 

Since content and UX work are rarely dedicated business functions, these roles are often disbursed across various business functions. They often find themselves embedded within a group where most people have a very different job role than they do. 

Regardless of where they are based in their organization, content people will need to collaborate with colleagues who:

• Have different roles and accountabilities
• Have different bosses
• Belong to different parts of the organization

They may join a project team where contributors belong to different “home” divisions based on their job role or funding source. They could be assigned to a single project or a number of them. Even when colleagues work on the same project, they may have responsibilities that are unrelated to it.

When working in a matrix organization, content people may find separate parts of the organization are responsible for their training and development, career path, work assignments, and evaluation. Content specialists who have multiple affiliations may find themselves trying to balance conflicting short-term and long-term priorities in their work. When individuals must support many stakeholders, that situation can limit their current and future availability. They may need to decline a reasonable request because of other commitments. 

Content people commonly need to adapt their preferred ways of working to prevailing practices. For example, a writer from the marketing department might not work frequently with UX designers but now needs to. A content manager who works within the web team under IT might be familiar with how developers plan projects but doesn’t normally work with product managers.

How work is prioritized

What’s urgent, and what gets pushed into the backlog? 

Stakeholders in content initiatives favor certain kinds of criteria when planning tasks and setting priorities.

Initiatives may follow differing approaches to prioritization, depending on whether the jobs to be done are evaluated through a product, program, or project prism. For example:

• A product focus may prioritize work according to feature availability. 
• A program focus may evaluate tasks according to their impact on improving performance metrics. 
• A project focus may rank jobs to do according to their cost and scheduling.

Content and UX experts enjoy discovery-driven projects that offer wide latitude to decide what to create. When they have that discretion, they may favor an approach such as collaborative dot voting to prioritize ideas. But frequently, they will need to follow the priorities set by other stakeholders in their organization. 

Products tend to prioritize releases in terms of launch tiers. New functionality can be categorized from Tier 1 (strategic) to Tier 3 (incremental). Some product ideas are provisional and involve deciding what to ship. Such products seek to validate their “MVP” (minimum viable product). Generally, product owners will decide what functionality is critical. The associated work done by content and UX teams will be prioritized accordingly. Yet the other roles may have alternative perspectives on what’s viable or important for customers.

Business stakeholders define and prioritize ongoing initiatives using KPIs or OKRs. To improve performance, initiatives will conduct experiments such as A/B testing, which will be ranked according to their expected effort and impact. Content and UX specialists will have many ideas to suggest on how to improve the outcome of an experiment, but they may not choose which experiments to conduct.

Projects that focus on enhancing existing products and services will classify tasks according to P-levels. Each enhancement or problem-to-fix gets categorized by P-level: from P0 (essential) to P3 (nice-to-have). People in different job roles could prioritize issues in divergent ways. Cost and urgency can be decisive criteria. Content contributors are sometimes disappointed that content problems are not prioritized as urgent.

How work is divvied up

After determining how to prioritize tasks, various roles need to decide how to coordinate the work that needs to be done. 

How are tasks divvied up? This question gets into specifics about how to chunk the work and how much time to devote to each chunk. Teams may follow various project delivery methods. People joining a new team may not be familiar with the planning process being used. 

Many tasks done by different parties (content, design, and code development) will be complementary: they address different aspects of a common output. The timing of these tasks needs to match up.

For example, one role could have a long task to do while the other role has a few short ones. Is the effort level balanced? Do resources need reallocating? Can the person who’s waiting do other things? Does the person with too much to do need backup?

A critical aspect of planning tasks is estimating the effort involved by breaking down larger tasks into smaller ones and planning how much time to allocate to each.

Estimation is difficult, especially for unfamiliar tasks. If the time required is underestimated, it can result in poor quality, delays, or cost overruns. For example, if the effort for UX design is underestimated, expensive developers could be waiting to code. Different roles need to compare how long each expects their tasks will take.

Product managers and agile leads often use story points to estimate effort. UX design who work with them may follow this practice as well, though the practice is not common among content specialists. The number of points represents the anticipated difficulty of a task. The numbers run in a series (1,2,3,5,8…) where each number represents a magnitude equal to the prior two numbers combined. Points reflect the complexity, risk, and repetition associated with tasks. The points don’t directly translate into hours of effort, as people with distinct responsibilities can have individual ideas about how many hours a story point requires. Story points reflect relative effort for the tasks within a role, but they don’t necessarily allow different roles to compare how much work they have ahead of them.

Some content teams have adopted the “T-shirt sizing” approach, which is similar in intent to story points. The tasks are divided into sizes: XS, S, M, L, XL. Although more intuitive to understand, T-shirt sizes are subjective. They help teams when everyone has a common understanding of what the sizes represent, but they won’t be precise for those without that shared knowledge.

How work is carried out

Who decides how tasks involving different functional roles get done?

Content and UX people may follow different methods when approaching tasks, especially if they haven’t worked much together previously. They might be accustomed to doing their work and passing it over to their counterparts with instructions on what should be done next. The “toss-it-over-the-fence” approach can occur when one role is brought into a project at a late stage—which often happens with content work. It can also be a legacy of having the input of one role previously outsourced.

A range of issues influence how work gets done:

• Do various roles have previous experience working together on the same activity at the same time? 
• Does a given role prefer to work individually or jointly?
• In what format are project assets: spreadsheets, word processing docs, diagrams, Photoshop files, or HTML?
• Do some roles depend on other roles to do basic but essential tasks?

The tools and formats used for design work can be a source of friction. These choices can reflect differences in which details are deemed important. Some options demand technical skills that some team members may not have. For example:

• Can everyone edit the same files, or are there barriers where only some can access the files? 
• Does everyone need to commit their work to a version control system such as GitHub? 

While some projects mandate that everyone uses the same tools, that approach is not always necessary. Different roles can use their preferred tools, provided these tools can update a common repository storing project assets. For example, webhooks (popularized by Zapier—“Zaps”) can allow different tools to retrieve or update a common file. The connectivity of headless CMSs allows the exchange of content with almost any tool that provides an API.

Improving cross-organizational collaboration

As content management gets de-siloed, more parts of the organization will experience firsthand how colleagues elsewhere make decisions affecting content. Differences in work practices can inhibit collaboration around content but don’t have to. 

Because large enterprises pursue a wide range of undertakings, it’s no surprise that work practices are diverse as well. No single action will eliminate all these differences. Rather, the most pragmatic approach is to harmonize and adapt.

In some cases, adopting one standard practice for everyone in the enterprise to follow is the most effective way to improve coordination and collaboration. It works well when everyone feels comfortable using one approach. In other cases, adopting a uniform practice that everyone must follow can reduce collaboration if it imposes limitations on certain contributors.

Avoid mandates without understanding the specific requirements of different roles. Different perspectives can improve the quality of decisions.

Standardize a practice only when it delivers efficiency to all. A single standard practice may not be realistic for the entire enterprise, given the diversity of roles and priorities. Employees belong to distinct parts of the organization and move between diverse projects. Don’t assume that all initiatives can adopt the same practices. 

Instead of expecting one prevailing practice, content contributors should become comfortable working with different practices that operate across the enterprise. They may need to be able to switch between projects that are marketing-driven, IT-driven, and UX-driven.

Diversity in practices poses a risk to collaboration when they are ignored. Contributors should understand the practices they are expected to follow and be allowed to explain their priorities when prevailing practices inhibit what they seek to accomplish.

Multiple levels of the organization have a responsibility to facilitate cross-functional understanding of practices and perspectives. This can be done through project onboarding, training, documentation of practices, and feedback. 

Alignment depends on dialog: being familiar with other perspectives and able to translate your way of thinking into the language and milestones that others use.