Like many of you, I watched the State of Martech 2026 keynote on MartechDay this past Tuesday. Around the forty-minute mark, Scott Brinker made a passing remark about MarOps careers.
AI is not taking over this work.
Quite the opposite.
As a result of AI, there is so much work to be done.
Frans Riemersma nodded. They both clearly believe it, and so do I. The line had no follow-up. A 55-minute keynote can only do so much, and the organizational implications of value engineering and context engineering were always going to be a thread to pick up rather than a chapter on their own.
So this is me picking up the thread.
A refit is the start, not the finish
The Royal Navy has a thing, a metaphor I use often, having experienced it many times myself, called FOST. Flag Officer Sea Training. After a ship comes out of a refit, no matter how good the new radar is, no matter how shiny the new combat system, it doesn't deploy until FOST has put the crew through hell for a few weeks. They simulate fires, hull breaches, and missile attacks. Basically, any kind of contingency is possible. The point isn't the kit. The point is whether the crew can fight with the kit they've just been handed.
The 2026 keynote did the refit beautifully. 15,505 vendors in the survey. The new SaaS-and-AI strata. Value engineering. Context engineering. Three pace layers and a Venn diagram with a golden context at its center. All of it is useful, all of it is accurate, and all of it is focused on what the ship now looks like.
The readiness work is what comes next. The FOST part. Someone in your organization has to actually figure out what the team has to become to operate any of this.
Matthew Niederberger
Read how I applied the FOST metaphor to the deployment of a CDP. It can be applied to any piece of tech you are onboarding within your organization.
Following the Billie story all the way through
The most useful organizational moment in the keynote was the IKEA Billie story. Frans told it to illustrate that AI doesn't have to mean redundancy. Their chatbot handled 70% of customer service queries, and instead of firing the staff that became redundant, IKEA reskilled them as interior design advisors. New revenue stream of $1.4 billion. It's a great example, and the point Frans was making is exactly the point I want to extend.
Because somewhere between "Billie goes live" and "we're now doing $1.4bn in interior design consulting" there were months of organizational work that nobody outside IKEA has written about. A manager had to figure out what to do with a person who'd spent eight years answering "where is my missing screw" and now needed to hold a conversation about open-plan kitchens. That curriculum didn't exist. Someone built it. Finance signed off on a re-skilling budget that wouldn't show return for at least a year, while the chatbot rollout next door was busy showing efficiency gains every week. Some people probably didn't make it through the transition.
That whole middle bit is the readiness work. Structure, capability, process. The IKEA outcome is what becomes possible when an organization actually does it. Most won't, not because they don't want to, but because the conversation usually stops at the technology decision.
I'd happily spend a year arguing about whether your context graph should be deterministic or probabilistic. I think the harder and more valuable conversation is which manager owns the re-skilling plan when an agent absorbs a workflow.
Ross Stevenson
As Ross Stevenson duely noted in the article above:
What made IKEA’s approach particularly impactful was how they identified the gap between the employees’ current skills and the demands of the new roles.
Instead of starting from scratch, they built on the employees’ foundational customer service knowledge. Training programs focused on crafting specific customer interaction, design, and sales capabilities.
Others were up-skilled to handle more complex customer service tasks that required empathy, creative problem-solving, and expertise. The skills we know that AI can’t replicate.
Context engineering is mostly an organizational job
Context engineering, the way Scott frames it, is about getting the right data and tools to an agent at the right time with the right governance. Fine. I agree with the definition. Every word in that sentence is doing work that someone in your organization has to actually do.
Right data. Who decides what right means? In whose authority does that decision sit? When the marketing ops team says "we need session-level context for this agent" and the data platform team says "that breaches our retention policy," who arbitrates? Conway's Law eats this for breakfast.
Right tools. Procurement processes were built for a SaaS world where you could trial a thing for 30 days, sign an MSA, and have it in production by quarter end. The probabilistic side doesn't behave that way. You can't really pilot an agent the way you pilot a campaign tool. You discover its edge cases in production. Most procurement functions are not set up for that.
Right governance. Scott named the governance gap directly, pointing out that adoption of AI use cases focused on compliance, brand standards and content validity is lagging the rest. The implication that follows is that closing that gap is mostly a question of process and accountability rather than tooling. Someone has to own the policy. Someone has to update it when the model changes under them, which it will, monthly.
Each of those is a structure question, a capability question, a process question. Those are the three axes I keep coming back to in the Martech Readiness Gap, and I'm becoming more convinced, not less, that they're the actual unit of work for the next two years.
The bullish case is real, with a footnote
Scott and Frans's framing of value engineering and context engineering is one of the more useful conceptual additions to the discipline this year. Both terms have started to show up in my client work and they hold up well. Also because strategic leaders and operators alike are trying to define the direction of their careers. The keynote will move the conversation forward, and that's worth a lot.
The footnote I'd add is on what the bullish MarOps case actually requires. MarOps will thrive if the organization gives MarOps the mandate to redesign procurement, governance and training, and if leadership accepts that 18 months of capability building precedes most of the value. Without those two ifs, MarOps becomes the team that gets handed an agent, a budget, and an impossible deadline, and burns out.
I've watched that movie before. So have you. The technology side of the keynote is in good hands with Scott and Frans. The organizational side is the bit I think a lot of us working on the people layer of this now need to go and write up properly.
What I'm watching for next
Two things I'd like to see in 2026, both of which are natural next steps from where the keynote left us.
The first is a credible maturity model for the trust ladder. Scott named three rungs (interpret, create-with-human, autonomous) and that taxonomy is useful as far as it goes. The next layer is progression criteria. What does it actually take to move a use case from rung two to rung three, beyond "trust"? Public data on what's happening to mid-career marketing roles would help here too. The keynote was bullish on MarOps in aggregate, but the sub-cuts are where the picture will sharpen.
The second is more conversations that lead with the organizational change alongside the platform feature. Scott's central point that AI is augmenting SaaS, not replacing it, is an organizational point as much as a technology one, and I think there's a lot of room to keep building it out from that angle.
If you watched the keynote and felt the same thread pulling at you, I'd be curious to hear about it. I'm working through this with clients at the moment, and I don't think anyone has the right answer yet, including me. The butterfly Scott and Frans described is a generous way to think about where we're heading. The chrysalis is where most of us are still working, and the organizational change inside it is the work I'd love to see more of us writing about openly.
Thank you to Scott Brinker and Frans Riemersma for an excellent report. If your team is in that exact spot where the tooling decision feels clear enough but the organizational redesign is fuzzy, that's the kind of work the Martech Workshop is built for.
Do you have any questions after reading this article?
Or need support with your Martech projects?
Discussion