A short history of CMS and digital teams
Web Content Management and digital teams have undergone a number of massive shifts in a short period of time. I started my career at a time when “webmaster” was a term used unironically, and this task was an extremely IT-focused endeavour. Infrastructure was hard and content started as an afterthought. Things that we take for granted today — basic internet access and the creation and distribution of content — required powerful but difficult to use tools and frameworks. As a result, they catered to IT and developers.
As databases and services increased in power, marketing self-service became the expectation. Initially it started as a “shadow IT” movement. Then marketing teams started gaining IT capabilities of their own. They took control of content and now-expanded customer-experience objectives from the IT teams. The core challenge of capturing and moving content between servers and social networks became easier, and the demands on organizations to provide visually compelling and interactive experiences became greater. As a result, the center of gravity shifted towards marketing teams.
Customer experience is everyone’s responsibility
Customer experience is now a major differentiator for enterprises, which requires a significant change in how teams work. Many companies have split the customer experience (CX) function out of marketing, or even eliminated the CMO role entirely — including several top global brands like McDonalds, Lyft and Johnson & Johnson. This split is due to a number of factors, but the cross-functional nature of customer experience is at the top. As companies work to differentiate themselves based on this new paradigm, they are building software to accelerate customer experience efforts. As one automotive executive stated to McKinsey, quoted in an article about applying these platform principles across the enterprise “The question is not how fast tech companies will become car companies, but how fast we will become a tech company.” Or, put bluntly by Marc Andreessen, "Software is eating the world."
Two shifts further enable this shift. First, technology has become far cheaper to scale up and maintain. This includes cloud platforms, open-source frameworks and tooling. The second major innovation is the construct of the product team, as it applies to customer experience. In the past, websites were often run as “projects,” often with a big-bang approach to redoing everything: branding, CMS system, content, etc. This would often lead to failed projects. The team was generally temporary, which created a gap of expectations between the old and new system on day one. Allocation of resources to maintain the system were often cut short (sometimes, ironically, to fund that initial large project effort), which intensified the problems.
Agile methodology has led to agile architectures
An evolution in team organization grew in parallel with the evolution of tools. Agile concepts started to gain traction for teams working on delivering products, and marketers realized that the same concepts could be applied to developing customer experience. This included the “product team” elements, such as listening to customer needs, delivering on a regular cadence and having business and technical teams working hand-and-hand in self-organizing teams.
Many organizations, such as Telus Digital, started small with a model to field test these ideas. They approached customer experience projects with principles for software development. They were called something like the “digital lab” or “innovation factory.” With the success of these organizational experiments, their approach has expanded to the organizational level. This has proved more difficult due to paradoxes of scale, in both technology and agile teams. Thankfully, organizational capability and Contentful have grown to match.
Previously, when marketing led CX efforts, integrated suites enjoyed popularity. Teams were small and responsible for more tasks (and doing “copy/paste” work to enter content on behalf of other teams). However, scaling across regions and teams introduced challenges of communication and coordination. Everyone worked in a single system, and stepped on each other’s toes in the same code base, content model and scheduled release cycle.
Contentful is designed with agile goals and scalability challenges in mind. Rather than a monolithic repository and website code base, it is possible to use spaces and environments to separate teams and projects within teams. In other words, you can share tools and spaces when it makes sense to share content and split them apart when it doesn’t (while still using tools such as the migration SDK using the content management APIs and webhooks (to trigger and move content as required).
Platform and people need to work together to scale
Concerns about cost and talent shortage are persistent issues that keep customer experience transformation from becoming more widespread than it is currently. I found an example from an implementation partner that references the platform and skillset complexity of a legacy competitor (seven different technical role types, ever-changing technology and multiple specific proprietary layer elements). The partner outlines what the program requires to run a team and notes that it “will not take more than two to three weeks to learn and start developing.” In contrast, achieving proficiency in Contentful takes a minimal amount of time.
You can build on the platform and manage infrastructure in minutes.
The problem is ever-present. The demand for skilled developers remains high, particularly for proprietary systems. Instead of committing to a particular skill set, you can incorporate a platform like Contentful into existing development practices. The API-first approach scales to enabling internal teams and partners to build repeatable, scripted stacks with integrations via the App Framework. These can be deployed quickly as you build your team or agencies build specific solutions for verticals.
Managing change means building on a flexible foundation
The release of the App Framework exemplifies how we scale Contentful to meet the needs of large platforms. When you install an app, it’s available to the entire organization. You can then provision it to an individual environment for testing purposes or across a space so that each business unit only sees the integrations relevant to them. The code for common use cases, such Digital Asset Management and ecommerce integrations, is open-sourced. You can also easily work with private and public apps.
The combination of these scalability and governance features — the ability to work with various technologies and the ease of “one-click” or scriptable API installations — means that Contentful uniquely provides agility and enterprise compliance with how software is rolled out and deployed across an organization.
There’s much to consider when you’re investing in key systems and platforms. They should grow with you, not block progress. Download our white paper on the seven dimensions of scale to learn about the factors that contribute to scaling success in enterprise systems.
