Part 1 of Part 1: Telling Rewriting the LMS Story

Note for my semi-regular (not so much lately) readers: Apologies for my absence. I recently took a position with a new organization.  The transition has soaked up all of my cycles but I think things are starting to normalize.

What would you build to enable access to structured learning opportunities?

If you were going to design a scalable system that enabled broad access to training opportunities across a large, geographically dispersed organization, what kind of system would you build? If you wanted to show an organization’s collective progress toward proficiency and readiness, what kind of system would you design? Chances are, many of the characteristics and features you would design into such a system would look similar to those offered in a typical LMS.

This piece isn’t meant to bash LMS products, but to question the premise and focus of this type of tool. LMS products are well intended by both the vendors that build them and the organizations that deploy them. Few enterprise systems focus on individual pursuits at such a granular level. LMS deployments *can* be a tremendous strategic asset. Features of LMS *can* deliver great value for every employee in the organization. Unfortunately, many (maybe most) LMS deployments… don’t.

The problem(s) with LMS deployments

For many folks that use LMS, these tools are anathema. This perception could stem from a misguided notion (on the part of those that would purport to manage learning) that an internal biological process (learning) can be regulated by a loosely coupled external technological stimulus (management system.) Moreover, many of the most common LMS features apply more energy to providing for those that watch the system than providing for those that use it to improve their own performance. This imbalance describes much of the problem I have with the idea of LMS. Systems focus on launch or attend and track. They tend to exist for the benefit of the organization as watcher, not the person as experiencer.

What characteristics exemplify these problems?

Again, this isn’t necessarily a swipe at LMS vendors. Customers drive priorities and shape implementations. Without pointing fingers, here are 6 of my least favorite LMS characteristics expressed as pseudo-requirements. I think you’ll find at least one thing here that resonates with your own experience.

1. The system must provide an environment that makes it easy to unleash ideas that torture the relative few onto the rest of the organization.

The label LMS implies a certain paternal push mentality. We push things to our “learners” in a content monologue. At worst, this monologue is a poorly produced, unreliable, dysfunctional mess with manifestations tantamount to torture. At best, it’s often content on a conveyor belt.

When we make it easy to distribute information, we also make it easy to broadcast well-intended but poorly selected and designed messaging. Much of the e-learning we see hung on learning management systems creates shallow communication without creating deep conversation. Broad messaging deployment with low costs of entry can tend to create pollution in an already polluted stream. Sure, an LMS can be super-efficient…

“There is surely nothing quite so useless as doing with great efficiency what should not be done at all.”  ~Peter Drucker

At some point, for better or worse, we all have an idea that we think will benefit the business. We don’t always consider whether or not we should, or how much it will actually matter. The LMS provides a platform to propagate ideas that compete for the attention of the participant. We don’t always coordinate these broadcasts well.

2. The system must dispense events within a narrow set of human contexts.

Let’s face it. One of the LMS’ primary value propositions is that of an event dispenser. Folks come to the LMS, find something in the catalog, and register for a self-paced or facilitated event.

The problem is not that the system functions as an event dispenser. The problem is the classifications of events focus on a very narrow set of human contexts. Most LMS focus on the solo frame and the group (one to many) frame while ignoring the rest of the spectrum. 

People are often found in pairs, teams, communities, and societies. Funny how we work. A too narrow focus prevents us from connecting people with people where and when they are and in the ways that we tend to gather naturally. While the LMS doesn’t need to provide all of these opportunities, the system with the right design won’t exclude them and, more importantly, won’t prevent smooth flow between them. It’s not about bolting social tools onto an LMS, it’s about being mindful of opportunities and opening system discovery and matching features to take advantage of these contexts.

3. The system must disconnect “Learning” from work

One of the problems I, and many others, have with the “Learning” management system has to do with the lexicon and language used to describe the container system as well as the stuff that it’s supposed to dispense. There is no question that people *can* learn from pathways created within an LMS. However, the events themselves aren’t learning. People learn. Events don’t.

