From Instructional Design to Learning Engineering
Point of view · 4 min read
Learning engineering is the discipline of deciding where capability should live, in the person, in the work, or in the machine, and then building it there and proving that it performs. Instructional design never had to make that decision. It inherited the answer.
The inheritance was reasonable in its time. Every method I was trained in, from ADDIE forward, rests on an assumption it never states: if an organization needs a person to do something, the only place the capability can live is inside that person, so you design the learning, run the course, and measure the transfer. For most of the history of workplace training that was simply true. The human was the only available container.
It stopped being true quietly, and the field has been slow to notice. Look at what a learning team actually builds now. Knowledge systems that put the right information inside the workflow at the moment it is needed, so that nobody has to carry it in memory. Feedback loops that correct performance while the work is happening rather than in a classroom weeks later. Automation and agents that absorb whole categories of know-how so that no human needs to hold them at all. A team that builds those things is no longer designing instruction. It is allocating capability, and every project now opens with a question that did not exist a decade ago: what should the system carry, and what must the person know?
Three distinctions that do the work
Answering that question well depends on three distinctions the field tends to blur.
Knowledge is not learning. Knowledge is information that exists somewhere; learning is a change in what a person can do. A procedure in a document is knowledge. A technician who can execute it under pressure has learned. Much of what organizations call training is the expensive conversion of the first into the second, in cases where the information could have stayed where it was and been delivered at the point of use.
Learning is not training. Training produces capacity for a specified performance: a defined outcome, a bounded context, a known task. Learning is wider than that, and the width is the point. Training is what you do when you already know exactly what the performance is.
Training is not formation. This is the distinction that matters most, and the test for it is offloadability. Because a trained performance is specifiable, it can be moved out of the person entirely, into a checklist, a sensor, a workflow rule, or an AI agent, and nothing of value is lost; the performance was the whole point. Judgment, ownership, and the ability to act well in a situation nobody specified in advance cannot be moved anywhere. You can store a procedure in a system. You cannot store judgment anywhere but in a person.
The hard problem
The clean version of that logic says: offload everything specifiable, reserve people for the rest. The practice is harder, and the difficulty is where the discipline earns its name.
Every time knowledge moves into the workflow so that people need to know less, a source of difficulty disappears. Most of those removals are pure gain. Nobody develops as a technician by memorizing torque specifications, and the error rate drops when the system carries them. But some difficulties were load-bearing. They never appeared as learning objectives, yet they were where situational awareness and ownership were built, as byproducts. The torque spec was trivia; diagnosing why the torque was wrong was the development. An organization that offloads indiscriminately strips out both, and it will not notice for years, because the dashboards measure the performance and the performance, for a while, improves.
So the real work is discernment: telling the load-bearing difficulty from the dead weight, then engineering the cognitive load of an entire organization so that systems absorb what is specifiable and people are reserved for, and developed by, what is not. That is a strategic function. It decides what an organization's people will know, what they will never need to know, and, less visibly, what they will never become because the occasion was automated away.
What this does to the designer
It raises the intellectual level of the work, and it raises it toward something instructional designers were always unusually good at: design under ambiguity. The gap between what a stakeholder asks for and what would actually change performance has always been the designer's territory. Learning engineering widens that territory from one course to the whole system of people, information, tools, and feedback that produces a result.
It also changes what a designer's hours are for. AI compresses production: structured designs render into first drafts, narration and visuals are generated rather than scheduled, assessment items are drafted from objectives that already exist. The compression is real and bounded. It reaches drafting, never judgment, and every generated asset clears the same review gate as anything made by hand, because a faster wrong course is still a wrong course. What the compression buys is time for the parts of the job that cannot be compressed: strategy, taste, and design. One learning engineer, so equipped, can build an entire learning system where an instructional designer built a course.
What this does to the function
A training department that has made this shift is no longer a support function that takes orders and produces content. It is the place where an organization decides what its people are for. It needs an intake that captures demand, a model that turns capacity into arithmetic, a governance structure that lets other people deliver to a standard, and a measurement architecture that proves the result in the business's own numbers. At Gigafactory Texas, that shift produced $50M+ in documented operational impact in under two years, and the number is the least interesting part of the story. The interesting part is that an instructional design team stopped asking how to build the course and started asking where the capability should live.
The instructional designer is becoming an allocator of capability. That is not a smaller job than the one I was trained to do. It is the largest version of it that has ever existed.
