What can the 1982 Video Game E.T. teach us about Employee Learning?

One of the ways I enjoy learning is by trying to find connections between two seemingly unconnected and unrelated things.  I find that the process of building these connections very often opens my mind to possibilities I had not considered before.  

I often do this with learning, asking myself the same question: What can 'XYZ' teach me about learning?  The fun of it is that 'XYZ' can be anything, and the more difficult it is to build the connections, the more enjoyable and valuable the experience can be.  

Recently I explored the connections of employee learning with the critical and commercial success of the video game Angry Birds.  In that post, found here, I discussed many of the aspects of Angry Birds that made it a successful video game, and how those same principles can be applied to employee learning.

It's said that for every action, there is an equal and opposite reaction.  If so, for every blockbuster hit like Angry Birds, or there must be an equally colossal video game failure.

And there is.  Any discussion about video game failures must include the 1982 game for the Atari 2600 video game, E.T., The Extra Terrestrial.

This reference may seem a little obscure to some, as the Atari 2600 game E.T. is nowhere near as ubiquitous in 2011 as Angry Birds.  So let me give a little background on this game for the uninitiated.

E.T. The Extra Terrestrial is a game for the Atari 2600 video game system based on the classic Steven Spielberg film of the same name.  The film was one of the most successful movies of all time, and the Atari 2600 is one of the most successful video games systems of all time.  The game was released during the holiday season at a time when the system and video games in general were very popular. 

It seemed like the perfect combination for a very successful game, and yet it turned into what one of the biggest commercial failures in video game history.  The story of this game is fascinating, ending with the video game crash of 1983, and millions of copies of the game famously dumped in a New Mexico landfill.  If you're interested, you can check out the full story of the game on Wikipedia... after finishing reading this post of course.

Despite the fact that this is the second post I have written in a week's time with a video game as part of it's topic, this blog is not about gaming; it’s about learning.  My posting last week regarding Angry Birds explored what a successful video game might teach us about employee learning.  This week's posting is similar, with a more cautionary tone.  Let's explore why this game failed, and how we can avoid having our learning programs suffer a similar fate.

Point #1: Remember (and Respect) the Time-Cost-Quality Triangle

When something is being produced, there are three measurements related to the production: Time, Cost, and Quality, as demonstrated by the triangle on the left.  The basic idea of this triangle is to show the connectedness of these three measurements, and the fact that you can not improve one measurement without adversely affecting at least one other.

Atari signed a license to create a game based on E.T. in the summer of 1982, right around the time the film was a blockbuster in theatres.  Because they wanted to release the game for the 1982 holiday sales season, the developer assigned to the game had only six weeks - a ridiculously short development time - to create the game so the cartridges could go into production for the holidays. 

The need to have the game delivered quickly increased both the Time and Cost factors.  When two sides of the time-cost-quality triangle are increased, the third side must shrink unless the overall scope is changed.  In the case of E.T., the costs and time sides of the equation were getting all of the attention, and with Atari not willing to change the scope of the game project, the game's quality suffered immensely.

In the world of employee learning, many times the timeline for delivering a solution consists of a single word: Yesterday.  Do we and our stakeholders understand this paradigm when we set project timelines? 

There's a bit of a paradox here.  One one side, you have the stakeholders who want a quality program that effectively addresses the desired performance needs.  One the other side, we have the L&D group, who often deliver the programs we can, rather than the programs we should, because the constraints of the project (low budget + quick turnaround) limit the degree of quality that can be delivered.

Why does this happen?  Quite simply, because L&D professionals are not having the conversation in which they say "The constraints of the scope are going to affect the overall quality".  That may sound like a difficult thing to say, but it's really not if you position it correctly. 

When I'm faced with these situations, I almost always preset my solutions with this flow: "Here's what we ca do based on the existing scope; and here's what I think we should be doing that will better address your needs."  That flow almost always results in the stakeholder saying "Well I want the second option", which is exactly what I planned for them to say.  That opens the door for me to say "Then we need to reexamine the overall scope."

Point #2: Never Skip the Testing Phase

Atari needed to deliver the E.T. game very quickly to get it on store shelves in time for the holidays.  When a project has more work then can be completed in the allotted timeline, you have two options: Extend the timeline (which is preferred) or eliminate non-essential tasks.  'Eliminate non-essential tasks is a euphemism for 'cut corners', ad that's what Atari needed to do in order to deliver the product by their own assigned deadlines.

I'm not completely opposed to cutting corners.  Cutting corners all the time is an issue, as is cutting corners as a response to poor planing.  Occasionally you may need to cut corners to adapt to unexpected shifts in the business needs, and while that may not be ideal, it's realistic.  When that happens, you need to be very careful to cut the right corners.

