My take on the content engineer (for now)
Content engineering isn't here to kill your content strategist. It's here to expand what they can do.
👋 Hey, I’m George Chasiotis. Welcome to GrowthWaves, your weekly dose of B2B growth insights—featuring powerful case studies, emerging trends, and unconventional strategies you won’t find anywhere else.
This note is brought to you by Minuttia.
Most companies have no idea how they appear in AI search results.
The team at Minuttia built a free AEO report that shows how your brand appears across AI platforms like ChatGPT and Perplexity, based on real prompts, citations, and sentiment data.
You’ll get:
A visibility score and share of voice
Breakdown by topic, platform, and sentiment
A shareable report with clear next steps
It takes 30 seconds to request. Minuttia’s team does the rest.
Get the report. See how visible you really are. Then fix what’s broken.
A few weeks ago, Lindsay Boyajian Hagan, VP of Marketing at Conductor, published a LinkedIn post that made a lot of people uncomfortable.
The gist of it: “Content Engineer” is vendor-created job security. The skills aren’t new. Your content strategist, your SEO manager, your marketing ops person who automated your Marketo workflows? They were already doing this work. You just called them something else.
The post got 230 reactions and over 40 comments. Some people agreed. Some pushed back. Some did both at the same time.
I read the post. I read the comments. I read what AirOps has been publishing about content engineering as a discipline. I read what Jasper has been saying about the “AI-native Content Engineer.” And then I sat with it for a while.
Here’s where I landed: Lindsay raised some valid points. But so did the people building these tools. And the truth, as usual, is more interesting than either side makes it sound.
Let’s go.
Where Content Engineering Came From
Let’s start with some context.
The term “content engineering” didn’t appear out of thin air.
It has roots that go back over a decade. Cruce Saunders, one of the earliest proponents of the concept, has been writing about content modeling, metadata design, and structured content systems for years.
In his framework, content engineering is about organizing the shape, structure, and application of content through seven disciplines: modeling, metadata, markup, schema, taxonomy, topology, and graph.
That’s the academic lineage. But the term’s recent resurgence in B2B SaaS and content marketing circles has a very different origin story.
In the past few years, a new generation of AI-powered content tools has entered the market. Companies like AirOps, Jasper, and others introduced platforms that promised to transform how teams create, optimize, and scale content.
AirOps, in particular, became one of the most vocal evangelists of the concept. They coined the term “10x Content Engineer” and published extensively about why this was the most strategic growth hire a company could make in 2026.

Here’s what I think happened. And I want to be clear: I’m not here to diss anyone. I’m here to provide clarity.
These tools are genuinely innovative. They offer new ways to approach growth through the combination of content and AI.
Some of them have steep learning curves. And the companies behind them needed a way to describe the person who would get the most out of their product. The “content engineer” became that description.
In other words, the rise of content engineering to the surface was driven by two things simultaneously:
A genuine shift in what’s possible when you combine content expertise with AI software.
And second, a positioning mechanism by the companies building these tools. A way to create a market category and define the buyer persona at the same time.
And that’s not a criticism. It’s just how B2B SaaS works. You build a product, you define the category, you name the role that needs your product. AirOps did this effectively. Jasper did this. Others in other categories did this too.
There’s nothing inherently wrong with it. It doesn’t mean they don’t have a good product. Many of them do.
We should be honest about the fact that the “content engineer” as a standalone role is partly a product of this positioning.
But that doesn’t mean the underlying shift isn’t real.
What’s Actually New (and What Isn’t)
Lindsay’s core argument was that the skills people call “content engineering” have existed in marketing for years. And she’s right.
Content strategists have been building repeatable systems. SEO managers have been automating metadata workflows. Marketing ops people have been configuring Marketo and HubSpot to trigger content based on user behavior.
None of that is new.
What is new is the technology layer that amplifies what those skills can produce. And that’s not a trivial distinction.
Think of it this way. A carpenter and a CNC machine operator both work with wood. The underlying knowledge of materials, joinery, and design principles overlaps significantly. But the CNC operator can produce at a scale and precision that the carpenter, working manually, simply cannot. The craft is related. The output potential is different.
The same logic applies here. A content strategist who knows how to build a content calendar is valuable. A content strategist who knows how to build a content calendar AND can design an AI-powered workflow that turns certain opportunities of that calendar into published, optimized, with-human-in-the-loop pages at 10x the speed? That’s a different capability.
One of the comments on Lindsay’s post captured this well. Ajdin Perco wrote something to the effect that the examples Lindsay gave (SEO managers, content strategists, marketing ops people) are roles involved in ideating, managing, and optimizing content that others produce. They’re not necessarily the ones building the systems that produce it at scale. Content engineering, he argued, is about putting in place a system and connecting tools that produce content at scale. Those roles could help build it, but they couldn’t necessarily do it on their own.
I think that’s the right framing.
Meanwhile, a SEMrush analysis of 8,000 content marketing job listings shows the market is already moving in this direction. “Content SEO Manager” roles now account for 20% of all listings, and the trend is clearly toward hybrid titles that combine content ownership with search performance and systems thinking.