Perhaps the greatest fault of the Learning Management System is the propensity of these fortresses of content solitude to completely isolate learning experiences from work experiences. Whether or not this is intentional, events within the system are typically deployed in ways that remove the participant from work contexts to receive the training experience. While this isn’t always a bad thing, this configuration doesn’t provide for the boundless potential of learning experiences that are connected with a real needs and work challenges. Some of the best learning experiences are directly connected with work. Many of the best work experiences are directly connected with learning.

4. The system must create unpleasant user experiences as a rule.

An LMS content library is a collection of objects. Some of these objects seem to be designed to defecate directly into the soul of the participant. Add this to the catalog link dumping ground problem and usability issues… Horrifying.

Photo Credit

5. The tool must be activated as “yet-another-IT-system”, completely independent of similar systems

Photo Credit

Large enterprises are full of systems. These separate systems can seem to be in competition for operational territory. Sometimes these systems talk to each other. Sometimes they all use the same authentication pool. Sometimes systems complement the strengths of other systems and bond together to make things easier on the people that use them. Sometimes… they don’t.

6. The system must focus the most energy on the things that mean the least to the people the system is intended to help

Image Credit

In our attempts to control everything that happens in our organizations, to know who is doing what they have been assigned, and to create reports for reports sake, we create monsters. These monsters focus more on features that feed the panopticon cycle than helping people do what they need to do. Even though I question the usefulness of a CYA reporting mandate in actually affecting behavior, external reporting mandates and other hierarchical reporting requirements are necessary. However, these features shouldn’t be the most prevalent uses and value propositions of the LMS.

…that sounds hopeless…

These characteristics, while common, aren’t rules. They don’t need to apply universally to systems intended to help people. We can do better. The future’s systems, better systems, might not be recognizable (or labeled) as LMS. This would suit me fine. Rather than chase management of learning, maybe systems of the future will focus on Work and Learning Support, with an emphasis on work and support.

This is the vision I’m pushing for in my organization and I think we’ll get there. In my view, the first step is dropping the ideas of management and learning exclusively as a packaged event. Big change. Big promise. Worth changing our collective mindset about LMS.

In the past weeks I’ve seen a bit of discussion surrounding fast and slow learning experiences and the strategies for setting up and supporting each. Some voices advocate exclusively for a chronic learning journey, bemoaning things like performance support and on-demand learning. Others yearn for a more acute experience, providing just what folks need when they need it. Very few of these discussions seem to draw a dividing line between on-demand learning and support experiences (just in time) and protracted learning campaigns (spaced over time). But there does seem to be some polarization on the gradient between the long-game and the short-game. Why does it need to be one or the other? Can’t we have both?

There is room for both a short and a long game for those looking to increase proficiency, maintain readiness, and get stuff done. In my view, there are three potential goal categories of change we want to encourage and assist. The goal category can be an indicator of short or long strategies. Here’s the way I think about teeing up opportunities for both short and long learning experiences.

1) We want workmates (and / or they want themselves) to be able to DO something they weren’t able to do before. To accomplish a task or demonstrate a skill that contributes to an outcome.

2) We want folks to BELIEVE or value something that’s important to the organization, to themselves, or improves the treatment of fellow humans. For example, it may be difficult to perform if you don’t believe in the organization, the product, the process, or yourself. Sometimes, many times, choosing the hard to do right thing is about valuing the right thing more than the easier to do wrong thing.

3) We want our partners to fill a job role and BE what they can be to the organization or for themselves. Advancing from apprentice to master, climbing the career ladder from entry level to master of craft. Growing to meet their potential.

This mapping illustrates three related categories of accomplishment. Thinking this way, there’s a probably a greater chance that a DO goal will match a short-game strategy than a BE goal. Not always, but it’s likely that DO will be shorter term than BELIEVE and BELIEVE shorter than BE.

This categorization could also provide some relational framing. For example, a BE goal could contain several smaller BELIEVE and DO goals, shorter strategies or campaigns that contribute to a long game strategy. A DO goal could contain a BELIEVE goal. A BELIEVE goal could contain DO goals, and so on. Mapping these frames could create a very complex picture of goals and sub-goals.

