arrow Products
Glide CMS image Glide CMS image
Glide CMS arrow
The powerful intuitive headless CMS for busy content and editorial teams, bursting with features and sector insight. MACH architecture gives you business freedom.
Glide Go image Glide Go image
Glide Go arrow
Enterprise power at start-up speed. Glide Go is a pre-configured deployment of Glide CMS with hosting and front-end problems solved.
Glide Nexa image Glide Nexa image
Glide Nexa arrow
Audience authentication, entitlements, and preference management in one system designed for publishers and content businesses.
For your sector arrow arrow
Media & Entertainment
arrow arrow
Built for any content to thrive, whomever it's for. Get content out faster and do more with it.
Sports & Gaming
arrow arrow
Bring fans closer to their passions and deliver unrivalled audience experiences wherever they are.
Publishing
arrow arrow
Tailored to the unique needs of publishing so you can fully focus on audiences and content success.
For your role arrow arrow
Technology
arrow arrow
Unlock resources and budget with low-code & no-code solutions to do so much more.
Editorial & Content
arrow arrow
Make content of higher quality quicker, and target it with pinpoint accuracy at the right audiences.
Developers
arrow arrow
MACH architecture lets you kickstart development, leveraging vast native functionality and top-tier support.
Commercial & Marketing
arrow arrow
Speedrun ideas into products, accelerate ROI, convert interest, and own the conversation.
Technology Partners arrow arrow
Explore Glide's world-class technology partners and integrations.
Solution Partners arrow arrow
For workflow guidance, SEO, digital transformation, data & analytics, and design, tap into Glide's solution partners and sector experts.
Industry Insights arrow arrow
News
arrow arrow
News from inside our world, about Glide Publishing Platform, our customers, and other cool things.
Comment
arrow arrow
Insight and comment about the things which make content and publishing better - or sometimes worse.
Expert Guides
arrow arrow
Essential insights and helpful resources from industry veterans, and your gateway to CMS and Glide mastery.
Newsletter
arrow arrow
The Content Aware weekly newsletter, with news and comment every Thursday.
Knowledge arrow arrow
Customer Support
arrow arrow
Learn more about the unrivalled customer support from the team at Glide.
Documentation
arrow arrow
User Guides and Technical Documentation for Glide Publishing Platform headless CMS, Glide Go, and Glide Nexa.
Developer Experience
arrow arrow
Learn more about using Glide headless CMS, Glide Go, and Glide Nexa identity management.

Not stupid enough: why asking the simple tech questions is best

Presented with complexity, it's an all-too-common reaction to ask what seem like complex questions about the subject at hand. That's not a situation that helps publishers. Keep it simple.

by Rob Corbidge
Published: 16:12, 01 December 2022

Last updated: 18:48, 01 December 2022
A red haired woman looking at an accurate blueprint design of a time machine by Stable Diffusion

Narrower than it was, there is still a divide between those who create content in publishing and those who make the dissemination of such content possible.

We're talking about Editorial versus Technology.

My first experience with a taxonomy-driven publishing system was not a good one. A highly efficient print editorial team was simply told, "This is what you do now for the online version," and an extra production step was added in which editors would add categories to stories as the content was pushed through towards publication for both print and online.

The introduction of such a step was not explained beyond "It's for the web". Ours was a tickbox system that followed defined rules that the business and editors had properly thought through - though I can see now it it was the wrong tickbox system for that publication and had notable holes in categorisation. 

At least though it wasn't free-form tagging, with the full decision and burden on how to categorise a piece of content left to the riotous imagination of journalists and whatever tags seemed right at the time, misspellings or otherwise. 

For us then, the print Editorial team could make zero representations about the process, as the excellent online team had more than enough on their plate, and they were the only conduit upwards to the people who had power of control to configure the rules and settings. Presumably the system itself wasn't simple at all to reconfigure, but we Editorial were never explicitly told that, and guess what - not being furnished with any information simply lead to resentment. 

How ironic that an information business was so poor at internal comms. Yet I know my example, drawn as it is from the mists of time, is far from unique.

So here's the lesson, based on our long engagement with publishers from both tech and content perspectives: Editorial need a Tech champion, in a two-way channel, that is respected by both houses.

The fact is that such a role, or roles, can be filled by either side, or both. The important part is that they ask the simple questions, and can understand the viewpoint of both sides. If they can only explain themselves using the lexicon of just Editorial or just Tech, then they are highly unlikely to bring about the desired outcome of bringing understanding. 

Not getting bogged down in terminology is vital: too much terminology will dominate thinking and lead to lack of clarity. Remove room for misinterpretation or dual meaning, so neither party can accidentally invoke the terms of another with disastrous consequences: what could a humble 'tag' be, for example, across the width of an entire organisation? 

Secondly, the champions must understand that the actual effect of a given improvement, feature, or function is all important - whatever the intention of that change is. Where something might be trivial or invisible from a technical perspective, but let's say added a two hours onto the creation time of an article for the writer, the champion should be there to head off such an effect.

If it can't be described in simple terms, then the chances are the person explaining it to the Technology team doesn't fully understand it themselves - and beyond that point Technology can only deliver something partway correct if at all.

The most confident and competent tech people, such as the ones who built our own headless CMS, don't choose or need to express themselves using esoteric terminology. Equally, the very best editorial people don't see the Tech team as a barrier to negotiate before they can do the thing they want - publish content.

It's not easy to build such a culture, but the results are worth the effort. Tech have someone they can trust to understand, and Editorial have someone who can explain, a situation that can also switch polarity depending on who is driving the updates. 

This is speaking from experience. I don't wish to embarrass myself in public about how long it took me to understand a widget as a discrete component within a system that performs a given function, but it was too long. I was simply approaching my understanding from an overly complex standpoint. For another of my colleagues years back, a widget was the thing in a can of beer that made it frothy: I wonder if they still assume that now.

There's also a monetary consideration. If the thing being built or bought cannot be explained to all who will use it, in whatever capacity, then the money is likely not being spent wisely, or at the very least imperfectly.

A simple question is never a stupid question, yet the turmoil the publishing industry has gone through in recent years has lead to a belief in complexity as a sign of competence. 

That is not true, and never will be.