Customer experience teams are generally pretty good at finding problems. I've been there myself in the past. We've run surveys, analyzed calls and complaints, mapped journeys, conducted research, built dashboards, identified pain points, and presented findings to leaders across the company.
At some point though, someone has to actually change something.
That is where many CX programs say their roles end. The problem gets handed to product, technology, operations, service, marketing, or some combination of all five. The CX team explains what it found, makes a recommendation, and hopes the issue survives prioritization, budget discussions, governance, architecture reviews, competing roadmaps, and everything else that can separate an identified customer problem from a real fix. Another meeting they survived.
I think CX needs a role designed to close that gap. I have led that team, and it's a game-changer. I call it the CX engineer.
I have been talking about this role for a few years now because I think it represents where the discipline needs to go next. As companies bring together more customer data, deploy AI, automate workflows, and connect more systems, identifying customer problems will get easier.
As a result, I think the day-to-day work is about turning what we know into a meaningful change in how the company operates.
This article covers:
- What the CX engineer role is, what it is not and what those who hold the role need to lead on.
- Why intervention is the CX engineer's USP and how they combine knowledge in technology, data, AI, product, workflow, and measurement to drive action.
- Why the days are numbered for a CX organization that primarily produces insight then hands recommendations to the rest of the business.
What a CX engineer does
A strong CX engineer should be able to do five things really well.
1) Diagnose a customer problem
That means getting beyond a survey score or complaint category and understanding what is actually happening. Who is affected? How often? Under what conditions? What does the customer experience? What is the business impact?
2) Understand the workflow and systems underneath the problem
Persistent customer problems are rarely caused by one bad screen or an employee who needs more training. They often sit inside policies, handoffs, data gaps, incentives, disconnected platforms, manual workarounds, or decisions made somewhere else in the organization.
3) Design a better way for the work to happen
Sometimes that means changing a workflow. Sometimes it means removing a step, changing a policy, connecting systems, introducing automation, giving an employee better information, or using AI to make a decision earlier.
4) Get the solution far enough toward implementation that it has a real chance of happening
A recommendation sitting in PowerPoint is still a recommendation. A prototype, defined workflow, tested automation, clear set of requirements, or working proof of concept creates momentum and gives the implementation teams something concrete to work from, let alone get excited about.
5) The CX engineer should be able to measure whether the intervention worked
Did customer effort decline? Did repeat contacts fall? Did retention improve? Did complaints decrease? Did the process get faster? Did revenue, cost, risk, or employee productivity change?
The work should end with an outcome and should never end with an insight.
What the CX engineer is not
As important as defining what the role is, I think we should equally define what it is not. Put simply, I would not expect one person to do everything.
A CX engineer should not be expected to build production-grade software alone, create complex enterprise data pipelines, design enterprise architecture, perform advanced statistical modeling, and lead organizational change across multiple business units.
No company is going to find one person who is world-class at all of that, and trying to design the role that way would make it impossible to hire.
The CX engineer owns the customer problem through intervention. They diagnose it, understand what is causing it, design a better approach, prototype where possible, coordinate implementation, and measure what happens afterward.
They know enough about technology, data, AI, product, workflow, and measurement to work effectively across those areas. They do not need to be the deepest technical expert in each one. Their value comes from connecting customer reality with the people and systems capable of changing it.
CX engineering is bigger than one role
I also see CX engineering as a multidisciplinary capability. In many companies, one CX engineer will not be enough. Harder problems require several types of expertise working together against the same customer outcome.
The CX engineer owns the problem through intervention.
- A CX data scientist or analyst finds patterns, models behavior, performs deeper analysis, and helps determine whether the intervention changed anything.
- A CX systems architect understands how platforms, APIs, AI agents, workflows, and enterprise systems should connect.
- A CX data architect or data engineer makes sure the customer and operational data required to understand and solve the problem can actually move, join, and be trusted.
Product and design capabilities may also sit on the team or come from elsewhere, depending on how much the intervention changes an interface, product, or service.
In a smaller company, two or three people might cover all of this, as challenging as that might be.
In a large enterprise, I could easily see 10 or more individuals in a CX engineering team working against a portfolio of high-value customer problems.
Frankly, I care less about the exact team structure than what the team is accountable for. At the end of the day, the work should be organized around customer problems that need to be solved, not around producing more CX activity.
How a CX engineer role works in practice
At a large financial institution I recently worked for, I led a team of roughly 50 people that combined many of these capabilities with more traditional CX skills.
We had research, analytics, journey work, data, technology, measurement, and other expertise across the team. What kept us focused was a simple set of questions we came back to constantly:
What customer problem are we fixing, what is causing it, what are we changing, and did it work?
That changes the way a CX organization spends its time. You spend less energy debating whether NPS moved two points and more time understanding what drove a customer problem, what can be changed, and whether the change produced a better outcome.
Surveys, journey maps, research, dashboards, and measurement still have a role. They become inputs into the work rather than the work itself. The important point is that the center of gravity shifts toward intervention.
Solving the longstanding execution problem in CX
CX teams can identify pain. They can quantify frustration. They can often tell the company exactly where customers are struggling. Authority and technical capability to change the systems creating those problems usually sit somewhere else. Thankfully, AI is shining a lot of daylight on this gap.
We can now analyze huge volumes of customer conversations, find patterns across channels, generate prototypes, automate workflows, test new approaches, and build functional proofs of concept much faster than we could even a few years ago. All of this changes what companies should expect from a CX function.
A CX organization that primarily produces insight and hands recommendations to the rest of the business will become less valuable over time. We are already seeing this manifest. The stronger teams will build enough technical and operating capability to participate directly in changing the experience.
Now, this doesn't mean every CX professional needs to become an engineer. Research, design, analytics, measurement, strategy, and organizational change all remain important.
But CX leaders should start looking carefully at the makeup of their teams. They need to know, "How many people can identify a customer problem?" and, "How many can actually help fix one?"
I think the gap between those two answers will tell you a lot about where CX goes next. Here's a challenge: if you're leading a CX team, whether two people or 20, how would you honestly answer these questions?
Quick links
- The forward deployed engineer: A role designed for CX in the age of AI
- Fragmented organizational cognition is why CX programs stall
- CX has to move beyond closed loop feedback