I wish I could remember where and when I first heard the expression, “You need to go slow to go fast.” It might not be the conventional business wisdom these days, but I have to say I’ve never seen going “fast” actually work – at least not in training.
Recently a friend of mine called to catch up. We’re both in the instructional design business. So naturally we ended up comparing notes on our various clients and projects. She had just come from a meeting with a client who wanted her to take a “just the facts” approach to a course she was designing for the company. In other words, the client wanted her to organize the content in a topical fashion. Since we were also working on another course together, she wondered aloud whether the “day in the life” approach we’d selected was right. After all the “just the facts” approach was faster – faster to design, faster to develop, faster for learners to complete.
The problem is that going “faster” also means stripping out context that helps learners understand how to apply the content to doing their jobs better. In contrast, the “day in the life” approach, while slower to design, develop and complete, pays bigger dividends in terms of results. This is because the so-called slower approach explicitly spells out how to use new knowledge on the job – it provides context. I guess I’d rather get somewhere slow than go fast and wind up back at square one.
Theory (Fast) vs. Application (Slow)
I’ve seen the faster versus slower dilemma play out before. Many years ago, we designed a full curriculum of classes that taught new employees how to do a specific job. The design was based on an action-learning model. Learners would spend a half day in training followed by a half day applying what they had just learned to a real work project. The program culminated with a team project that required learners to apply everything they had learned to solve a real business problem. They then presented their solution to senior management and received direct, specific feedback, which added to their learning. The program was intense and it worked.
The last I heard, though, managers had deemed the training as too slow. So, the project work was cut. I wondered: How effective is the program if all that’s left are classroom sessions that cover the theoretical aspects of the job? The purpose of training is to ensure new knowledge and skills are applied so work is performed more effectively, right?
Cramming (Fast) vs. Chunking (Slow)
The other situation where “fast” doesn’t work involves cramming, which happens a lot with big systems projects. Too often, right before the go-live date, end users are jammed into a room and shown every feature and function of the system. Then they’re sent back to their desks dazed and confused. They still don’t know how to use the system, let alone how to use the system to do their jobs.
One of our clients let us design systems training in short segments instead. Each segment taught learners specific tasks they’d need to do almost immediately upon returning to their desks. In this way, new system knowledge was layered on bit by bit and immediately applied to make sure it would stick. It was slower, but it worked.
Untested (Fast) vs. Tried and True (Slow)
Finally, I’ve seen the fast approach backfire when subject-matter experts are pressed into inventing best practices in the service of expediency. This may happen during an organizational redesign. There isn’t time to test whether the new design will work let alone whether a best practice really is the best way to do something. Learners are then trained on these untested best practices. And, when the best practices don’t work as anticipated, mayhem ensues not to mention a trip back to the drawing board.
Re-do It or Do It Right
I agree that in today’s highly competitive 24/7 business environment, there is no time for lollygagging. And, I’ve seen well designed training save valuable time. For example, the “slower” training we designed for one of our clients got new employees up to speed on their jobs 78% faster than previously. Talk about a boon to productivity. But I wonder all too often: Why does there always seem to be time to re-do it, but never time to do it right in the first place?
