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

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.