And as MarTech reported, the 2026 content marketing role is no longer a narrower writing job but a broader visibility mandate.
The skills are converging, whether we give them a new title or not.
The Venn Diagram
So, where does the content engineer actually sit? In my experience, it’s at the intersection of four things:
Technology Enablement: Understanding how AI tools, workflow platforms, and CMS systems connect and work together.
New Skills (specific to those tools): Prompt engineering, workflow design, quality assurance for AI-generated content, and more.
Existing Strategic Skills: Content strategy, SEO fundamentals, product marketing, and editorial judgment.
Growth Potential. The ability to identify scalable content opportunities (more on that later) and build systems that capture them.
No single existing role covers all four circles. A content strategist typically covers circle 3. An SEO specialist might cover parts of circles 2 and 3. A marketing ops person might cover circles 1 and parts of 2. But the person who sits at the center of all four? That’s the content engineer.
Now, does every company need to hire someone with that exact title? No. And Lindsay’s point about not letting vendors dictate your org chart is well taken. But the functional need is real, regardless of what you call it.
Content Engineering Is a Craft, Not a Title
Here’s where I think the conversation goes off the rails. Both sides are treating content engineering like it’s primarily about a job title. It’s not.
Content engineering is a craft.
It’s an approach. It’s a capability that can live inside different roles within an organization.
Your senior content strategist can practice content engineering. Your SEO lead can practice content engineering. Your growth marketer can practice content engineering.
The question isn’t whether you need to post a job listing for a “Content Engineer.” The question is whether someone in your organization has the skills and mandate to build AI-powered content systems at scale.
And this matters because the alternative framing (content engineering as a distinct, must-hire role) creates unnecessary anxiety.
It makes companies feel like they need to go find a unicorn who’s part product manager, part writer, part data scientist, and part AI whisperer, as Lindsay put it. That’s neither realistic nor necessary for most organizations.
What is necessary is investing in the capability. Train your existing people. Give them the tools. Give them the mandate. The role title is secondary.
Where Content Engineering Actually Matters Most
Now, here’s where I want to get practical. Because I think there’s a misconception floating around that content engineering is about applying AI workflows to every piece of content a company produces. It’s not. At least not in my experience.
Content engineering is most valuable for scalable opportunities.
Let me give you an example.
Say you sell HVAC software. Your potential customers are HVAC contractors across the United States. Every state has different licensing requirements for HVAC work. That’s 50 states, each with unique regulations, application processes, fees, and renewal timelines. Some example states:
hvac license florida
hvac license texas
hvac license ny
Creating a comprehensive, accurate page about HVAC licensing for each of these states is a scalable opportunity. It’s the kind of content that follows a repeatable pattern, requires structured data, and serves a clear audience need.
Building an AI-powered workflow that researches state regulations, generates draft pages, ensures accuracy through human review, handles internal linking, and publishes to your CMS? That’s content engineering as a craft.
You don’t need a “Content Engineer” on staff to do this. But you do need someone who can think in systems, who understands the tools, and who can build the workflow.
Other content engineering opportunities include:
Content refreshes for scalable opportunities: If you have hundreds of scalable opportunity pages that need periodic updates, building a workflow that identifies underperforming pages, generates updated drafts, and routes them for human review could be a content engineering opportunity.
Programmatic content for product variations. SaaS companies with multiple integrations, use cases, or customer segments can build templated content systems that scale. (Think of how Zapier targets thousands of long-tail keywords with integration pages.)
Location-based or compliance-driven pages. Any business that needs to address regional differences at scale.
Where content engineering is NOT the right approach (again, in my experience):
Content that has the objective of generating revenue (e.g., alternative listicles, comparison guides, and generally commercially-focused pieces)
Content that has the objective of thought leadership (e.g., data studies, surveys, opinion pieces)
Content that has the objective of gaining attention at scale, mainly through social media (e.g., giveaways, GIFs, events-and-trends-based pieces)
These require human judgment, nuance, and original thinking that most workflows can’t replace (for now). And conflating the two creates real risk.
As I shared on LinkedIn a few weeks ago, the marketing industry (particularly for B2B SaaS companies) has an AI content hangover. And I can tell you that for many companies, the hangover is really bad.
That’s because many companies fell for the promise of AI-generated content and used it blindly for every piece they put out.
The thing is, there’s a right and wrong way to deploy AI content strategies, and as I just explained, not every piece of content “qualifies” for that.
Let’s see what principles you should follow when deploying content engineering strategies.
Four Principles That Should Guide It
Every time I think about content engineering, whether as a craft or a role, I keep coming back to four principles that should be non-negotiable:
Let’s look at these principles in more detail:
Quality First: Any system you build should produce content that meets or exceeds the standard you’d set for manually-created work. If your AI workflow produces mediocre output at scale, you’ve just created a very efficient way to damage your brand.
Ethical Execution: Don’t use these systems to manipulate search engines. Don’t publish content that misleads users. Don’t flood the web with near-duplicate pages that add no value. The technology makes it easy to do all of these things. The principles should prevent it.
Long-Term Sustainability: Every content decision should be evaluated against this question: “Does this compromise our ability to grow in the future?” Publishing 500 pages in three months might get you short-term traffic. It might also get you a manual action penalty that takes months to recover from. Build systems that create lasting value, not short-term gains.
Human in the Loop: No workflow should run from input to publish without a human checkpoint. Someone needs to review what the system produces, verify claims, check tone, and make the call on whether it’s good enough to go out under your brand. Automation without oversight isn’t efficiency. It’s a liability.
I know these aren’t controversial principles. But they’re worth stating explicitly because the excitement around AI-powered content production can easily override good judgment.
The Real Question: What Is Content Engineering Expanding?
Let me try to tie this together.
I don’t think content engineering is a new role. I don’t think it’s purely vendor-created marketing, either.
What I think is this:
Content engineering represents an expanded spectrum of what content marketing, as a function within the broader marketing organization, can do.
Before these tools existed, the possibilities were mostly bounded by human bandwidth and other resources (e.g., budget). You could publish X articles per month because that’s how many your team could research, write, edit, and publish. You could refresh Y pages per quarter because that’s what your headcount allowed. You could cover Z markets because going beyond that was operationally impossible.
And I won’t even discuss budget and other limitations.
AI-powered content systems expand those boundaries. Not infinitely. Not without oversight. Not without quality controls. But meaningfully.
And that expansion doesn’t mean companies should stop hiring content strategists, or product marketers, or SEO specialists.
It doesn’t mean those roles become obsolete. It means the overall function of content marketing can do more than it could before.
A content engineer, however you choose to define the role, doesn’t write death notices for existing jobs. They add a new layer of growth potential. They unlock opportunities that were previously too resource-intensive, too slow, or too operationally complex to pursue.
Final Thoughts
The debate around content engineering reminds me of earlier debates in marketing. Remember when “growth hacking” was the hot term? Some people argued it was just marketing with a new label. Others argued it was a fundamentally new discipline. The truth was somewhere in between: the underlying skills overlapped heavily with traditional marketing, but the mindset, the tooling, and the velocity were genuinely different.
Content engineering is following a similar path. The skills are not entirely new. The tools are. The possibilities are. And the companies that figure out how to combine the old skills with the new tools, ethically and at scale, will have a meaningful advantage.
Whether you hire a Content Engineer, upskill your existing content strategist, or build the capability across your team, the important thing is that someone in your organization is thinking about content as a system, not just a series of individual pieces.
That’s what’s actually new here. Not the title. The scale of what’s possible.
Thank you for reading today’s note, and see you again in two weeks.
Disclaimers and Limitations
GrowthWaves and its author are not affiliated with, sponsored by, or compensated by AirOps, Jasper, Conductor, or any other company mentioned in this note. This is independent editorial analysis. AI tools were used as a research assistant in the preparation of this piece. All claims are sourced and linked throughout.




