Am I a content engineer?

I have spent most of my career thinking of myself as a writer, journalist or editor. Recently I have started wondering whether some of the work I am doing has a different name: content engineer.

I am not entirely comfortable with it. Partly because I am not an engineer in the conventional sense. I do not spend my days building production software. I would feel ridiculous pretending otherwise. Partly because content already has enough inflated job titles. And partly because the term itself is contested.

Content engineering is not new. Its older meaning is closely connected to structured content, taxonomies, metadata, content models, CMS architecture and the technical systems that allow content to be reused across channels.

The newer AI-era definition is broader. It increasingly describes people who design workflows, knowledge systems, agentic processes and repeatable infrastructure around editorial production. That version sounds surprisingly close to parts of my job.

But I am still not convinced I should call myself a content engineer. The more interesting question may be whether editorial work itself is becoming more engineered.

I am still writing. But the writing is no longer the whole job

This week gave me a good example. I went to Accountex North with a set of questions around Making Tax Digital, but I was not primarily looking for an article.

I wanted to know what accountants were misunderstanding, where operational pressure was actually appearing, what quarterly reporting changed, what happened with multiple income sources and where the evidence gaps were in the material we already had.

I chose sessions against those questions. I recorded and transcribed what I heard. I compared HMRC, software providers and practitioners. I looked for repeated signals and contradictions. Then I banked the useful evidence so it could survive the event.

That evidence may eventually become articles, FAQs, video answers, page improvements, GEO material or something I have not identified yet. The important shift is that the published asset is no longer necessarily the starting point or the final boundary of the work.

I wrote about this yesterday in The content job is moving up a level. The useful unit of work can now be a question, an evidence gap, a decision, a source, a recurring pattern or a piece of context that makes the next output better.

That starts to look less like a publishing workflow and more like a system.

I keep building systems around the content

I have noticed the same pattern elsewhere. With customer stories, I have been experimenting with what happens if the intelligence gathered during an interview survives the finished case study.

A customer interview contains more than the quotations that make the final edit. There are proof points, themes, objections, unanswered questions, useful language and things you wish you had asked. Traditionally much of that disappears once the story is published.

I am interested in making it recoverable. The story still matters. But it leaves behind structured editorial memory that might improve the next interview, strengthen a future argument or reveal a recurring theme across several customers.

My personal Editorial Intelligence system has developed in a similar way. I started using GitHub because I wanted somewhere durable to save work. It gradually became something closer to an operating layer: decisions, working notes, experiments, article drafts, project state and save points that allow me to recover what I was thinking instead of reconstructing it from memory.

That led me to write about making work recoverable and why prompting is becoming routing.

Increasingly I am not asking one AI to do everything. I am deciding which system should hold the context, which tool should perform a task, what needs human judgement and where the useful result should be stored so it can be used again. Again: system, not just output.

GEO pushes editorial work even further upstream

Generative engine optimisation has made this more obvious. The uninteresting version of GEO is to take an article and make it easier for an AI system to quote. The more useful version begins earlier.

What are people asking? Where does the organisation have a weak answer? What evidence would make that answer stronger? Which sources should we gather? What should be published, structured or updated so the answer becomes genuinely useful and retrievable?

That changes the editorial brief. Search and AI behaviour can become an input into reporting rather than simply a distribution channel after publication.

At Accountex, I used known question gaps to decide what evidence to collect in the physical world. The machine signal influenced the journalism. The journalism should now improve what the machines can retrieve.

That feedback loop feels important. It also needs an editor in it.

Demand data can tell me that people are asking a question. It cannot decide whether the premise of the question is wrong, whether the available evidence is good enough, whether two sources genuinely constitute a pattern or whether there is a more important story nobody is searching for yet.

The system can become more sophisticated without editorial judgement becoming less important. In fact, I suspect the opposite is true.

This is where “content engineer” starts to fit

The modern descriptions of content engineering tend to emphasise a few things:

• reusable workflows rather than one-off production
• structured knowledge rather than disconnected assets
• AI and automation used as infrastructure rather than novelty
• content designed to travel across formats and systems
• feedback loops that improve future work
• human governance of quality, evidence and brand judgement

I am doing versions of all of those things, and I expect to do more of them.

I want customer-story evidence to become reusable editorial intelligence rather than disappear into finished pages. I want event reporting to create evidence banks rather than folders of forgotten transcripts. I want GEO work to connect observed demand with reporting, evidence gathering, publishing and measurement.

I want narratives to be tracked after publication so we can see which ideas travel, mutate and get adopted. I want AI systems to work from durable context rather than repeatedly starting from blank prompts. And I want the knowledge generated by one project to improve the next one.

That is difficult to describe as simply “writing content”.

But the term also bothers me

There is a danger that content engineering becomes another way of making ordinary editorial work sound more technical than it is. Editors have always built systems.

Newsrooms have style guides, commissioning processes, source networks, archives, taxonomies, production desks and institutional memory. Good editors have always decided what evidence is sufficient, what information should be retained, how a story should travel across formats and how one piece of reporting should inform another.

AI has not invented any of that. It has changed the scale and the mechanics.

Another problem is that “engineering” can imply determinism. Content is not software. You cannot reliably specify an input, run a process and expect the same quality of intellectual output every time.

Reporting changes your assumptions. Interviews take unexpected turns. Evidence contradicts the brief. A phrase that looks insignificant becomes the centre of the story. A useful editorial system needs to preserve room for surprise.

If content engineering becomes synonymous with automated production pipelines, I am much less interested in it. There are already enough systems designed to produce more content. The problem I care about is producing better decisions around content.

Maybe the important word is not engineer

Yesterday I used a phrase I currently prefer: editorial ownership. You can stay close to the craft while taking responsibility for more of the system around it.

Not just writing the article, but identifying why it needs to exist. Not just conducting the interview, but deciding what the organisation should remember from it. Not just publishing the page, but understanding whether people and machines can retrieve its argument.

Not just launching the campaign, but seeing whether its language travels. Not just using AI, but designing where AI belongs in the workflow and where it does not.

Content engineering may be one useful description of the infrastructure involved. Editorial ownership describes the responsibility. Editorial intelligence is the broader idea I keep circling: how organisations preserve and apply judgement across all of this.

The future role may not have settled on a name yet

I do not think “content writer” adequately describes where this kind of work is heading. I am not convinced “content engineer” does either.

The future role seems to sit somewhere across journalism, editorial strategy, knowledge management, content operations, AI systems and measurement. It needs enough technical fluency to design workflows without assuming everything should be automated. It needs enough editorial experience to know that a neat process can still produce a bad idea.

It needs enough commercial awareness to understand why the work exists without turning every editorial decision into short-term attribution. And it needs to remain close enough to real people, reporting and evidence that the system does not simply optimise itself around its own assumptions.

Perhaps companies will eventually call that a content engineer. Perhaps they will invent another title.

For now I would not put “Content Engineer” in my LinkedIn headline. But I am comfortable saying that I am increasingly doing content engineering. The distinction matters to me.

I am not trying to borrow the authority of engineering. I am trying to describe the fact that the work is moving beyond producing individual pieces of content and towards designing the environment in which good editorial decisions can compound.

Maybe the job changed before the title did.