In my recent post, “DRIVER – A Repeatable, Agile, Methodology to Generate Learning & Performance Guidance”, I’ve received many positive comments and a few great questions asking for more details. This post will attempt to slice into the anatomy of the DRIVER discipline and add some essential context…yes…discipline. I chose the word “methodology” in the original title, but upon reflection I can see how that might skew the perception of DRIVER to be some sort of tool. It’s not a tool. It is the only approach I’ve found after 30-plus years in the L&D “charley foxtrot” that prioritizes PERFORMANCE in the environment where our workforce learns and works. Yup…this is a paradigm shift.

Many have written about this “environment” as a dynamic ecosystem, and as jargon-ish as it sounds, it’s a reality. At my most recent conference breakout sessions I open by asking, “By show of hands, how many of you have a dynamic learning performance ecosystem in place today?” Usually a few hands go up with most either unsure and would rather wait to see where the question leads.

Truthfully, everyone in those sessions has a dynamic learning performance ecosystem in place today. The better question to ask is, “How many of you feel you have optimized all the moving parts of L&D functions that should be in place to sustain that ecosystem?” Am guessing not many hands would be in the air. None of us do a good job of that because we’re not thinking in that paradigm…yet.

I’m not going to blast through what is and isn’t part of an ecosystem, but instead will focus on who is plugged into it…the workforce…and what is expected of them to produce…business outcomes. More importantly, I want to point out an underlying perspective that should be top-of-mind thinking throughout our efforts to create and sustain workforce capability. Top-of-mind should be driving sustained workforce capability. Period. And…by the way…the only place sustained capability matters is at Point-of-Work (PoW).

 

The Continuum Concept

To my knowledge, no training course graduate walks out of class or signs off an online course as competent to execute consistently at PoW. The journey to competency at PoW is completed over time by actually DOING the work…failing at times…making corrections…receiving guidance…making more attempts. That process is what I would call “learning on the job”. Isn’t that what the 70% of the 70:20:10 is all about? Unfortunately, not “getting it right” the first time and every time has a direct linkage to business outcomes. We did/do an outstanding job of training, and we can prove it, but are these not the results we all experience? Something is missing.

Outcomes are not optimized. They get there over time, but at what cost? Methinks there is a better way to slay this beast after bashing my brain and those of my teams over the years trying to squeeze better outcomes from our training solutions.

Our solutions need to track with the development cycle of reaching competency. Nailing the “training” part of the trip is not enough and yet it is often what we do and hope for different results. Yes, we get creative and micro, gamify, and adapt learning paths, but it’s still training.

Like that ecosystem question I opened with, there is also a Learning Performance Continuum (LPC) in place too. It’s kind of like the “ecosystem thing”…it’s already there…but I must ask, “How well are our solutions synched up with it?” (See Figure #1)

The continuum is not based on rocket science but can…and should…flip our thinking dramatically. The continuum runs simply from Point-of-Entry (PoE) to Point-of-Work (PoW). No muss, no fuss, right? Not so fast. Here’s a truth I always try to keep top of mind…

 

Everything we deliver at PoE should be tied to the reality of performance expectations at PoW.

Figure #1

Let’s take a closer look. PoE is an obvious starting point…entry into the journey to competency. Onboarding should come to mind straightaway, but don’t stop there. Consider an existing worker promoted into a new role…or a new product launch for the sales force to sell…or a new safety protocol for a bedside clinician…are these not also points of entry? Absolutely. How do we address them today?

To complicate things those workers experiencing change in workflows, processes, protocols, etc., are already at PoW. That little complication should not slow the transfer of operational changes from a critical PoE event despite the recipient is already buried in a workflow at PoW and pulling productive workers off task to train them should not be the knee jerk reaction.

This is exactly why the DRIVER discipline should come into play. What comprises the best way to transfer knowledge seamlessly, frictionlessly and ubiquitously regardless of where the worker is on the continuum and…especially…where they might be during a critical workflow? The answer is, “It ain’t training!”

Then what is it?

The workers need a driver in place to enable overcoming their moments of need right then…right now.

The solution should be based upon application of whatever asset(s)/media/collaborations are necessary to close the gap at the moment of need with minimal delay and frustration…and I’d add we should include avoidance of risk and liability of error as well. I’m sure that’s not news, but consider these questions that should follow…Where do those assets come from? How are they accessed? Are they pulled? Are they pushed? Are they tracked? Are they delivered contextually? The list goes on before the first storyboard gets baked.

The source for answering those questions is embedded within the DRIVER discipline.

Let me stop right there and toss in some context for you. The definition of what constitutes a driver for performance is important…

A DRIVER is a condition or a capability…that if in place…enables a specific business outcome.

A solid, viable driver should enable an outcome. Is it a 10-second video clip, a checklist, a job aid, a live IM? Determining what the right driver is at a moment of need becomes our mission. That definition hopefully helps posture why I call DRIVER a discipline. It’s the process of ensuring the right conditions and capabilities are in place at moments of need and at PoW. I’ve included the DRIVER diagram from the earlier post below as Figure #2, but you should hit the link for details around the acronym.

Figure #2

Ultimately, we are seeking 7 Right Things during Discovery that combine to Road Map the answers to the questions I posed and more. The Road Map provides high-level design clues to what asset(s) should be part of the solution. Keep in mind one of the 7 Right Things deals with the delivery technology…the push/pull questions become quite relevant…as well as end-user technology, available bandwidth, etc.

I hope this is not getting crazy confusing, but we’re talking “moving parts” that L&D may not be considering…nor even need to…in the development of training solutions. That means there needs to be a compelling continuum-think mindset present synched with our solution set. I suppose we could say that continuum-think is one of several drivers behind full adoption of the DRIVER discipline.

On a closing note, I had an interesting comment on the original post asking about how DRIVER was an agile tool. First, DRIVER is not a tool. Second, let’s define what part of agile matters most. I say that because there are multiple faces of agile in the DRIVER discipline.

·         Most obvious is Intentional Design with Iterative/Incremental deployment of objects to field test and refine…not just to achieve rapid development of training assets

·         The LPA in Discovery is also an iterative effort from prioritizing gaps to nailing the right combination of 7 right things in the solution

·         Evidence is where we’re able to track business impact of incremental deployments versus a total solution and enable early actions and decisions.

·         Replicate is where I’m living by the credo of “create once – use many times” by embedding performance guidance assets and hands on use of performance guidance technology during PoE formal learning to promote that thread of continuity from PoE to PoW that delivers a seamless and frictionless and ubiquitous learner-to-performer experience

Pick whichever one floats your boat; they’re all part of the DRIVER discipline. I actually think I may have left out the most important aspects of “agile” of all….

·         PoW where the workforce is both agile and resilient because the performance guidance drivers are in place and enabling them to execute effectively and efficiently at PoW to generate business outcomes. Seriously, isn’t workforce agility at PoW the big deal?

 

Okay, better stop there. This could boil over into 3,000 words in a heartbeat. I’m on a roll. What’s been covered here is pretty darn dense and may trigger more questions than deliver answers, but then…hey, that’s impetus to dig deeper for the answers. I think DRIVER is that important and hope some of you agree.

I’m currently working on a workshop to support teams who may choose to take the plunge to DRIVER in the future. If that sounds interesting, let me hear from you and we can discuss beta options when it’s ready.

As always, I appreciation your tolerance for my rambling style and welcome your questions and comments as they surface.

Take good care!

Gary G. Wise
Workforce Performance Advocate, Coach, Speaker
gdogwise@gmail.com 
(317) 437-2555
Web: Living In Learning
LinkedIn