Model Thinking is for people who work where content, systems, and design meet.Each issue connects ideas across content strategy, content modeling, and content management system design with a focus on what actually works in practice.
Not every team should manage a content model the same way
Published about 6 hours ago • 5 min read
Issue 40
Managing your content model over time, part 4
In early 2023, after Elon Musk acquired Twitter, the platform removed free access to its API. (API’s are traditionally how one piece of software is connected to another.)
Immediately a whole ecosystem died. I remember so many cool bots and valuable automated posting accounts that just went away. There were research tools, monitoring tools, and academic projects that had to shut down.
What does this have to do with content?
Because content usually comes out of a content management system (CMS) via APIs—just like Twitter content came from APIs—and you may not always know the impact that a change to your content model will have.
We talked in Part 3 about the risk of content model changes. Today, I want to talk about why understanding the type of team you’re on matters.
If you need a refresher, here’s the entire series so far about managing your content model over time:
Matthew Skelton and Manuel Pais wrote a book called Team Topologies to help design multi-team organizations that provide value quickly. Their framework talks about four main types of team topologies. Here’s the four topologies and my explanation of what they are:
Stream-aligned team: Owns an entire end-to-end piece of work.
Platform team: Provides an internal product to accelerate delivery by other teams.
Enabling team: Fills in the gaps and helps stream-aligned teams solve challenges.
The team topologies framework says that teams only interact in three ways:
Collaboration
X-as-a-Service
Facilitation
Team topologies for CMS work
Let’s borrow from this team topologies framework for our content management work. To my mind, most CMS work fits in three of the four topologies very easily:
Stream-aligned teams: A single cross-functional team handles the content strategy, content architecture, user experience, back-end development, front-end experience development, and so on.
Platform team: One team is doing the back-end development, building the primary content platform and its content architecture and its APIs. Then other teams may put the content into the platform, while others consume that content via the platform APIs to build front-end experiences. (I’m using “content platform” here to refer to the headless/API layer and not a monolithic CMS.)
Complicated subsystem team: Highly-specialized content architects, taxonomists, ontologists, writers, and others provide expertise to the platform team.
While it’s good to know that complicated subsystem teams might be a pertinent topology, I mostly think of the first two topologies. I’ll keep coming back to them.
Let’s get real
As with many things, I see the topologies as a helpful framing to reference, but in reality, CMS work is probably better understood as being on a continuum of these typologies. At the least, we should expect that CMS work may shift from one topology to another over time.
Why knowing your team typology matters
If you’re managing a content model over time, the difference between being on a stream-aligned team and a platform team has huge implications for governance and documentation. (Sneak peek: an upcoming issue will focus on what to document.)
Since a stream-aligned team owns the end-to-end process, content model governance can be more fluid with less need for documentation. The team managing the content model is the team using the content model.
With a platform team, you’ve got to be more strict with governance of the content model, and you need to document thoroughly. The team managing the content model is not consuming the content model. Other teams are.
Just as developers need APIs to be stable and well documented, the platform content model needs to be reliable and well documented. In fact, as we’ve already mentioned, the platform is delivering content via APIs. It’s not a metaphor; it’s reality.
Changes to an API can bring about “breaking changes.” Twitter’s shutdown of the free API was a big breaking change. Many API developers work to avoid breaking changes, but when they are needed, the developers usually document them extensively and communicate widely about it. Since the content model drives content APIs, similar care needs to go into managing them in the platform team topology, where the platform team may not even know the teams that are depending on them.
Similar content model changes in a stream-aligned team can often be absorbed since the team is self-contained.
R - E - S - P - E - C - T
Let’s go back to the Twitter API shutdown. The way in which it happened wasn’t respectful to its users. Life-saving information went dark immediately. Information that made our planet better stopped. Quirky little projects that brought a smile to our faces just fizzled into the ether.
If you’ve been reading Model Thinking for long enough, you know that I talk a lot about governance. You may even know that I don’t love the harshness of the word governance. But I talk about it a lot because it’s so important to content strategy and to our users. (Shoutout to Issue 31 “Who is the user, really?”)
So regardless of what typology your team falls into, you should be thinking about content model governance and documentation as a form of respect for those working with and consuming the content in the CMS.
“Governance is the process of managing change … Communication is critical to successful change.”
Managing Enterprise Content: A Unified Content Strategy by Ann Rockley and Charles Cooper
Top of mind
Best thing I read in the last 2 weeks: While it’s not deep, nor entirely fresh, Think Like A Freak by Steven Levitt and Stephen Dubner had some good reminders. The biggest, for me as a consultant, was “It has long been said that the three hardest words to say in the English language are I love you. We heartily disagree! For most people, it is much harder to say I don’t know.” There were also good thoughts about the importance of storytelling.
Something that made me smile in the last 2 weeks: Baseball is huge in my household. My younger son and I went to watch our local minor league team play recently, and he got a photo with a player whose uncle is my son’s teacher. This week, that player got called up to the Majors, where he tripled and score the game-winning run in the debut.
A pattern I noticed recently: My part of the world has these insidious field sandburs in the summer. Each year, there’s a pattern: Since we have a dog, we take a lot of walks. We see green burrs in the weedy grass along the sidewalk or in the fields at the park. Over a few weeks, they start browning up and drying out. Then they start hitching a ride home—on shoes, on socks, in the dog’s fur. Lastly, we start finding them in our carpet and rugs as we walk around without shoes—and it hurts!That’s the pattern. It’s been particularly rainy this season, and it seems like there’s a bumper crop of burrs this year. Right now, we’re at the “hitching a ride home” stage of the pattern …
John Collins
Need an expert review?
I offer limited advisory sessions for teams working through content modeling, CMS selection, content architecture, governance, and migration planning.
Bring your challenge, documents, or diagrams. Leave with actionable recommendations and next steps.
Welcome to the 1 new subscriber who joined us since the last issue of Model Thinking.
Model Thinking
Improving your organization’s content
Model Thinking is for people who work where content, systems, and design meet.Each issue connects ideas across content strategy, content modeling, and content management system design with a focus on what actually works in practice.