Fluid Disciplines Deserve Fluid Roles

“I am a designer.”

I heard that sentence over and over at the California College of the Arts MDes graduation today.

It made me wonder: what does being a designer actually mean now?

Design engineer or designer PM.

But what if those aren’t the two career paths? What if they’re simply two examples of something bigger happening to the discipline?

Designer careers now have a new binary. The popular path is design engineering. The other, still without a clean title, is the shift into product management.

Some designers want to take the design engineering path. They are technical and excited by the newly enabled programming skill. David Eisner’s new book, Product Design Engineering, pushes this idea hard. He argues that designers who can’t code are at a disadvantage as teams prioritize speed and tighter collaboration.

On the other side, Jason Cyr recently asked his LinkedIn network to help identify designers who’d moved from design into PM. Another emerging trend. On my past teams, I saw designers move into PM roles just as often as designers moved into design engineering roles.

I dislike binary perspectives. Not everything is black and white.

What about the happy middle? What about the designers who don’t want either of those? They might want to work in design sales, become designer TPMs, or simply remain designers with more leverage, more impact, and more interesting problems, and who now wonder: what’s my career actually supposed to look like?

My unpopular opinion: forget the title. Just do what you’re passionate about. Make up a title if you have to. I brought this exact take to Peter Merholz and Jesse James Garrett on their podcast, Finding Our Way. They pushed back. Designers still need a title. What about the people job hunting? They asked. How does anyone find you without one? That’s the reality. So yes, we retreat to our old titles when we need to be found.

Admittedly, there’s a mismatch right now. Designer career growth is still the traditional ladder. Junior to senior, eventually to principal.

What if we stop thinking about specific skills and start thinking about capabilities?

AI has changed the equation. Everyone’s toolkit expanded overnight. A designer can now generate working prototypes, write documentation, think through systems design, optimize GTM strategy, work sales angles, and yes, ship code. Not because they are becoming an engineer, a salesperson, or a PM, but because their ability to engage with the problem has expanded.

This creates space. A lot of space. Design engineering and designer PM are just two options. There are others.

The designer who becomes a designer-strategist focused on GTM. Not a PM. But someone who understands how products get to market. Someone who can talk to sales about what matters, to marketing about positioning, to the product team about differentiation. Their design work now includes the full context. They make better design decisions because they understand the business.

Or the designer who becomes a system designer. Not writing code daily. But understanding complex organizational problems through a design lens. How do teams actually work? What information do they need? How do systems create friction? This is where design thinking meets ops. Using the same skills you’d use to map a user journey to map how work actually flows through an organization.

Or design sales. The one who understands design deeply enough to help potential customers see value. To translate technical complexity into clarity. Not selling, but enabling customers to understand what they’re buying.

Or the designer who becomes the ops person, not by accident, not because they couldn’t hack it as a PM or engineer, but because they’re the one who actually enjoys making the system work. Who finds the friction and removes it.

These aren’t new disciplines. They’re examples of fluid roles built around capabilities rather than job descriptions. The point isn’t to create another set of job titles. It’s to create more ways for designers to apply their capabilities.

What becomes possible is a different kind of individual contributor. Rotated between key initiatives. Not embedded in one team. Brought in for the projects that need their perspective. Strategic. Valuable. Moving.

The Fluid IC isn’t necessarily:

• the best designer on a single team

• a strategist

• a manager without reports

• a specialist with a fancy title

They’re someone whose expertise becomes portable across problems.

Not every designer wants to be a Fluid IC. Some work best in a deep domain area, with constrained rotation within that domain. That's not new, and it can work well alongside a Fluid IC model. I go deeper into who is a good fit, what we expect from them, and how we're actually building this in Inside the Fluid IC, How We're Actually Building This.

Fluid IC group. You can call it a team, a group, a pod, whatever. Here’s how it works: a group of Fluid ICs, experienced product designers and service designers, takes on wicked design problems. Sometimes that’s a special project the executive team needs immediately. Sometimes it’s an operational problem for the team. They roll up their sleeves, dive into the weeds, and sort it out. We haven’t landed on a name for the group yet.

For the organization: access to high-context expertise without disrupting existing teams. For the individual: more agency, breadth, and exposure without abandoning the IC path.

How does it benefit the org? Urgent product needs get addressed immediately. No disruption to the day-to-day product development already on the roadmap. You don’t have to pull designers off their current projects to put out fires.

How does it benefit the individuals? The group is extremely flexible. People take on projects that align with their strengths and interests. A Fluid IC might take on an operational task when they’re not deep in a design challenge. This flexible way of working supports a career path. More agency. More ownership. More accountability.

I am excited about the experiment because, from an ops perspective, it creates an opportunity to fulfill operational requests without expanding headcount. There are many arguments for why an org should build out an operations team. But when you start with an ops team of one, this formation provides much-needed operational support.

Instead of hiring a dedicated design operations person, what if you rotated a designer passionate about a specific workflow to help update and modernize it? That’s ops work. Have them tackle a tough ops problem for a quarter, then move back to a strategic project. They’ve felt the operations pain firsthand, so they bring systems thinking and a real sense of the constraints. And they solve it differently, because they’re doing it as a designer, not a career ops specialist.

The traditional career path tried to make designers choose one linear track. I’ve always wanted to see development as a spectrum, two-dimensional. I’ve long advocated leaving a portion of career development for ICs to decide. Not deep specialist or generalist, forced into one lane. The middle path says neither. Be strategic. Be deep in design. Be capable of moving into whatever problem matters most right now.

Right now, we’re losing people. Good designers who don’t want to be PMs. Who don’t want to become design engineers. But who also don’t want to stay in the same lane forever. They want growth. They want impact. They want to understand the whole system their work sits inside.

We know how to hire designers for specific domains. But creating roles for designers who move between problems, who work across functions, who use AI to expand their own capability set? That’s unfamiliar territory. They are not equivalent to a design strategist who tackles strategic problems; these designers are fluent not only in strategic system problems, but also in tactical challenges.

It requires thinking differently about how work gets organized. About what careers can look like. About what value looks like when it doesn’t fit a job title.

The good news: AI has made this possible. Your toolkit is bigger. You can actually deliver in these middle roles now. It’s not theoretical anymore.

The question is whether organizations will build the career paths or keep pushing designers toward PM or engineer, leaving the middle empty.

To the CCA grads who kept saying “I am a designer” today: that’s still true. It’ll just look different than it did for the generation before you. You won’t have to choose between shipping code and owning a roadmap. The middle is possible, and right now, at my own company, we’re building it in real time.

The middle isn’t a career path. It’s a way of working.