Mapping the Modern Learning Profession

A few months ago, I wrote about why I decided to go back to school for a graduate degree in Learning Design and Technology. This came after spending over 25 years working across technical content, customer education, product strategy, platforms, enablement, and a handful of other areas. But sitting right under that decision was a surprisingly basic question: what exactly is it that I do?
That question has kind of haunted me for most of my career. Depending on the company, the team, or the project, I could reasonably describe parts of my work as technical content, customer education, learning, product management, content strategy, enablement, knowledge systems, or learning architecture. None of those descriptions are wrong, but none of them tell the whole story either.
For a long time, I figured that ambiguity was just my own doing. I had hopped around enough adjacent fields that maybe I was just hard to put in a box. But the deeper I get into learning design, and the more people I talk to in this space, the more I realize this isn't just a me problem.
The learning profession has gotten tough to describe because the field itself has blown wide open.
Instructional design is still a big piece of the puzzle, but now it sits right alongside learning design, learning experience design, curriculum design, learning architecture, learning engineering, customer education, developer education, enablement, knowledge management, content strategy, learning technology, analytics, certification, and workforce capability. On top of all that, AI is adding a whole new layer, creating fresh work around adaptive experiences, agent orchestration, AI-assisted content, evaluation, and knowledge systems.
The terminology is messy because the work itself is messy.
The Same Questions Keep Popping Up
I started noticing the exact same debates happening over and over on LinkedIn and Reddit. Teachers trying to figure out where their skills fit outside the classroom. Instructional designers asking if "learning experience design" is actually any different or just a buzzword. People trying to figure out if customer education belongs in L&D, Marketing, or Product. And then there are the job postings that basically ask one person to be an instructional designer, content strategist, facilitator, project manager, video editor, LMS admin, data analyst, AI expert, and change manager all at once.
Someone posted a job description like that recently and called it a search for a learning "unicorn." That hit home because it points out two things. First, some companies really are trying to squeeze three full-time jobs into one salary. But second, a lot of organizations are just genuinely struggling to write a job description for work that spans several different fields.
That kind of cross-disciplinary work is becoming the norm.
A technical writer today isn't just typing out documentation. They might be setting up structured knowledge that powers support systems, search, RAG pipelines, copilots, and AI agents. A learning designer might be building simulations, adaptive paths, AI tutors, and product workflows. A customer education leader might run onboarding, certification, community, and enablement all at once.
These aren't neat little boxes. They're overlapping webs of work.
Looking at a Career as a Map, Not a Ladder
Seeing things that way started changing how I looked at my own path. Looking backward, my progression feels less like climbing a ladder and a lot more like filling in a map.
Early on, I worked in customer support and technical content, helping people solve immediate problems and turning those solutions into reusable articles. From there, I moved deeper into documentation and developer education. Over time, the work grew from individual articles into bigger end-to-end experiences involving code samples, step-by-step guides, websites, and learning portals.
Later, that scope stretched even further into certification, skills assessments, hands-on labs, platforms, localization, analytics, and governance. At other companies, I managed help content, customer education, digital experiences, publishing pipelines, and content operations. Eventually, the work grew to encompass broader cloud architecture guidance, reliability, and helping customers navigate really complex technical choices.
The job titles kept changing, but the core challenge was always the exact same: how do we help people understand complex topics, build real skills, make better choices, succeed with technology, or even generate revenue?
That’s a big part of why I signed up for the Master's program in Learning Design and Technology at George Mason. I wanted a solid theoretical toolkit for work I’d already been doing in the trenches for years. I also wanted to see where my experience fit in a field whose boundaries were clearly way bigger than I originally thought.
The deeper I dug, the more I realized job titles only tell a tiny fraction of the story.
"Instructional Designer" tells you something, but not much. One ID might spend their whole day building traditional e-learning courses. Another might spend all their time on performance support, simulations, or product education. A Learning Designer at Company A might be doing the exact same work as an Instructional Designer at Company B.
The title is fine, but the actual day-to-day work underneath it is what matters.
Mapping the Profession
Eventually, I needed to visualize this. Instead of trying to invent one perfect taxonomy, what if I just mapped out the profession in a way that showed all the overlaps and connections?
That turned into a project I call the Learning Profession Explorer.

