The New Hybrid Roles AI Teams Actually Need

One thing I keep noticing in AI teams is that the clean old job boundaries make less and less sense.

The work is too entangled now.

Product decisions shape model behavior. Implementation constraints shape the UX. Prompt and tool choices shape onboarding quality. Eval design shapes whether the team even knows if the feature works.

So the teams that move well increasingly need people who can cross those seams.

Not because specialists stopped mattering. They still matter a lot. But because someone has to keep the whole system coherent while it is being built.

Quick definitions

Hybrid role: a role that spans two or more traditional functions, like PM + engineer, designer + engineer, or operator + researcher.
Seam: the boundary where one discipline hands off to another.
AI product: a product where model behavior, tool calling, uncertainty, or eval quality directly shape the user experience.
Operator: the human who steers models, workflows, prompts, tools, and review loops toward an outcome.

Why AI increases the value of hybrid people

In more traditional software teams, a bad handoff was annoying.

In AI teams, a bad handoff can quietly ruin the product.

If PM writes vague requirements, engineering may build the wrong workflow. If engineering ignores UX, the model may technically work while users still do not trust it. If design ignores model uncertainty, the interface may look polished while the experience falls apart in real use. If nobody owns evals, the team starts shipping vibes instead of evidence.

This is why AI increases the value of people who can translate across layers.

The core problem is no longer just “can we build it?”

It is:

what exactly are we building,
what part is deterministic versus probabilistic,
where does user trust come from,
what failure modes are acceptable,
how do we measure whether the thing helped at all?

Those are not purely PM questions. They are not purely engineering questions either.

They live in the middle.

The old stack had handoffs. The new stack has knots.

The old product org chart was easier to draw:

PM defines the requirement.
Design shapes the interface.
Engineering implements it.
Data or analytics tells you later whether it worked.

That picture was never fully true, but it was stable enough to function.

AI products make that sequence much messier.

Now the PM may need to understand schema constraints and confidence thresholds. The engineer may need to reason about whether the workflow is legible to a human. The designer may need to think about fallback states, explanation surfaces, and recovery paths when the model is uncertain. The person writing the prompt may effectively be shaping product behavior as much as the person writing the code.

That is why I think AI products produce not just faster teams, but stranger teams.

The work is more braided.

The hybrid roles I think matter most

There are a few combinations that seem especially important right now.

1. PM / engineer

This is probably the most obvious one.

AI products move quickly, but only if scope decisions are grounded in implementation reality.

A PM/engineer hybrid can:

define a narrower but more shippable first release,
see where a workflow should be constrained,
understand whether a model feature belongs in product or in tooling,
evaluate whether an implementation path is real or just demo-able.

This role is especially valuable in 0→1 work, where the biggest risk is not coding speed. It is building the wrong shape of system.

2. Designer / engineer

AI UX is full of awkward edge cases:

uncertainty,
partial output,
tool latency,
retries,
fallback behavior,
explainability.

Someone who can think visually and implement interaction details directly has a huge advantage here.

They do not need to hand-wave the hard part to another team. They can shape and test the interface where the weirdness actually lives.

I also think designers matter more in AI than a lot of engineering-heavy teams first assume.

Good design is not cosmetic polish after the system works. It is where trust, pacing, clarity, hierarchy, and recovery actually get expressed to a human being. If an AI product is technically impressive but confusing, stressful, or hard to interpret, users will abandon it long before they appreciate the underlying model quality.

3. Operator / builder

This is a newer role shape.

As agent workflows improve, there is increasing value in people who can run AI systems as production machinery:

choosing tools,
setting task boundaries,
managing context,
reviewing outputs,
designing escalation paths,
instrumenting what is actually happening.

This is part product sense, part systems thinking, part operations.

The person is not just “using AI.” They are managing a machine floor.

4. Strategist / implementer

There is also a quieter hybrid that matters a lot in enterprise or consulting contexts:

the person who can connect leadership goals to something buildable.

This person helps a team move from:

vague ambition,
to workflow definition,
to execution sequence,
to real deliverable.

That sounds simple, but it is often the missing layer.

Why this fits how I tend to work

This is also why the shape feels familiar to me.

Over time, I have ended up working across the full product stool rather than staying in only one lane.

I have done product management. I have done design. I have done engineering.

At Unyte, I worked as a Product Manager and took a legacy non-digital offering into SaaS product form. At Aterica, I worked as a Product Designer on patient and provider workflows. At SmartHalo and Esper, I was close to implementation, with software engineering roles that forced me to care about production reality rather than abstract roadmaps. In consulting and now AI product work, I keep sitting in the middle: translating a business need into flows, constraints, edge cases, implementation plans, and ultimately shipped product.

That has been the recurring pattern.

I learned a lot from design, and I still apply those lessons constantly even when I am operating as a PM or engineer.

Design taught me to care about how a user reads a screen, where uncertainty needs explanation, how a workflow earns trust, and how small interaction choices change whether a product feels coherent or brittle. That perspective carries directly into product work: better framing, clearer requirements, better defaults, better fallback behavior, and better judgment about what the user actually experiences versus what the team merely intended.

I tend to be most useful where the work is still ambiguous and somebody needs to make it more coherent.

Not by doing every specialist job at once forever, but by helping the system take shape early, tightening scope, and keeping the handoffs honest.

Hybrid does not mean chaotic

One thing worth saying clearly:

hybrid does not mean “one person should do everything.”

That is a bad reading.

The point of hybrid roles is not to replace great specialists. It is to reduce the failure that happens between specialists.

Good hybrid people make specialist teams better because they:

clarify the brief,
translate constraints,
surface tradeoffs earlier,
help the team decide what matters now versus later.

In the best case, they reduce organizational drag.

That is different from martyrdom.

Why this matters even more with agents

As AI agents get better, I think hybrid people become even more valuable, not less.

Why?

Because once one human can direct more implementation throughput, the bottleneck moves upward.

The scarce skill becomes:

picking the right target,
defining the right workflow,
knowing what to validate,
understanding what good output even means.

That is hybrid territory.

An agent can draft code, summarize documents, compare branches, and prepare options. But someone still has to determine:

which path is strategically right,
what quality bar matters,
what should be constrained,
what should be measured,
what risk is acceptable.

The more leverage the tools create, the more costly bad framing becomes.

So I do not think the AI era eliminates hybrid roles.

I think it reveals that they were undernamed all along.

My practical takeaway

The new AI org chart is not just PM, design, engineering, and data sitting in separate columns.

It increasingly needs bridge people:

people who can think in user outcomes and system constraints at once,
people who can turn strategy into workflow,
people who can spot when a handoff is hiding a bad assumption,
people who can use AI not just as output generation, but as part of a real product operating model.

That is the kind of role I am drawn to most.

I like the messy middle. I like shaping the first credible version. I like finding the right scope. I like turning ambiguity into product structure.

And in AI, that combination feels especially practical.

Related notes:

Best,
Oli
April 26, 2026