Why MOOC Engagement is So Hard

MOOC?

A MOOC is a Massive Open Online Course. It offers a social media framework to support open, informal, social learning on a topic. The MOOC I joined was called #PLENK2010 (Personal Learning Environment, Network, Knowledge). #PLENK2010 started in September 2010 and runs for 10 weeks. It was created to support several research projects on the subjects of PLE and emergent learning. Topics included learning theory, social learning, LMS (Learning Management Systems), PLE’s, PLN’s and Connectivism & Constructivism. I registered late, with no bad consequences.

Within the forums and Elluminate sessions, there was some discussion about why a MOOC is so frustrating. One reason is the way in which we think about classes. A traditional class has requirements, goals, tests and clear limits to what will be covered. The teacher’s job is to walk you through the material and insure that you learn it in the prescribed way. We are comforted by the milestones and limits of the class. We celebrate our completion. And our grades tell us how we did. When it’s over, it’s over. A traditional class is a good example of formal learning.

So it’s no surprise that when we drop these students into a MOOC, they are going to get frazzled. Such frustrations, we are told, is the norm and to be expected. I had to wonder if that was just a cop out for poor design. Even the navigation was challenging. But maybe the design was not so bad after all.

A MOOC has almost none of the safety features of a traditional class. Sure, it has a time, a topic and a location online. By that I mean a place to discuss the material under the loosest supervision of some moderators. It has no objective to achieve, no goals beyond that which you bring to it. It has no tests to tell you how you’re doing. There are no milestones beyond the abstractions of statistics. There is not even a glossary, unless of course, you decide to work on one for the group, which we did. There are no assignments or attendance requirements. There are suggested readings sent out in the Daily newsletter to offer a starting point. But you are not expected to read them all. Indeed, you are told it would be impossible to read all the suggested readings and forum posts. I concur.

In a MOOC, you are encouraged to take a whole new approach to learning. You are asked to step up and create your own flight path, your own adventure. To where you ask? Well, that’s part of the challenge. You are invited (dare I say begged) to make the class into what you want, to change the system at will. If you need a feature not currently available, such as a private chat room to discuss sensitive things, one can be set up for you. If you want to open up a new discussion in the forum, just do it. If there are parts of the system that could work better, tell someone who can fix it.

You are asked to bring order to this massive pile of information. To all of it? No. Remember that in this ever growing field of data, you can never wrap your head around all of it. Be selective. Skim the headlines in the Daily newsletter. Don’t feel like you have to read them all. Just pick the ones that interest you. If you don’t like the writing style or the discussion, then move on. There is too much good stuff to get stuck in parts you don’t like.

In this new approach to learning in a MOOC no real thoroughness is possible. So you need to release the fantasy of doing it all right. That fantasy is at the root of suffering on a MOOC.

Be the explorer. Chart out a plan to learn all you can about some small slice of the puzzle. Find the best articles and resources in this area and curate them. By that I mean arrange them in an order that makes more sense and is easier to digest. Be like a museum curator and decide what is important and how it should be displayed. Produce a field guide to the area and make it freely available to others. That’s the “Open” aspect of a MOOC. Summarize key points of long threads to save others the arduous work of having to plod through 90 comments.

Blog to Engage & Learn

One of the best ways to engage in a MOOC is to create posts on your own blog to report what you are learning. Don’t have a blog? Get one. They’re free and easy. You might be wondering, what if no one sees my post? What if no one comments on my blog or finds it useful in any way? Then what? Am I just wasting my time?

As it turns out, every new blogger shares this concern. Just know this. It always takes longer to develop followers and comments than you think it should. Do it anyway. Keep posting. And when you comment on blogs and forums, go ahead and make appropriate references back to your blog posts. Eventually, if you stay with it, you will find your audience and develop your network, a circle of people who care very much about what you have to say and what questions you have.

Beyond the service you provide others in your blog, there is another compelling reason for writing posts about what you are learning. Your blog can serve as a public repository for notes to yourself. Those notes will document the insights and conclusions of all your travels through the field, and perhaps even your frustrations. A year from now you might want to review your notes, for surely you will have forgotten much of what made your learnings so powerful at the time.

Blog because you learn better with it. By reporting your struggles to learn the material, you learn better. By summarizing, reviewing and debating the ideas of the course, you learn better. By writing for an audience, you write better and thereby learn better. By making your journey open through the use of blogs and forum comments, you not only serve others, but you also do the extra work of sense making that leads to deeper integration of the materials.

As you give the material away in a form that works for others, you make it more your own. We teach best what we most need to learn. — Fritz Perls. And we we learn best that which we teach others.

