I didn’t arrive at AI from the technology side or the research side. I arrived from the seam between them, which is where I’ve spent most of my career.
Honestly, that seam goes back much further. I grew up both intrigued and irritated by technology: Commodore 64, ColecoVision, Nintendo, Compaq—all before dial-up entered my life. Later, I explored computer engineering while taking art classes, and eventually moved into new media.
The combination made sense to me even when the labels didn’t. I liked understanding how something worked. I also cared about what it looked like, how it felt to use, and whether it helped a person do something they couldn’t do before.
By the time I entered market research in 2005, I was managing data for a large quantitative tracking program using SPSS and WinCross while also traveling for qualitative research: in-home ethnographies, focus groups, campaign testing, store-concept evaluation, and other projects that let me watch people interact with products, spaces, media, and technology in real life.
Then I had to bring it all together. What did people say? What did they actually do? What did the numbers show? What mattered to the client? And how could I use the visual and reporting tools available at the time to make the answer clear?
That was one job. Technically.
Later, at Delahaye and then Cision, I spent more than a decade working in custom media analysis for major global organizations. I watched bespoke analytical work become increasingly connected to an evolving technology stack. The company acquired and integrated new platforms and capabilities; the tools changed, the data changed, and the expectations changed with them.
I wasn’t simply clicking buttons in a finished system. I had to understand the data underneath it, learn what each platform could and couldn’t do, catch the gap between a technical output and a defensible insight, provide feedback, and invent the occasional MacGyver-level workaround when the work still had to get out the door.
Seriously. Fist bumps to all my colleagues who went through the ’07–’18—and beyond—tech and data growing pains.
That experience is part of why I was later able to provide useful direction on internal AI-enabled products and workflows. I understood the research process, the client need, the data, and the practical reality of using technology under deadline. I’d already lived through multiple versions of the promise that a new platform would make everything seamless.
Sometimes the technology made the work much better. It almost never made the work ownerless.
Roles don’t just change. They accumulate.
In a single week, someone in insights may be an analyst, researcher, observer, editor, storyteller, project manager, client advisor, quality-control lead, and now AI workflow designer.
None of those responsibilities is absurd on its own. Many naturally belong together. The problem is accumulation without subtraction.
The research still needs to be sound. The data still needs to be checked. The client still needs an answer. The presentation still needs a story. The team still needs guidance. Then the same person is expected to identify automation opportunities, test tools, write instructions, document edge cases, validate outputs, track usage, adapt to model changes, and help everyone else understand the system.
That isn’t simply “using AI.” It’s process design, change management, quality assurance, risk management, and technical enablement layered onto an existing job.
A specialist in what, exactly?
This is the question I’ve struggled with throughout my career. What am I a subject-matter expert in?
Research? Data? Media intelligence? Technology platforms? Reporting? Data visualization? Client strategy? Workflow design? AI automation?
The honest answer is that I have needed to know all of them—sometimes at the same time. It can feel less like “jack of all trades, master of none” and more like “jack of all trades, expected to master all of them.”
That makes it difficult to choose one clean label, especially in a professional culture that wants expertise to fit inside a job title, a software certification, or a single functional lane. But the work itself has never respected those boundaries. You can’t evaluate an output without understanding the data. You can’t turn the data into an insight without understanding the research question. You can’t make that insight useful without understanding the audience. And you can’t automate the process responsibly without understanding every handoff in between.
That kind of expertise can look broad from the outside because it is built across a system rather than confined to one task. It is also why piling on one more responsibility is so easy: the person who can see the whole process is often the person asked—or quietly expected—to hold more of it together.
What if nobody assigned the new job?
Much of the AI and automation work I’ve been doing wasn’t formally assigned.
No one handed me a roadmap and said: map this process, find the weak points, test where AI can help, build a prototype, document what works, and figure out how to make it repeatable.
I did it because I’m curious. I’m driven. I like knowing how things work, making them work better, and solving problems that keep getting in the way. If I can see a way to make a process more useful or efficient, I have a hard time pretending I didn’t see it.
That curiosity has created real value throughout my career. It also takes real time.
This is where the current push for AI adoption gets strange. Employees know—explicitly or implicitly—that adaptability and AI fluency are being judged. But the work of becoming fluent often isn’t assigned, scoped, protected, or recognized. People explore between deliverables, after meetings, or on their own time. They absorb the learning curve and the failed experiments along with their existing responsibilities.
And, at least from where I sit, the push is often stronger than the modeling. Employees are encouraged to transform their workflows, while many leaders aren’t visibly using AI to rethink their own work in the same hands-on way.
That doesn’t make leadership anti-AI. Senior roles involve different responsibilities, risks, and constraints. But it does create a gap: the people with the least authority to redesign the operating model may be doing the most experimentation inside it.
Curiosity is an asset. It isn’t free labor.
I love experimenting with AI. It has helped me explore analytical possibilities, build prototypes, ask better questions, and see relationships I might not have found as quickly on my own.
But enthusiasm doesn’t create capacity.
If a task that took four hours now takes two, the response is rarely, “Great—use the remaining time to think more deeply.” More often, it’s, “Great—here are two more things.” The efficiency becomes the new baseline almost immediately, while the work of creating and maintaining that efficiency remains mostly invisible.
Reliable automation still requires someone to understand the process, data, dependencies, failure points, review steps, and downstream consequences. It requires someone to notice when a result is mathematically correct but contextually misleading. It requires someone to update the workflow when the source, model, policy, metric, or business need changes.
The work may become faster. It doesn’t become ownerless.
So when did one job become five?
Probably long before AI arrived. AI is simply making the accumulation harder to ignore.
The opportunity isn’t to ask the most curious employees to quietly absorb one more discipline. It’s to recognize the work they’re already doing, decide what should come off their plates, and give them the time and authority to build something other people can actually depend on.
Further reading
- Cision’s history — Cision
- WinCross Desktop — The Analytical Group