Traditional 3-5 day training workshops won’t stand up to the fast pace of technological change. They just won’t. That whole one and done thing, you know, where learning is an event? It doesn’t work, not for soft or hard skills. But to teach technology? That is a definite no.
Technologies today are too complicated, and change too quickly. Learning has to be a journey. It has to build. Engineers and developers can’t go in a classroom and learn everything they need to know about a given piece of technology in less than a week.
Additionally, many of the technologies developers need to contend with for their organizations to remain at the top of their respective industry trees, are emerging. Meaning, everything there is to know about them hasn’t been discovered yet, which makes the learning process quite interesting and even more challenging.
So training can’t be an event. It must become an experience, an all-in-let’s-get-our-hands-dirty-together-in-a-safe-environment-where-mistakes-are-encouraged experience. In this environment, even mistakes have something to teach (and are often one of the most effective tools an instructor can leverage).
Technical training program design needs to be immersive because developers don’t just need to learn the technology; they need to learn how to learn technology.
In classes where learning leads to breakthroughs on the job and new innovations in the marketplace, developers need a chance to play, break, experiment, test and be tested. Then they need a chance to ruminate on what they’ve learned and go back to work, apply their new knowledge and skill on the job, and then come back to class to get the next chunk of knowledge to build on what they already know.
Then they can start all over again: play, break, experiment, test and be tested. Only it’s not a new beginning. It’s more like sliding the next piece of a puzzle into place.
The classroom for technical training is ideally a place where participants can collaborate with their peers, play with the tech they’re learning in progressive labs, and have their instructors interact with them on a level that goes far deeper than that whole sage on the stage, front of a room lecturing routine. Technical training should be 70 percent hands on and only 30 percent theory.
A few days might cut it for low level skills, but 6-12 weeks is a much better time frame when the goal is to teach developers and engineers how to solve complex problems and create the future with technology. How to not just work with it, but work around it, work under it, essentially, figure out how to use technology in ways that may go beyond its current application.
I think of it like writing. Sure, with a big can of Folgers and nimble fingers, you could write a book in a few days. But how good will it be? Will people be able to continuously use the information you’ve presented? Will it touch lives? Will someone remember it? Whereas if you take weeks, maybe even a few months, to flesh the story out and edit it down so that the message is clear, then you’ve really got something.
So, when it comes to class time for technical training, think weeks, not days. Learning leaders need to invest more time in technical training courses to ensure that learning sticks. It’s not just about teaching the technology. It’s about teaching a technical mind how to use that technology to solve business problems today and create solutions to different challenges coming down the road tomorrow.