So why is a MOOC so hard? Because it breaks all of our expectations about what is supposed to happen in a class. We are asked to transform from the passive role of student to the more active role of self-directed learner. Our new role makes us ever more responsible for our own learning, in a way that might just expose us and make us appear silly. That is a daunting undertaking, even for the most web-savvy students. The good news is that you can’t really fail, unless you apply the old rules to the new situation. Survive a MOOC and you’ll come out of it a better person. Thrive in it and you’ll come out a better leader.

NOTE: Much of this was culled from forum posts and Elluminate sessions of #PLENK.

References

http://ple.elg.ca/plenk2010/ PLENK 2010 Blog
http://connect.downes.ca/ Welcome to the Course PLENK2010
http://ple.elg.ca/course/moodle/mod/wiki/view.php?id=60&page=Recordings PLENK2010 Recordings on Elluminate
http://wthashtag.com/Plenk2010 Transcript of #PLENK2010 Tweets

Blame the System

We live in a culture of blame. That’s not always a bad thing. Blame does point us to questions of who broke something and who should fix it. Managers, teachers and parents all try to instill values of personal responsibility in their charges. Much of that instilled value involves feeling bad. We want those people to feel bad when they mess up. Especially something for which they have agreed to be responsible. We want them to blame themselves when things go wrong. We feel better when others feel “bad enough” for what they did. We may even want them to grovel.

Now it takes a lot of time and effort to discern who was responsible for an outcome, and to what degree. One approach – if everyone just takes 100% responsibility for whatever went wrong, then we can all get back to work. “If only I had done my part, this would never have happened.”

Of course, it rarely works out that way. Some people consistently take far less blame than we’d like them to, while others take too much. Indeed, we often define our best people as those who pick up the slack where others have dropped it. And as long as the job is getting done, management rarely feels the need to confront those dropping the ball, letting standards slide and having things fall between the cracks. As a result, those who frequently pick up after others often feel resentful, but may be afraid to complain. And those who regularly get picked up after have a false sense of how good or successful they are at their jobs. No news is good news, particularly in organizations who don’t actively encourage feedback.

When taking responsibility requires that we feel bad, we have moved into blame. Where we have lots of blame, we have lots of fear, guilt and shame, thus creating a fear-based organization. Problem is, we don’t learn well in the presence of guilt and fear. The fear that comes out of blame will even inhibit problem solving abilities. A systems theory view of productivity can show us how to blame the system itself, instead of each other, thereby reducing fear. A simple definition of a system might include the values, procedures, rewards and communications of an organization. When you blame a person, you may feel better, but you forget to look at how the system has contributed to their actions.

