I grew up visiting the national parks with my parents on long road trips across the country. We live in Florida, so getting to see mountains was a rare treat that I always looked forward to. I got away from it in my twenties, but as I got older I felt the pull of the mountains calling me back. One of my friends has recently declared his life’s quest to be visiting every national park, so we took the chance to tick Bryce Canyon off his list in the days following this year’s Devlearn. Bryce isn’t quite as imposing as Yosemite, nor as famous as Yellowstone, but I’ve always been curious to see the bizarre little spires (the famous “hoodoos”) ever since I first saw pictures of them.
And they don’t disappoint. The rim of the canyon is on a bit of an incline, so as you approach it from the west, all you see is a fairly unremarkable forest (though if you’re lucky, you’ll spot a few deer).
Cresting the hill brings you to this view…
And it’s hard not to have your breath taken away.
My friend and I immediately started searching for the trailhead, ready to dive headfirst into that beautiful canyon.
Another friend took one look and decided that an afternoon of reading and drinking hot chocolate in the lodge was preferable to anything that could happen in that canyon (in her defense, it was bitterly cold, about to snow, and the hike ended up being incredibly challenging – her choice was probably the rational one).
It’s amazing this place could contain such a variety of experiences. You can dive into an intense day hike or bum around and relax by the fire. There are deep wilderness backcountry trails that take days to traverse… or you can hire a tour bus from Las Vegas and get driven straight up to a paved overlook path.
If the excitement of being in this beautiful place isn’t enough, you can even get an extrinsic reward by playing the “Hike the Hoodoos” scavenger hunt.
After giving it some thought, I realized how the act of building and curating these experiences feel oddly parallel to what L&D professionals do in the workplace.
Performing well at work is wild. It is complex. It is no longer “show up and push this lever for eight hours.” It’s more like, “here’s a problem we don’t know how to fix – please solve it.” During his keynote, Neil Degrasse-Tyson spoke about the irrelevance of knowledge. The people that will succeed in our new economy aren’t those who remember the most, but those who can solve the most problems and create the best new ideas.
— Kevin Thorn (@LearnNuggets) October 29, 2014
It’s an amazingly big ask for our learners, but trying to contain this challenge and complexity, dumb it down somehow, would take away everything beautiful and exciting about it. Instead we must provide the appropriate experiences within that wildness for each person. In the same way we can’t let a bus load of sedentary sightseers try to tackle the “Under the Rim” trail (23 miles one way), we can’t let an inexperienced new hire tackle a complex project without the necessary guidance and resources. The same way we can’t hold back an experienced hiker or ultrarunner by building only easy paved trails, we shouldn’t prevent the experts from achieving all that they can.
In one of the conference breakout sessions, Marc Rosenberg and Steve Foreman laid out the case (based on a recently released a white paper) for just how such a learning ecosystem might look. Clark Quinn’s book, Revolutionize Learning & Development, offers up a similar vision. It’s a big shift in thinking, and involves not just considering the singular learning experience (through an event or performance support tool) but all the things before, after, and two years down the line.
Building an ecosystem isn’t easy, and it isn’t something that can be accomplished in an afternoon. We’ve been discussing it at my company for some time, and it’s going to take a while before all the disparate pieces come together and all the audiences have what they need to thrive.
But that’s what it’s going to take to start learning in the wild.
As for the conference itself: I cannot thank enough the eLearning Guild and my company, who gave me the opportunity to speak and give back to a community that has given me so much. A big thank you to everyone who showed up and added to the conversation! Please contact me should you have any additional questions or would like to chat further.
The final day of DevLearn had me sitting in sessions led by Clark Quinn, Conrad Gottfredsson and Neil Lasher. Since there were so many overlapping concepts, I’ll just cover them based on the two overriding themes I saw rather than by session.
Start at “apply”
The problem that instructional design seems to face is that requestors bring us in to situations that don’t always require instruction. So instead of creating unnecessary instruction, start design by trying to understand what the end user needs to do to perform a behavior. If the design demands the introduction of new knowledge, introduce that knowledge within the relevant context, then provide the ability to apply that knowledge in practice and offer appropriate feedback. But if performing doesn’t require instruction, don’t force it. As Clark Quinn mentioned earlier in the panel discussion, “build knowledge into the world, not in the head.”
In terms of deciding what needs instruction and what doesn’t, Conrad Gottfredson presented a beautifully simple system for sorting it out. While performing your task analysis, determine the negative consequences your learners face should they fail and rate it on a scale of 1 to 7, 1 being no effect, 7 being catastrophic (I would probably add a level 8, just in case failure leads to a zombie apocalypse). Anything rated 5 or higher gets the most instructional attention, anything rated a 3 or lower gets mostly performance support. It’s so simple, but it’s a brilliant way to make sure our end users get the support and practice they need to perform (and not cause a zombie apocalypse).
I like the emphasis at this conference on building smaller bits of content as performance support instead of courses. I never went to school intending to become a technical writer, but somehow when I landed my current role as one, it seemed to be a pretty natural fit. I think if instructional designers better understood the things technical writers produce (help systems, job aids, documentation) and if technical writers understood the skills that instructional designers can leverage (user centered analysis and design, multimedia instruction) both professions would be in a better place.
I think since my department has a history of delivering on these things, most of our requestors are willing to be talked into performance support solutions, even if their initial inclination is to request training. There are other challenges, of course, namely how do we respond to requesters demanding a small forest’s worth of printed documentation (destined to go out of date almost as soon as the training ends)? And how do we optimize documentation so that it covers everything that needs to be covered while being attractive and not intimidating for the user?
Then there’s problem of managing and tying all of these things together, which leads us to…
Build an ecosystem
When it comes to supporting performance, elearning is just the start. As Art Kohn mentioned on the first day of DevLearn, nothing can be taught in one pass, as the learner will almost immediately forget it. Instead the goal should be to build an ecosystem of learning and support by using all of the tools at our disposal. This means EPSSs, job aids, pocket cards to support performance as well as mobile delivery and context to support instruction. Additionally, managing it requires content governance to ensure the most relevant things are easily discoverable and not lost beneath a mountain of outdated content.
Neil Lasher displayed a brilliant example that tied in some of the transmedia storytelling ideas in Lee Lindsey’s session on day one. He presented a simple scenario of a top sales employee at a retail outlet angrily tossing a customer out. You’re then presented with several options:
- Verbal Warning
- Written Warning
Making the wrong choice (in this example, a written warning) causes the employee to storm out and quit. Later on, you’ll receive an email or SMS offering additional information and coaching. A couple days later you’ll get another SMS, saying there’s a situation developing with another one of your employees. It leads you into another scenario where you have to deal with an employee causing problems because they saw the other employee quit angrily a couple days ago.
It’s a real time scenario. Like Animal Crossing for new managers! 🙂
As more scenarios are developed and new content is required, more pieces to the ecosystem (both instructional and performance support) are added. It’s important to note that at no point is any “score” information provided, as simply receiving feedback from the scenario is enough. Score data is only used on the backend to calculate what the system should send the user to next.
Keynote: Talent Anarchy
Though I found the Talent Anarchy keynote on hacking to be a useful tool that I’ll be implementing on an almost daily basis, I don’t know how much I can add to the conversation around it. Instead, I defer to Bianca Woods and Cammy Bean who have posted excellent recaps from the session.
And that’s it!
I want to thank everyone for another great DevLearn where I learned new things, gained tons of inspiration and met people doing some very exciting work. Rather than being an end, DevLearn last year was a real kicking off point. Many of the things I’m only just putting into practice were inspired by those sessions, and I suspect it’ll be similar this year.