Not everyone in marketing should be an AI builder | MarTech

Marketing organizations are rewarding employees for building AI tools, even though most marketers will use tools built by others. That emphasis risks overlooking the people who keep those tools running, monitor their performance, and put them to work.

In September, I gave a talk at the AUTONOMOUS conference called “Not Everyone Should Be a Builder.” In a follow-up roundtable on the topic, one person said it reminded him of the dot-com era, when he was told that “one day everybody’s going to be writing HTML.”

In the 30 years since, he’s written about three lines of HTML. Instead of building the technology, he used what other people built. He wondered if the same would hold true for AI. When his refrigerator stopped working, he asked AI which new one to buy. It walked him through troubleshooting instead, pointed him to a repair video, and the fridge got fixed. (I love this story.) He observed that he hadn’t built anything with AI but was just a user, and said, “I think we’re going to have a whole bunch of those.”

We’re pushing to make everyone a builder

In April 2025, Shopify CEO Tobi Lütke told employees that reflexive AI use is now a baseline expectation and that it would be reflected in performance reviews. Plenty of companies followed suit, and Accenture has linked AI use to promotion eligibility. In the organizations I talk with, the bar has moved from using AI to building with it: custom GPTs, agents, and automations stitched between the CRM and the email platform. If you aren’t building, it gets noticed at review time.

As a result, people are building. Dataiku surveyed 685 CIOs in July, and 84% agree employees are creating AI agents and applications faster than IT can govern them. Another 72% say they can’t reliably verify whether those agents deliver the results they were designed to deliver.

No surprise. According to Goodhart’s law, when a measure becomes a target, people start gaming the system, making it less useful as a measure.

We end up with a monoculture

The people who lean hardest into building, especially early, tend to share a personality. They tend to be innovative, creative, comfortable with risk, and happiest with a blank canvas. Those are wonderful traits. Reward only those traits, though, and you end up with what I call a “builder monoculture.” You have a team hired, trained, and promoted around one personality type.

A partner at a small industrial marketing agency told the roundtable his four-person team is all in on AI. How did he get there? “The ones that weren’t are not in my agency anymore.” Ouch.

Then he talked about his designer, the slowest adopter on the team. At first, that frustrated him because he wanted to see how far she could push the tools. On reflection, he’s glad she’s there. “I also want that human touch.”

A monoculture ships fast. But if my experience is any indication (I identify as a builder), it leaves behind a pile of prototypes because we tend to move on to the next idea once the thing runs.

The roles beyond builders

A working AI organization needs a mix of people, yet most leaders I talk to focus only on teaching people how to build. The difficult part is that roles (and their associated personalities) get ignored.

• Builders start things. They see a repetitive task and want to automate it.
• Maintainers keep things running. They like to troubleshoot, find the problem, and fix it. They’re often not wild about a blank canvas.
• Monitors watch what the system does. They like keeping work inside the guardrails, and they notice drift before anyone else does.
• Users apply AI to their own work without building the tools. This is the biggest group, and the one the HTML analogy predicts.

These are different temperaments. When reviews only reward building, your natural maintainers spend their energy trying to look like builders, and the job they’d be best at goes undone.

Building architectural fitness

An architecture governance lead at a financial services firm had a name for this. He called it architectural fitness, saying, “The build is the easy part.” In his experience, builders assume a maintainer or someone else will take care of what comes next. “But that’s not a good idea.”

A consultant finishing a project in the energy sector described the moment it catches up with you. Someone builds a cool tool and wants to deploy it the way the rest of the system runs. “And we’re going, oh, we never actually sat down to define that.” When something breaks at the edges, the fix usually lives in “a lot of institutional knowledge in like three or four heads.”

I heard the same pattern when I keynoted DC State of the Stack in September. A platform and SRE lead at a membership-based online grocer ran 11 two-day AI dojos in about six weeks, followed by an all-hands where 300 people saw what their colleagues had made. The dojos worked. Seventeen applications and counting, from people who now knew how to build. His description of what came next: “abundance without triage.” Then, in his words, “governance arrived uninvited.”

In marketing, day two is predictable. The promotion ends, but the agent doesn’t turn it off. The model updates, and the brand voice now sounds weird. Someone renames a CRM field, and the lead-routing automation breaks without anyone being told. The person who built the whole thing moves to another team. Each one needs a maintainer or a monitor, and in most organizations, that person isn’t named.

Making room for maintainers and monitors

The right mix depends on your team’s size and how much you’ve built, so start with questions.

• What does your review system reward? If launching a new automation earns more credit than keeping an existing one healthy for six months, you’re paying for prototypes. Does “kept it running” count as much as “built it”?
• Who gets the call when something breaks? Every marketing team has that person. They’re your maintainer. Do they know it? Does their manager?
• Who notices drift? Think about the person who flags off-brand copy or asks where a list came from. That’s a monitor.
• Does anything ship without a second name on it? Pairing a builder with a named maintainer at launch costs almost nothing, and it’s much easier than retrofitting ownership after the fact.

And for the users in your organization, let them be users. A marketer who uses a well-built tool well is doing their job, and their review should say so.

Lessons from another disruption

Fifteen years ago in DevOps, a handful of teams were shipping continuously, and everybody else was watching. Platform teams, guilds, and blameless postmortems closed that gap by giving the people who kept systems healthy a real place in the work.

Marketing is at that moment with AI. The builders have done their part, and I’m grateful for them. The next step is to give maintainers and monitors a name and credit for their work.

Look at your team this week. Who are your builders? Who are your maintainers and monitors? And which of them does your performance review reward?