So while there is a certain workaholic satisfaction that comes from hoping everyone will take 100% responsibility, it never really works out as well as we hope. Those who take too much responsibility burn themselves out, resulting in what we call work anorexia or work avoidance. Taking too much responsibility for events over which we have little control or power always leads to depression. People regularly try to take too much responsibility in a fear based organization. Unfortunately, the best you can ever get out of such a system is basic compliance. If you want more than compliance, if you want excellence, you will have to eliminate fear from the organization. (See point #8 in Deming’s 14 points, Drive fear out.)

Given how much guilt and personal shame are woven into the fabric of religion, parenting, management and law, it is hard to imagine an effective way of getting things done without them. It’s hard to imagine how anything lasting and good can come out of an organization that proclaims, “We never want our people to feel bad about tasks where they have underperformed.”

But that’s exactly what we are called to do in a systems theory view of productivity. Rather than focus on who did what wrong and how bad they should feel, we focus on the whole system. We ask, how has the system failed us? Starting with the assumption that everyone wants to do a good job, we ask the question, “How has the system made it difficult or even impossible for them to do good? How has the system failed to support the individual success of the players?” In all fairness, not everyone will be a good fit for your new non-blaming organization. However, addressing that does not require blaming anyone.

Once we are free to look at and address where the system has failed us, we can let go of our blame and resentment for our co-workers. I propose that we need blame. We are meaning-seeking creatures and as such, we need to blame someone or something for what went wrong. Blame people and you demoralize them and make them afraid. When you blame the system, no one gets hurt and things gently improve. Blame yourself too much and you get depressed. Blame the system and you stimulate the problem solving abilities of the group. Let’s put the blame back where it belongs. It’s no ones fault how the system currently works. It just sort of turned out that way. Our job is to improve the system while honoring those who work in and around it. Let’s all just blame the system.

This has been a gentle introduction to systems theory, with brief reference to W. Edwards Deming, father of Total Quality Management (TQM). #PLENK2010

Stupid User Syndrome

If you do technical support for a user community, you have probably had to contend with stupid users. I use that phrase in the most affectionate way. These are users you have to explain things to over and over again. Others don’t want to listen to the end of your explanation. Some even assure you they know exactly what to do and then do something different. And some ask questions that you can’t believe. Mostly they just waste your time.

While you occasionally question your own abilities, you quickly reassure yourself that you are a strong support tech. And, as much as you’d like to take it out on the users, you slowly come to terms with the sage advice to, “Suck it up and bear the discomfort.” But even such sage advice does little to alleviate the fatigue you regularly bring home.

So where do stupid users come from? Is it a simple bell curve distribution? Or is there a school they attend to develop their particular brand of not learning? Is it an issue of different learning styles, which means I will have to learn to do educational back flips to give these people a clue? Maybe it’s my karma. But I’m really such a nice guy in this life. Isn’t that worth something?

As it turns out, there’s a formula for calculating where stupid users come from. It has 3 variables, so it’s kind of complex. But if you work in tech support, you certainly have the ability to do the math. Here it is. Preponderance + Propensity + Jokes = your score. Preponderance is the number of stupid users you have in your organization, measured by percentage. So if you have 50 users and 10 of them are stupid, you have a Preponderance score of 20%. Propensity is a measure of how likely you are on average to return home still upset or wearied by your users. This is a percentage too. So if you come home one day out of five still upset about stupid users, that would be a score of 20%. Jokes are the number of jokes you tell or overhear in a week at the expense of your users, whether in their presence or not. This is a raw number per week.

Add these two percentages and your Jokes per week and you arrive at your score. If your total score is less than 5%, then your stupid users come from the luck of the draw. Count your blessings and do your best. If your total score ranges from 10%-45%, then your users come almost entirely from your imagination and your own sense of victimhood. If your number is over 45%, I have good news for you. It’s not your fault at all. You’re in the wrong profession. Find a career that makes use of your intellect, but one that makes no demands for compassionate customer service and you’ll do just fine. If, however, you are sure that you can’t possibly change careers, then see category two(10-45%). You really are making it up. Now I know what you’re thinking. What if your score is between 5% and 10%? As it turns out, we have no data on that. No one has ever registered a score in that range.

Stupid user syndrome is what happens when your tech support people think it’s the user’s job to make their job easy. The syndrome shows up in companies where support techs love the technology and easily learn the ins and outs of the system. Because of this, they have very little understanding of, or compassion for, the varying needs of typical users. They make the assumption that others are just like them, and that this task the user is working on should be simple and quick. They also assume that like themselves, if you give users the barest outline of a fix, they can connect the dots for themselves and run with it. There is also a managerial component of wanting your techs to fix problems quickly and often.

Let’s get serious here. What is missing in this short-sighted approach is three things:

1. an awareness of the Pygmalion Effect.
2. an understanding of Instructional Design and
3. a familiarity with Systems Theory. If we are not viewing the organization as a system, then all we are left with is blaming the users.

The Pygmalion effect is when students either rise or fall to the expectations of a teacher. When you treat users with contempt, even veiled contempt, they become self conscious. That produces bumbling, slows down the fix and interferes with learning, which seems to justify the label of stupid user. When next you meet, you are both primed with the label. They expect you to be short and irritated. And you expect them to be bumbling. Self-fulfilling prophecy. Having contempt for any user who is having trouble understanding something can turn him into what we might later call a stupid user.

Good instructional design starts with a goal of competency-based training that is easy, fast and fun. If we design our training appropriately, users will learn and do the task. If users don’t learn, then the design has failed. And while that certainly happens sometimes, starting with this assumption results in far better trainings. To those who object and say that we are in tech support, not training, think again. A great deal of your job in tech support is (or should be) training, even if only in short bursts. Your job is not simply to fix the problem, but also to reduce the chances of that problem showing up again.

Systems theory would suggest that if some percentage of your users are doing things you don’t want them to do, then the system itself is broken. Drawing from the works of C. Edward Deming’s TQM (Total Quality Management) and Peter Senge’s Learning Organization, we can stop blaming users almost completely and spend our time creating a healthy system that actually works.

While tech support people are rarely expected to have expertise in instructional design, having them understand this perspective can lead them to a fruitful search for simple ways to make learning easier. And rare is the tech support person who has any understanding of systems theory, especially as it relates to the organization. But starting with the simple goal of reducing the chances for error leads to a whole array of easy guidelines that can improve the system. Examples of reducing user error include: FAQ’s, a Buddy system, mentoring, checklists, videos, easy-search help docs and restructuring the work flow of a task. These supports are not hard to deliver if you start with a healthy goal and there are lots of blogs that offer tips to support you.

There are no stupid users, only unenlightened tech support people, who may or may not be in the right job. As tech support staff, it is our job to be of service. The better we get at that, the more our users will shine, making us look good. And the sooner it becomes their job to make our life easier.

Resources

http://www.hci.com.au/hcisite2/articles/deming.htm Deming’s 14 points
http://www.infed.org/thinkers/senge.htm Peter Senge and the Learning Organization
http://managementhelp.org/systems/systems.htm Systems Thinking (plus a nice collection of management articles)