A.k.a. The technical training that fails to engage
If you’re a technical trainer, you’ve seen this before: you designed an exercise, people in the class started doing whatever it is that they needed doing, and then they start dropping like flies. It happens for different reasons, but the outcome is the same: people stop working, and you’ve got to figure out what’s happening. Usually is one of two things.
The first way is boredom: the task sits below the person’s competence, people already know how to perform it (or they think they do), and they don’t feel a reason to stay engaged.
The second is anxiety: the task sits above their competence, they lose the thread, and — this is a well-documented phenomenon — they start forgetting things they already knew.
Between these two symmetrical failure modes lies a narrow band Mihaly Csikszentmihalyi called flow and we’ve seen this before in correlation with LEGO® Serious Play®: flow is the state where challenge and skill are both high and roughly matched, and attention is a consequence of that tension between the two.
Most technical training is designed ignoring this mechanism entirely, out of structural laziness: it’s easier to build a course as a sequence of content to deliver than as a sequence of challenges to calibrate. The result is what we all recognise: rooms where half the participants are bored because they’ve seen it all before, and the other half are silently panicking because they don’t have the foundation to keep up. Neither group is learning: they’re both just waiting for the ordeal to come to an end.
So today, as we get back into things after our summer breaks, let’s take a look at how the concept of flow can help us design better learning paths, starting with what flow is, and how to recognise it’s happening.
A Checklist of Conditions
In his 1990 book Flow: The Psychology of Optimal Experience (New York: Harper & Row), Csikszentmihalyi names eight characteristics of flow: clear goals, immediate feedback, a balance between challenge and skill, deepening concentration, absorption in the present, a sense of control, an altered perception of time, and dissolution of the ego. They can be divided into two conceptual groups:
- the last four — concentration, presence, control, altered time, ego dissolution — are effects, they’re what happens once certain conditions are met. You don’t design for them directly.
- the first three — clear goals, immediate feedback, the challenge-skill balance — are the actual levers, and they happen to be the exact levers game design has used for decades to keep a player locked into a system.
This also is a parallelism we’ve seen before: well-made games are machines for producing engagement (flow) on demand. And technical training — which has to teach complex systems, with rules, states, recoverable and unrecoverable errors — has more in common with a good game than it has with a well-structured manual. So let’s tackle a few of them.
1. Clear Objectives
Most courses state learning objectives in the syllabus and then abandon them for ninety minutes of slides. An environment built for flow, instead, communicates the goal inside the task, moment to moment: not “by the end of this module you’ll understand level-of-development management,” but “this model has three elements inconsistent with its declared LOD: find them.” It’s the difference between a table of contents and a mission. Game design calls this moment-to-moment goal clarity, and in technical training it translates into verifiable micro-goals: not “understand IFC interoperability,” but “this file opens in three different pieces of software without losing five specific pieces of data: find out which ones are lost, and why.”
2. Immediate Feedback
This is the Achilles’ heel of almost all classroom-delivered technical training: feedback usually comes at the end, in the form of an assessment or a test, by which point the error has already hardened into habit. In a flow-oriented experience, feedback is nearly synchronous with the action, and it’s the learning system that surfaces the consequence in the instant the mistake is made. When a model fails to federate because one parameter is out of standard, the conflict shows up immediately, and it’s not up to the instructor to review it three weeks later. This is also the strongest argument against purely theoretical instruction: without immediate feedback, flow is structurally impossible, no matter how good the lecturer is.
3. Balance between Challenge and Skill
Technical culture has a bias toward fixed difficulty: we do “beginners” courses and “advanced” courses as two parallel tracks that never talk to each other. But a real group is never homogeneous, and the right challenge for one person is boredom for another and panic for a third, in the same room, at the same moment.
Game design solves this with adaptive difficulty: the system itself raises or lowers the challenge based on observed performance, not on a plan fixed in advance. In technical training, this might translate into branching scenarios: a base task with optional extensions that only unlock if the previous task was solved cleanly. The people who finish early don’t sit around reading ahead in the slides: they get the extra constraint that raises the challenge to their level. It’s more design work. But it’s the only way to avoid losing half the room in opposite directions.
There’s also a couple of additional warnings to unpack here.
The pitfalls
Two things can quietly sabotage this, though, especially the latest point I made about branching and adaptive difficulty.
The first is framing: an extra task, handed out after someone finishes early, might be interpreted as more homework (historically a punishment) unless the design makes clear it’s a reward in the form of a harder, more interesting problem. If the unlock feels like punishment for competence, people start finishing slowly on purpose.
The second is cultural: this only works in a room where finishing the base task and stopping there is a legitimate outcome, not a visible mark of falling short. In organisations where anything less than full completion reads as failure — as a professional and an individual, not just a technical failure — nobody will risk being seen at the base level, and the whole point of calibrated difficulty collapses. Adaptive difficulty needs a culture that can embrace different people finishing in different places without ranking them for it.
The trainer’s job
Once the task is built to carry the three levers, the trainer’s job changes radically: it stops being about transmitting content and becomes about continuously reading the room — who’s bored, who’s drowning — and intervening on the task itself rather than on the explanation: tightening a constraint here, dropping a hint there, holding back the answer a beat longer when someone’s still working it out. That’s a different skill than lecturing well, and most technical trainers were never taught it, because nobody designed their training to need it.
On a side note, LEGO® Serious Play® facilitation runs on exactly this principle: the facilitator’s whole job is reading the group’s state and adapting the next question to keep it in the flow channel, rather than delivering content or running a fixed scheme for a workshop. It’s one of the clearer real-world models of what “designing for flow” looks like in practice.
This is also where the usual “gamification” rhetoric falls apart, as I wrote a few months ago: badges, points, leaderboards are useless when they’re bolted onto content that stays fundamentally lecture-based. That doesn’t produce flow, because it doesn’t touch any of the three real levers: it doesn’t clarify the goal moment to moment, it doesn’t give synchronous feedback, it doesn’t recalibrate difficulty. It’s simply decoration. Flow isn’t achieved by dressing a course up as a game: it’s achieved by designing the course as a system of verifiable challenges, with tight feedback and difficulty that moves with the person facing it. Everything else — scores, avatars, leaderboards — is optional, and often beside the point.
Csikszentmihalyi is insistent that flow isn’t some mystical destination but a structural condition for the activity to be successful. You produce it with the right conditions: you don’t chase it with enthusiasm or participant goodwill. We’ve been trained to face the problem as “making dry content interesting.” The problem isn’t interest: it’s the architecture of the tasks you’re proposing. Visible goals at every step, near-immediate feedback, difficulty that tracks the person instead of ignoring them. Designing technical paths this way costs more upfront than any sequence of slides, but it’s the only real difference between a course people forget the moment they leave the room and one they still remember months later as the point where they stopped knowing something and started being actually able to do it.
No Comments