The AI is almost never the thing that’s broken

Anca Pintilie spent six years running marketing and brand for one of Amazon’s largest operations in EMEA, most recently leading the effort to bring six regional teams onto one operating model. She’d previously worked at Revolut, Oracle, and in agency roles.

Whatever hasn’t been dealt with falls out of the bag

Ask Anca what she checks before a team buys AI, and she doesn’t start with the tool. “Are they able to describe how work actually happens within their function?” That means understanding how decisions get made, which ones trigger spend, what data feeds them, where that data comes from, and whether it all has ‘the same refresh rate’.

Businesses reorganise so often, she says, that any chart is obsolete before people settle into their new roles. Unless the operating model has been mapped in the past month, whatever’s on the slide is fiction, tidied up for management.

She reaches for the TikTok bag-check videos to describe what happens next: someone empties their bag on camera, and out comes whatever they haven’t dealt with in three weeks. Buy or build the AI before doing the work of finding out, and that’s what gets automated, in public, at scale.

Discovery always takes longer than planned

Anca had planned on two months of discovery across the six teams she inherited. It took five to six months, and around 72 calls, before her team got anywhere close to the truth. Even that wasn’t enough until everyone stopped dialling in and got in one room with a whiteboard.

Mapped, in her definition, means codified: decisions written down somewhere, not held in two people’s heads. “If a team member leaves tomorrow, do we know how they made decisions and where the value came from?” she asks. If the answer’s no, the map isn’t finished.

Roughly 300 to 400 people, it turned out, were running 13 different operating models, and no one had noticed. It wasn’t anyone’s fault: each had drifted to fit whatever the business had asked of that team at the time. One built for quality, another for volume, another for retention over growth. But they’d become difficult to unwind once people had built their roles around them.

“Complexity pays salaries,” she says. “Somebody’s run a process for five years, so now they’re attached to it.”

Her advice for teams in the same position is to skip the six-month version, get into a room, be honest about what’s happening, map it, simplify the reporting and decision-making, and “after that you can take your decisions on AI”.

Ghost processes grow around the tool that didn’t fit

Anca’s seen it happen first-hand. A tool built for how the North America team worked was then rolled out to Mexico, where the channel mix, decisions, and data were all different. The result, as she puts it: “The team starts building ghost processes to actually manage the inappropriate tool that you just brought in. So it becomes even messier.”

The alternative is often duller than an AI rollout, and doesn’t need AI at all: a simple deterministic model, or compliance and governance requirements built directly into the brief.

Technology is decision number three

Anca sequences the work in three steps: operating model first, change management second, then the technology itself.

The complaint she hears most often is that a marketing team isn’t getting value from AI. “The AI is almost never the thing that’s broken.” What’s usually missing is a clear business question, data everyone agrees on, or a standard somebody owns. She’s dealt with the data problem directly: 68 external vendors feeding one part of the business globally, with no single measurement framework across them.

What makes her cautious is a vendor selling the tool as a layer on top of the current system, without asking whether the business underneath it works.

Adoption is not usage

For Anca, change management starts before anyone is trained on the tool. It means telling a team what’s about to change in their inputs and asking how their behaviour needs to shift.

She pushes back on framing this as training. Usage isn’t adoption, she says, and most teams get the first without the second. “Embedding means you don’t work around your technology, it’s about how you change the way you make decisions now that you have it.”

A change mandate, including her own, needs an exit built in from day one. Once a system’s stable and just needs maintaining, that’s a different job, and paying senior rates for maintenance is the wrong spend. Her advice for mid-market teams: “sometimes it’s okay to go in stages, you don’t have to do it all at once.”

It’s done when the operating model has absorbed the system and the system just runs on its own.