Most conversations around training start in a familiar way.
“What programs can you offer?”
“Do you have something on leadership?”
“Can you run a workshop for our managers?”
It’s a natural starting point.
But it’s also where things start going wrong.
Because at that point, the assumption is already set — that the answer lies in a course.
In reality, when we work with L&D heads and functional leaders, the conversation quickly moves away from courses.
It shifts to questions like:
-
What exactly needs to change in how this team operates?
-
Where are decisions breaking down?
-
What are people struggling with in real situations?
-
What would “better” actually look like in their day-to-day work?
Until those questions are clear, recommending a program is premature.
This is where the role of an L&D architect is different. The job is not to match a requirement to an existing course. It is to design capability around a specific outcome. And that requires going deeper than most learning conversations usually go.
A large part of that work is understanding the function itself. Not at a high level — but in terms of how work actually gets done.
-
How does planning happen today?
-
Where do delays typically originate?
-
What decisions are pushed up instead of handled at the right level?
-
How do experienced people in the system approach the same situations?
These are not questions you can answer through templates. They require:
-
conversations with functional leaders
-
time spent understanding context
-
and often, a fair amount of independent research
Because without that depth, any learning design will remain surface-level.
Once the problem is understood, the design process starts to look very different.
You’re no longer thinking in terms of:
-
modules
-
sessions
-
generic content
You’re thinking in terms of:
-
situations people need to handle
-
decisions they need to make
-
judgment they need to build
For example, instead of saying: “We need a program on supply chain planning”
The conversation becomes: “Planners struggle with balancing service levels and inventory — especially under variability. How do we build better decision-making in those situations?”
That distinction changes everything. Because now you’re not designing a course. You’re designing for a capability.
This is also where domain understanding becomes critical. Without it, it’s easy to fall back on:
-
generic frameworks
-
surface-level case studies
-
content that sounds right but doesn’t hold up in practice
With it, you can:
-
ask sharper questions
-
challenge assumptions
-
and shape learning around what actually matters
In many cases, the design work involves bridging two worlds:
-
the functional world, where work is messy, contextual, and constraint-driven
-
the learning world, which tends to prefer structure and simplification
The role of the architect is to connect the two — without diluting either.
Another important shift is how success is defined.
If you start with a course, success becomes:
-
completion
-
feedback scores
-
participation
If you start with capability, success becomes:
-
better decisions
-
fewer escalations
-
improved outcomes in real work
And that forces a different level of rigor into the design itself.
Over time, you realize that good learning design is less about content creation and more about problem-solving. You’re working with:
-
business leaders trying to improve performance
-
L&D teams trying to enable that improvement
-
and experts who bring in real-world depth
The design sits at the intersection of all three.
This is also why, in many cases, the final solution doesn’t look like a traditional “course” at all.
It might be:
-
a series of expert-led discussions around real scenarios
-
structured interventions around key decision points
-
or a mix of formats tied together by a clear objective
What matters is not the format. It’s whether it builds the intended capability.
At Huksa, this approach is central to how we work. We don’t start with programs. We start with outcomes.
And from there, we design learning that is grounded in the function, shaped by real-world expertise, and focused on what teams actually need to do better. In the end, the difference is simple. You can start with a course and hope it leads to better performance. Or you can start with performance — and design everything else around it.
