AI is not a department

Why research leaders cannot outsource this one

For months, I have been watching the same pattern play out across LinkedIn, Medium, and Substack. An individual contributor on a research team learns **Cursor or [Claude Code](http://claude.ai)**. They unblock a two year backlog in an afternoon. They build an internal agent that replaces a week of synthesis work. They write a thoughtful post about it. The team lead shares the post. The org writes a series about it. The company calls itself AI forward.

Meanwhile, over on the Design, PM and engineering side, the conversation sounds completely different. Engineers talk about agentic workflows and what Claude Code has changed about how they architect systems. Designers are quietly writing production code. The conversation is about the shape of the work, not the adoption of a tool.

The gap between these two conversations is not about tool fluency. It is about how the function is being led.

Diagram showing AI as one of five equal tools inside a research function, with a separate “AI department” box crossed out.

The victory lap gap

In research, the victory lap is: We used Claude or Cursor. In product and engineering, the victory lap is about what the function now looks like, what the team structure now is, and what shipped because of the change.

• One is a tool adoption story.
• The other is a function redesign story.

Only one of these is the job of a leader.

The gaps of AI as a department

Here is what AI as a department looks like in a research org today: someone gets the title Staff Researcher, AI Initiative or AI Enablement Lead. A builder role appears, undefined. The team runs setup sessions. There is a library of custom agents.

I am not arguing against the utility of these things. I am arguing that a head of research who thinks the job is done here has misunderstood the job. This pattern creates five specific gaps:

1. Two track research: The AI track does showcase projects; the normal track does the roadmap. They do not integrate, leaving the function unchanged in its deliverables.
2. Tool adoption as end state: Success is measured by we now use Cursor rather than our research is answering bigger questions. The easy metric wins; the hard one is dropped.
3. Depreciating infrastructure: Custom MCP and bespoke tooling built to bridge Qualtrics to Snowflake. This is platform work that will likely be obsolete in 18 months when native AI features catch up.
4. Rigor as afterthought: Evaluation frameworks get bolted on reactively once output quality drops. A function designed from scratch would start from rigor.
5. Role inflation without clarity: Builder emerges as a shadow role because existing roles haven’t absorbed new capabilities. This is a sign that leadership hasn’t redesigned the function.

Root cause: Treating AI as a department inside the research function instead of treating it as a tool the research function uses.

Why hiring an IC doesn’t fix this

The usual response is to hire or promote a senior IC to lead AI adoption. This solves the problem of our researchers don’t know how to use these tools, but it ignores the real problem: our research function is not designed for how work gets done now.

The first is a training problem. The second is a leadership problem. You cannot delegate a leadership problem to an IC. Only the head of research can answer:

• What work should we stop doing?
• What work should we start doing?
• How should we be organized?
• What should our relationship with product, design and engineering become?

Systems thinking requires hands in the system

You cannot redesign a function around the tools you do not use. You will make the wrong decision about the roles and workflow based on what a senior IC tells you, which is not the same as what works for a function.

I am not saying every head of research needs to become an engineer. I am saying you need to:

• Use Claude Code to draft an analysis plan.
• Set up an MCP connection and watch it break.
• Experience prompt fatigue and the discomfort of using these tools badly.

Systems thinking requires hands in the system. You cannot do this from a distance or by being briefed.

What a redesigned function looks like

I don’t have the full answer, but I know the shape of it:

• Rigor as the organizing principle: It starts with the question: What does credible research look like when an agent wrote the analysis?
• Speed as a consequence, not a goal: Chasing speed directly produces Research Slop. Speed should be what you get when the function is well designed.
• Collapsed role boundaries: If everyone has the same toolkit, the function needs to be designed around new boundaries, not old ones with a builder role bolted on.
• Shared context over shared tools: The hard problem is that everyone now has enough context on each other’s work that coordination costs have changed.
• New success metrics: Measuring the function by what research made possible (decisions made with confidence), not by AI tools used or studies shipped.

The short version

AI is a tool, like surveys or SQL. You do not hire a Head of Dashboard. You hire a head of research who uses dashboards and hold them accountable for what the function produces.

If your research leader is not using Claude Code every day and rethinking what the function should become, you do not have an AI strategy. You have an IC with a good side project and a leader who hasn’t noticed that the job description changed.

The tools changed. The job, redesigning the function to meet the moment, remains the same.