The current version maps out over 40 roles across six broad buckets: Leadership and Executive Roles, Strategy and Systems, Instruction and Experience Design, Technology and Data, Content and Delivery, and Enablement and Audience Focus.
These categories are intentionally wide open. They aren't meant to build rigid walls. In fact, most roles naturally spill across multiple areas.
A Learning Engineer might live in Technology and Data, but they're probably deep in experience design too. Developer Education might lean toward Content and Delivery, but organizationally it could sit in Product, Engineering, Marketing, or Developer Relations. Customer Education can look like pure learning design at one company and sales enablement at another.
That overlap isn't a bug in the model. It's the whole reason I built it. The goal isn't to say, "You belong in this box and nowhere else." It's to make the relationships between these roles easier to see.
The interactive version lets you click on a role to see its core responsibilities, deliverables, skills, tools, and where it usually sits in a company. You can compare roles side by side, or view the map through different filters like target audience, role type, or the style of work.
Filtering turned out to be critical because a job title by itself still leaves out context. Someone might want to know which roles focus purely on external customers. Someone else might be looking for technical or AI-heavy paths. A teacher might want to see where their current skill set translates best.

Why the Teacher Transition Discussion Needs a Refresh
Teachers are a great example of why this kind of visual mapping helps.
I see so many teachers asking how to transition into corporate or tech careers, and the advice online almost immediately funneling them into one bucket: instructional design.
That perspective is way too narrow.
Teachers bring heavy-duty skills that show up all over the learning world: lesson planning, facilitation, assessment, learner support, differentiation, communication, coaching, curriculum design, and community management. Those capabilities are valuable in instructional design, sure, but also in learning design, customer education, community management, curriculum strategy, and enablement.
Now, transferable skills don't mean you automatically skip the line for every role. A teacher wanting to get into learning engineering will need to build some serious tech skills. Someone heading into customer education needs to learn SaaS mechanics, product metrics, and customer success. Moving into learning architecture requires a grasp of enterprise systems, governance, and platforms.
But looking at the field this way leads to a much better conversation than just saying, "Teachers become instructional designers." The real question is: where do your current strengths overlap with the map, and what specific gaps do you need to bridge?
AI Isn't a Role, It's a Layer
AI gave me a fun design puzzle while I was building the map.
At first, it felt easy to just throw an "AI" category right alongside the others. But the more I thought about it, the less sense that made. AI isn't turning into a separate silo in the learning department. It's becoming part of how all the work gets done.
So instead of a new bucket, the map treats AI and agentic workflows as a foundational layer that cuts across every single category: design, create, orchestrate, govern, and adopt.
That feels a lot closer to reality.
An AI Learning Experience Designer might build intelligent tutors, adaptive paths, or coaching simulations. An AI Content Designer might focus on prompt workflows, synthetic content, and automated generation. A Technical Writer is designing knowledge bases so AI agents can parse them easily. A Learning Engineer is busy wiring AI APIs into existing platforms. An AI Enablement Lead focuses on helping teams actually adopt these tools effectively.
The tools are shiny and new, but the underlying challenges aren't. We're still trying to help people understand complex ideas, perform better, access information, and build skills. We just have a much bigger, faster set of systems to do it with.
The Map Will Keep Changing (And That's the Point)
If there's one thing I'm sure of after building this, it's that there is no such thing as a final, perfect taxonomy for this work.
Companies will keep using titles however they want. New roles will crop up. Existing roles will absorb new tech. Some titles on this map will probably merge, and others will split off.
And that's completely fine.
The most useful questions usually aren't "What is my exact title?" They're: "Who am I helping? What problem am I solving? What am I building? What skills does this take? What systems am I connecting to? What business outcome do I own?"
Those questions tell you infinitely more about your career than a title on a business card.
The Learning Profession Explorer has about 40 roles in it right now, and I fully expect that number to shift. It's an ongoing experiment. I'm sure I missed some roles, put a few in the wrong spot, or grouped things that should be separate.
Honestly, that's what makes it fun.
I didn't build this map because I have the entire learning industry figured out. I built it because I kept running into people asking the exact same questions I’ve been asking myself for two decades, and I wanted a visual tool to help us all figure out the answers together.
Maybe the confusion around titles isn't a sign that the learning field lacks structure. Maybe it's just a sign that the work is evolving fast.
For years, it used to bug me that I couldn't summarize my career in a simple, tidy title. I look at it differently now. The issue was never that my path was weird. The issue was that our industry's old categories were never very good at describing work that sits at the intersection of content, learning, technology, product, systems, and enablement.
Which, as it turns out, is where most of the exciting work is happening anyway.
If you want to check out the current build of the Learning Profession Explorer, it's live in my portfolio. It's constantly changing, so I'd love to hear what you think is missing, what needs to move, or what new roles you're seeing out in the wild. If this map looks completely different a year from now, that just means it's doing its job.

