Case study: Establishing a content platform
After a successful content management tooling project, my team pivoted from a project team to a platform team to build out enterprise-wide content capabilities.
What was the problem?
Even with a new content management system (CMS) in use by numerous teams, that usage happened organically and content is still siloed within the CMS with each team building out their own set of capabilities for publishing websites, managing localization, and so on.
Who was involved?
LEADERSHIP TEAM
Our core group operated under the “triad model” in which three different roles formed a leadership team.
Product manager
John Collins (content architect)
Engineering manager
PLATFORM TEAM
6-9 full-stack developers
SPONSOR
IT manager
How was the problem solved?
The members of the leadership triad collaborated to convince executives of the need and tell the story of how a content platform could drive savings and innovation.
We developed a variety of diagrams and slide presentations that we could use to show the problems of the existing piece-meal approach to content and how a centralized content platform would be more efficient. I created most of the diagrams and slides.
We secured an executive sponsor and funding from that sponsor (as well as some stakeholder teams, I believe).
I combined my knowledge of the company with insights from software architects, marketing leaders, content designers, product managers, support agents, and people around the company to create a domain model.
What was the outcome of this project?
We managed to get funded as a platform team and spin our original project-specific work into a new team.
We created our first “content primitive” content type and it’s being consumed by three user experiences.
The team developed the idea of “content primitives” to be core content types that are agnostic to how they are consumed, thus able to be consumed in a variety of experiences. This is based on thought leadership I provided.
Our belief in structured content spread throughout various stakeholder teams and more and more of the company is moving toward structured content.
At the same time, we knew that a lot of enterprise content isn’t as highly structured as these content primitives, so I did foundational work to create taxonomies and metadata that can be attached to unstructured content so that we can connect content across the enterprise.
My advocacy for taxonomy led to an informal taxonomy group and an investigation into taxonomy software vendors.
I identified the need for an “orchestration layer” to help build user-visible experiences from structured content, and presented several vendors that might address that need. Three years later, Atlassian signed a contract with the leading vendor I had identified.
I’ve created a domain model that could guide future content models in the company.
Competencies demonstrated
Strategic planning
In reality, this idea of an enterprise-wide content platform was our goal since we first looked at CMS providers. In a sense, this is the realization of years worth of preparation (with years worth of buildout to come).
We drove toward strategic decisions that could impact the entire business and turn a cost center into an asset.
I drove much of the vision for this team.
High-impact communication
I’ve advocated for content as a strategic asset for years. Many of the messages I shared with my triad formed the nucleus of the business case we made and how the team positioned itself.
We communicated up to executives and sponsors and across to stakeholders across all parts of the business. This required tailored communications for those audiences.
The team used diagrams, videos, and text for much of this communication.
Continuous improvement
A lot of our team’s work was very theoretical, and we repeatedly changed our “elevator pitch” and related comms to find examples, metaphors, and so on that connected with executives and stakeholders.
We viewed our work as iterative, so we tried to make decisions that kept us moving with a path to refining as we go.
We made mistakes along the way and learned from them.
Applied reasoning
There’s an inherent tension in the triad model, and that’s by design. There were times when we had to have hard discussions about tradeoffs between design, engineering, and the business. These discussions required applied reasoning.
Many of our stakeholders were happy with the status quo. We had to help them understand that the status quo won’t enable the future that they need to deliver, and that our platform would.
Guiding team success
In many ways, I drove the team’s vision.
While the team had some turnover in the years, I was with the team all but a few months of its existence.
When needed, I was very involved tactically to help drive the team to deliver value and reach milestones.