This picture drives a conversation and produces questions that give birth to other questions. What business measure do we want to improve? What opportunities do we want to queue up? What does the entire canvas look like and when can we help? How is the business impeding (or providing counter-incentives to) these goals? When is it best for us to get out of the way and let people take control and plot their own course?

“DO, BELIEVE, and BE” is one way to frame the conversation around the ways we might want to move the needle. How do you frame your conversations?

I’ve long held this theory about the relationship between trust and chaos (which often results in conflict). The theory started out like this.

Trust and chaos have an inversely proportional relationship. As trust nears zero, we’re all going to be in serious trouble.

This statement implies that as trust goes up, chaos decreases and vice-versa. The more I think about it, the more I think this isn’t exactly right. How could it be right? If it were this simple, trust would be universal, right? And we know this isn’t the case. Not even close.

I do think there is a direct relationship between trust and chaos. Trust is at the heart of most, if not all, of the conflicts and problems on this little planet. But the relationship is far from simple.

Earned & Granted

There are two ways I’m now thinking about the relationship between trust and chaos. The first is a simplified categorization of trust. This categorizes trust as earned and / or granted.

This is the first opportunity for conflict. And in this logical equation, multiple situations can arise:

• Trust can be earned but not granted.
• Trust can be granted but not earned.
• Trust can be earned and granted.
• Trust can be neither earned nor granted.

Only one of these situations minimizes conflict. A combination of these situations can compound conflict or chaos. For example, if one member earns but isn’t given trust while another is given without earning, ugly conflict is sure to brew below the surface. Many workplaces have their share of empowered incompetents. Conflict in these environments is probably significantly higher than environments with equitable distribution of trust. Ideally, trust is granted until removed (temporarily) as a consequence.

Which workplace do you think operates at potential? The workplace with low trust / misplaced trust or the one with high trust / equitably distributed trust?

Local & System Trust

Mario Vittone, a friend of mine, recently retired from Coast Guard active duty. Back in 2008, he wrote a fantastic article titled “The Missing Competency“. In his article, Mario writes that trust is the missing competency in leadership development. The component of leadership that is seldom spoken of in formal development programs and rarely practiced with intent. He gives some great advice for increasing local trust, in particular methods you can use to increase your personal trustworthiness score. Read Mario’s stuff! You won’t regret it.

But I see local trust and system trust differently. I see tight coupling with local trust and loose and complex coupling with system trust. Think about how much you trust the U.S. Congress this year or last year. Now compare that with two decades ago, if you can remember back that far. Is your trust of that system component higher or lower? Now think about large banks and Wall Street. Do you have higher or lower trust in these systems than you did a decade ago? System trust isn’t universal and it’s far more complex than local trust.

A Trust Curve

I’ve revised my original theory about the relationship between trust and conflict or chaos to look more like a curve. And this curve isn’t the same for every context.

Trust seems to have a band of effectiveness on average. While I think we should 1) grant trust more often and 2) push for more trust, I don’t think 100% trust is the answer in every context. There is likely a threshold of trust that provides the best return on energy used to build the trust, beyond which conflict could be higher.

For example, consider the much maligned position of IT services within most organizations. Opening up 100% trust provides a risk calculation that is uncomfortable or unacceptable to those that govern IT resources and are charged with protecting the organization, its business, and its data. In this situation, zero trust is completely counterproductive (though common). 100% trust (though rare) opens the organization to risks that IT management believes are unacceptable. So the default response to many requests for an increase in trust or access is no. Right or wrong, this is a common position. It’s a balancing act that tends to err on the side of caution.

Within any optimized trust band (best discovered through experience and honest evaluation), there lies a point of diminishing or negative return. The hard part is figuring out where this balance is and leaving both benefit of the doubt and options to increase the window of trust when the returns are positive. This becomes a game of trade-offs. One of min-max where you’re aiming to maximize the positive and minimize the negative. It’s almost never simple.

Low trust makes things that should be easy excruciatingly hard to get done. Unbalanced assignment of trust creates subsurface conflicts and can destroy a team’s motivation.

How do you maximize trust and minimize chaos?