There’s a post I read from a marketing Substack that I keep thinking about, because it’s precisely what I have been recommending, but have not really spelled it out as obviously.
The idea: every marketing team needs one person who understands how AI tools actually work under the hood, not so they can write prompts, but so they can build repeatable systems and package them for everyone else. One person builds it, and the whole team benefits without having to go deep themselves.
That’s a good model, and it’s not just useful for marketing teams.
It applies just as much to HR, operations, finance, legal, customer service, and executive functions as it does to content and campaigns.
The mistake most organizations make is assuming that either everyone needs to become an AI power user or that buying a tool is enough. What really works is having at least one person on the team who understands the architecture, who can translate between what the team actually needs, how they work, what they do, and what the tools can actually do. This is the person who builds the infrastructure that makes everyone else more capable without requiring them to go deep themselves.
Let me be clear, this isn’t IT. If you don’t have an IT person, you don’t need to hire one. If you have an IT person or department, what I’m talking about in this article is a translator between the team and IT.
This person might already exist on your team and just hasn’t been identified yet. It might be you, even if you never would have called yourself an AI person. Or it might be someone you bring in to set the foundation, train that internal person, and hand it off.
Why this role is different from “AI champion”
Most organizations, when they decide to get serious about AI, go looking for enthusiasm. They want someone to run the lunch-and-learn, organize the demos, and build the internal newsletter. That’s a useful person to have, but also not the same as what I’m describing.
The person I’m describing understands systems, not just tools. They think in terms of inputs and outputs, not in terms of which chatbot to use. They care about whether a workflow is repeatable, not just whether it worked once. They ask questions like “what context does this need every time” and “how do we make sure this doesn’t break when something upstream changes.”
That’s a different skill set from enthusiasm, and it’s worth naming it separately because organizations that conflate the two end up with a lot of hype and not much that actually runs.
What this skill set actually looks like in practice
In concrete terms, the person filling this role would be doing things like building structured instruction sets that encode your team’s best processes and make them repeatable, configuring AI tools to have consistent access to the context they need (your brand guidelines, your client data, your internal frameworks), connecting tools so outputs from one step become inputs to the next without anyone manually moving information, and maintaining the whole system so it stays current as tools evolve.
They’re not doing this instead of their job. They’re doing it in service of the team’s job, which is what makes it stick.
Why this keeps you relevant
Most career advice right now is pointing people toward learning AI tools, and that’s genuinely necessary. Everyone on a team benefits from knowing how to use the interfaces they have access to. But using tools and building with them are different skills, and the second one has a longer shelf life. Tools change, get acquired, get deprecated. What doesn’t change is the ability to look at how your team works, identify where the friction is, and build something that reduces it. That’s the skill worth investing in deeply, and it’s also the one most teams don’t have covered yet.
If you’re building that skill set, or if you’re a leader trying to identify and develop that person inside your organization, the starting point is less about learning specific tools and more about learning to think about AI infrastructure the way an operations person thinks about any system: what does it need to know, what does it need to do, and how do we make sure it keeps working when we’re not watching it.
This is a genuinely durable role, and it’s probably not as far from your existing systems thinkers as you or they might expect. If you’re trying to build toward it yourself, that’s work I help people do. And if you need someone to come in and be that person for your team while you figure out who fills it long-term, that’s something I do too.