Category: Technology

Every big content team eventually faces the same problem with scaling. The rate (and quality) of content production is no longer proportional to the size of the team. In early days teams can simply add staff to solve production bottlenecks. If they need to do more, they grow the team. However, as they and the systems and processes around them mature, the positive correlation between headcount and content dramatically fades.

In these cases, business managers face a choice. Keep hiring, hoping they stumble on some magical combination of people and roles, or look to the machine underneath the team and find ways to free the team from time/attention/energy-sapping tasks that distract them from what they were really hired to do.

In this article, we’re going to look at the impact a slow-moving content machine has on productivity (and ultimately profit), and then go over 3 examples of ways big teams are unblocking their content creators and freeing them to focus on content creation.

Imagine needing a car mechanic’s help every time you wanted to change gears.

“Hey Bob, could you just drop to second as I approach this intersection. Thanks.”

Unsurprisingly this isn’t reality. We have gearboxes. They take the repeatable and technically complex task of gear-changing and make it accessible to the driver.

Increasing efficiency in big teams, or implementing workflow gearboxes, is perhaps the biggest problem category we work on with our clients. They find that in their day-to-day operations they have these repeatable and technically complex tasks being handled by their development team. For example:

• Build a new page layout > Get a developer
• Update the style > Submit a ticket
• Move a banner ad > Add it to the backlog

The business impact of these bottlenecks is three-fold:

1. Content production is dependant, or blocked, by the developments team’s capacity to respond to the task
2. To move a task forward, content producers are required to understand and interact with the development workflow
3. The development team spends their time on operational tasks rather than focusing on maintaining and enhancing the platform

Removing these kinds of bottlenecks results in massive time and resource savings.

Now remember, in a car a gearbox doesn’t do everything. It has a clearly defined range of influence. It doesn’t let the driver change the oil, swap out a fan belt, or replace a tyre. It lets them change gears. Defining what tasks should be handed over to a site manager, and how, or left in the hands of developers is just as important as the actual implementation. There is a process for identifying what should be gearboxed and what should remain in the purview of the development team, but for now, let’s explore some specific and current examples of how big teams are reducing day-to-day reliance on developers and unblocking their content creators.

Example 1 – Layout & Site Customization

Layout customization in the form of drag-and-drop page builders is something most site managers are at least familiar with. The WordPress eco-system itself has seen a boom in this quadrant with many businesses developing tools that deliver page-building powers to site owners. However, the translation of this kind of mass-market solution to big teams isn’t as simple as could be expected. There are a few factors that need to be considered. These can include:

• Restriction – What should, and should not, be customizable by the team (gearboxing)
• Sitewide Previewing – Understanding the impact of how a customization impacts the entire site
• Reviews & Approvals – Like general content, layout and site customizations should go through a review workflow
• Scheduling – When customizations should go live (more on this in example 2)

The good news is that even though the implementation can be unique to every team, the underlying methods and technology are becoming more standardised. For example, recent and arriving (changesets) updates to WordPress Core lay a very strong foundation for the kind of complex implementation big teams need for layout and site customization.

Example 2 – Complex Scheduling

Let’s use an example to illustrate the opportunity here. Imagine coordinating a 12 days of Christmas campaign that delivers unique content on a rolling 24-hour cycle for the 12 days leading up to the 25th. The number and variety of changes impact things like:

• Headlines and other copy
• Banner ads
• Imagery
• Page layouts
• Styling

These changes include more than what is typically “scheduled” by site owners. Scheduling content (e.g. articles) is a familiar CMS feature, but big teams need to consider much more. Normally scheduling these kind of changes would involve working with a developer team to stage the changes on a separate instance of the site and scheduling a code-merge. For our above Christmas campaign, this would mean coordinating numerous code-bases and deploying, possibly manually, on a very strict timetable.

Recent updates in WordPress actually now allow the changes to be both made and scheduled within the WordPress user interface. The direct reliance on staging environments and developer teams can be removed through this.

The positive impact on efficiency is obvious when complex changes like these can be systemised (gearboxed) and taken away from developers and given to the content team.

Example 3 – A/B Testing

Frequent, small, defined and measurable changes to a site will over time produce a far greater ROI than big redesigns. Unsurprisingly, the discipline of A/B testing is widely used and something we see a lot of our clients doing. Simply put, the process looks like:

1. Select the metric to be improved (E.g. time on page)
2. Define a hypothesis (E.g. if we increase the body text font-size from 14px to 16px we will see an increase in time on page)
3. Create the assets required to deliver the alternate state (E.g. font styling)
4. Set up an A/B experiment to deliver both the current and new state
5. Measure impact on selected metric
6. Implement the winner

Throughout this process there are potentially multiple developer touchpoints. I.e.:

• Develop experiment assets
• Set up mechanism for delivering the experiment
• Collect data
• Implement experiment winner

For the full value of A/B testing to be realised, experiments need to be run frequently. If developers were required to manage the above 4 points, the bottleneck would prove fatal to the entire process.

Big teams, especially those that are producing and managing high-traffic sites, are systemising this process as much as possible. Even the mechanisms for determining “the winner” of an experiment are being automated. Developers are freed from having to manage and implement and site managers can accelerate the A/B process significantly, properly realizing the ROI of a compounding A/B testing strategy.

These three are only a few of the ways we are seeing big teams remove their dependency on developers and unblock content creators. The industry and technology under it move at an incredible pace and we are constantly seeing innovative solutions enter the market.

How does your team handle these kind of repeatable and technically complex tasks? To what degree do you think your team is burdened by tasks that distract them from focusing on the work they were hired to do?

Want to reduce these kinds of bottlenecks? Contact us for a consultation.