One of the stages of development that Atari cut was the actual testing of the game.  That turned out to be one of the biggest mistakes Atari made.  The game shipped with a number of bugs and more importantly, gamers found it frustrating and boring.

Do you test your learning and performance programs?  You should, regardless of the medium.  A live workshop should have a pilot; e-learning should be tested for both technical functionality and effectiveness before being launched; even a simple job-aid should be submitted to a member of the target audience before being publish or distributed.

Testing is critical to any production cycle, and is a stage that should never be skipped.  Doing so, in learning and development or any other field, creates a serious risk of an inferior product and diminished reputation.

Point #3: Even the Best Content can be Meaningless within Poor Design

To many, E.T. is one of the greatest films of all time.  It had a great story, endearing characters, and was kid-friendly. In short, it was great fodder for a video game.

None of what made the film so endearing transferred into the game.  Why?  The design of the game missed everything that made the movie a hit.  The story was absent, even when judged by the low bar set by Atari 2600 games.  The low-quality graphics (again, even judged against Atari 2600 standards) did not allow any of the characters' personality to show.  Worst of all, the gameplay was monotonous and boring. It did not share the arcade action that was common in that time, instead focusing on a recovery mission approach that was completely lost on it's target audience.

This same problem exists in learning and performance programs.  You can have content that maxes out the scales in terms of importance and relevance to an audience.  If that content is buried in a program that is poorly designed and does not engage the audience, the knowledge and skills associated with the content will not likely transfer.

NOTE: It is often said that the developers of the E.T. game actually did a very admirable job of design considering their six-week project timeline. Whether you agree or disagree with that is immaterial  That's a discussion of the skills of the designer.  If you take the finger of blame and reasoning out of the equation and look solely at the design of the game, it can not be denied that the design failed to deliver on the potential.

Point 4: Repetitive and Monotonous Activity is not Engaging

As was stated earlier, the gameplay in E.T. (when it worked) was extremely monotonous. It consisted of walking around and intentionally falling into holes to see if one o the missing pieces of his machine is there.  If it was, you walked into it to pick it up and climbed out of the hole.  If it wasn't, you still climbed out of the whole.  The you repeated this process until you found all the missing pieces.

Once you were able to find all the missing pieces, there was another step to get to the end of the game.  Unfortunately, (or fortunately, depending on your point of view) most gamers never saw this ending.

It's not as if the game was so challenging that players could not finish it. Gamers couldn't bear to finish it.  It was excruciatingly boring and worse, had bug-ridden controls.  Most players turned off the game long before finishing it.  In truth, many customers returned the game because of how disappointing it was.

How many of our learning programs do people 'check-out' of while still engaged in it? Are we designing learning and performance programs base on content delivery or engagement?

Think about your programs for a minute.  In your live workshops, do you shift gears every ten minutes or so?  Do you have engaging activities planned for after lunch to combat the post-meal desire to take a nap?  Do your e-learning follow the same template that gives learners an almost identical experience each time with different content?  Do you incorporate different types of activities to engage.  And really... is some of your e-learning still a book displayed on screen with a NEXT button to turn the pages?

Learners have a choice, just as the players of E.T. did.  The main difference is that learners can't return our programs back to the store, though maybe they should have that right.


Point #5: Even Horrible Mistakes have Value if they Result in Actionable Learning

A great deal went wrong with the E.T. video game.  By almost all measurements, the game was a colossal failure, and is widely accepted as one of the worst video games in history.  Had Atari and the video game industry looked at the game and said "What a mistake!  Let's move on and hope that never happens again!", the game would have almost no value to it.  That's not what happened.

There is value in making mistakes, if you allow yourself to learn from them.  That's just what happened in the case of E.T. the video game.  Many of the accepted practices in the video game industry of today originated from this colossal failure.  One example is how a company's now handle licensed games based on movies.  These deals are now signed well in advance so that proper time is allocated to design and development.  In addition, game companies and movie studios often collaborate to create a better product.  E.T. the video game crashed and burned brilliantly, and from it's ashes stronger and better practices were enacted that in many cases stand to this day.

Learning and performance programs sometimes fail.  Even if the overall program succeeds, there are usually mistakes made along the way.  We should always be taking the time to reflect on our programs, and especially our mistakes.  These mistakes have tremendous value if we allow ourselves an opportunity to reflect in them.

As you can see, there are a great number of parallels between the 1982 video game catastrophe, E.T. and the employee learning and performance culture of today.  Do you see other connections between E.T. (or any failed game) and employee learning and performance not mentioned in the points above?  If so, please add them to the comments section below.