The "AI is blurring roles" and "[role] is dead" discourse occurring across a thousand LinkedIn posts simply restates an issue has been apparent for decades, but companies have been unwilling to address: in knowledge work, the role was always the wrong unit of organization.

Until we move past it, even with new capabilities, we'll be stuck in old ways of thinking about work.

I believe a superior model of organization features two prongs:

• Skills and their associated activities (the true organizational atoms)
• Teams (which is how skills, through their practitioners, are realized in practice)

This became clear to me years ago as I shifted from working in design consulting to working in-house. To design good software requires a wide variety of skills, more than any individual can excel at:

But product squads typically had single designers embedded within them. The unfortunate organizational hack was staffing Product Designers who were strong in visual and interaction design, but weak in everything else. And this meant software quality suffered–it may look good, but it didn't work all that well.

If you have a team of designers, you can ensure a broad complement of skills:

The TL (Team Lead), SPD (Staff Product Designer), and PD (Product Designer) are technically in the same role (Product Designer), just different levels of experience. The blocks below them show a 1-5 rating across a set of skills (like those listed in the image before). Even though each of them occupies the same role, their skills are quite different, and that's okay. We need to move away from role essentialism and embrace that roles, like people, exist on a spectrum.

You may still have specialists, such as the Content Designer (CD), who is there to ensure expertise in Writing.

When you "add" the skills across the team, you get a robust complement of capabilities, able to address any software design challenge.

Skills + Team organization

Now, imagine instead of a design team of 6, it's a product development team of 6. Typically this would mean 1 product manager, 1 designer, and 4 software engineers.

But, if instead of organizing by role, we organized by skill? What are the [10? 15? 20?] skills necessary for this team to competently build whatever is expected of it? And then, what skills do our people have, and how can we groups those people to address the necessary complement?

This isn't me just talking out of my ass. Two recent pieces from folks 'in the field' show how they're moving in this direction.

Clay Parker Jones, an organization designer at AirBNB, wrote a thoughtful (and somewhat wonky) piece on The End of Role Clarity, showing the shortcomings of roles-based thinking, advocating for the primacy of "team clarity," which is sorely lacking in most organizations.

Changying (Z) Zheng, in her case study of transitioning Cloudflare's design team to AI tooling, has a set of takeaways from her experience:

What’s dying:

• “That’s not my job” as a defense
• Role-based tool ownership (designers own Figma, engineers own code)
• Handoff-based workflows
• Execution skill as the primary differentiator

What’s transforming:

• Job titles (from “designer” to “builder,” from “PM” to “product person”)
• Career ladders (skill-based, not role-based)
• Collaboration models (everyone builds, everyone thinks strategically)
• Value creation (judgment over execution)

Granted, this is a single data point, but the direction it suggests warrants grappling with.

But, if it were only this straightforward

The shortcomings of a role-based approach have been known for decades. Nevertheless, it persists.

Why have we stuck with roles? I see three reasons.

1. Roles are People-Shaped

What I believe is the most salient, yet least explored, reason, is rooted in human psychology and cognitive bias: roles are 'people-shaped,' easy to picture and understand. When you read "UX Researcher", "Product Manager," "Data Scientist," you can't help but picture the person doing the work. Though, it's crucial to understand, what you imagine is, by definition, a stereotype.

Skills are abstract. When you read "interaction design," "UX writing," "product discovery," "systems architecture," "quality engineering," it takes significant cognitive effort to connect that with work.

Work teams are variable and complex. They can have a range of people. They have different mandates, and so the skills they need will vary from team-to-team. So the idea of a 'team' is fuzzy and indistinct.

2. Roles fit with bureaucratic practices

It's important to acknowledge, though, that while roles are 'people-shaped', they are not people. They are a generic take on what a person could do. They remove the humanity, individuality, and idiosyncrasy, replacing it with an approximate box that can be manipulated systemically.

This is the second reason: bureaucracy loves roles. As organizations scale, they use heuristics to wrangle complexity, and so individuals are no longer seen as people, but titles on org charts. This enables the (bureaucratic) benefit of fungibility—resources (aka people) can be moved around as needed, with some expectation that their title presupposes their capability. But this fungibility requires stricter role definition (so you can move people around without having to individually assess their appropriateness), which in turn means we need to define more roles as the work gets more complicated.

2a. Related—Roles are easier to hire

There's an obvious problem with abolishing roles, and that's—how do you hire? If I post a job for "Practitioner" or "Builder" or "Technologist," I'll either get zero or infinite responses. I would love to post, "I'm looking for someone competent in these 5-10 skills," but that's... just not how things are done. The amount of industrial and even societal change necessary to make this happen is enormous. Roles, and their job titles, provide a shorthand for the kind of skills you're seeking.

3. Roles provide my identity

There's an uncomfortable irony at work: while roles are not people, people's identity is often bound up with their role. Designers go to school to study design, look for design jobs, attend design conferences, use design tools, and may join professional design associations. All of this reifies ones sense of being a Designer.

And then things get tribal—the world becomes divided between Designers and Not Designers. Designers have shared language, experience, values. And, many allow the role to define who they are, willingly blunting their own individuality in favor of conforming to expectations. This is why you hear designers complain that "Product" is not giving them what they need, or "Engineering" said "no."

Unlocking potential

The cynic in me foresees that organizations will be unable to embrace skills + teams, much like they haven't been able to adopt contemporary product development practices. For some, this will be welcomed, as it means things won't change much, and they can operate as they always have.

The optimist in me hopes that the radical opportunity of this new technology finally overcomes the resistance to better ways of organizing, seeing beyond the essentialism of generic roles in favor of recognizing everyone's distinct spectrum of practice.

Need help finding focus?

I've started working with clients who are thinking through how their organizations can support enabling these new ways of working. If you need that kind of Thought Partnership, don't hesitate to reach out.