|Ogilvy Notes - Don't Shoot The Player|
Here are the key nuggets I hung on to afterwards.
So what does "don't shoot they player" mean? What Katie is referring to is an experience the Portal game designers had while play-testing an early level design. While players were trying to learn a new skill introduced by the game, the designers had added some turrets to shoot at the player. The play-testers literally couldn't see the exit because they were being over loaded by both trying to learn a skill and dodge incoming fire. They became frustrated and few could get past the level.
The lesson here was this: when learning a new skill, people need a safe zone to do it in. They need to be able to fail at the task until they learn it. Then you test them on the learned skill under fire and allow them to apply it.
That is what games are, afterall, right? From Chess and Checkers to World of Warcraft and Call of Duty, the game is a series of learned skills and those players who master those skills the best play the best.
Furthermore, that's what work is, right? It's a set of learned skills applied for the support of a company, business, or group of people in exchange for compensation. Ideally, those who perform the best on a wide set of skills are the people who are compensated the best.
What we learn from game design can be applied to our workplace.
Also, the game designers found that they could not create a level too hard for two players to solve. When two people are working together one person takes the cognitive load while the other follows along. When the first person becomes tired, the second person takes up the cognitive load. The two individuals alternate, meaning nearly full concentration is always applied to solving a problem. They learn from one another's attempts and experiences together.
This concept of learning together is key. In Katie's words: "learning is social".
But for some reason, we teach in our schools that sharing is cheating. Does the workplace reflect this? Do we not share what we've learned with one another? Sites like StackExchange are built purely around the sharing of lessons with one another. Opensource theory is all about sharing code and components with one another. We learn from one another's accomplishments, incrementally improving products in doing so. We pair the less experienced with the more experienced to share skill sets and bring people up to speed quicker.
Collaboration is key and we should be embracing it in our workplaces and in our schools. We are social animals that learn best from one another's experiences and mistakes, not just our own.
An intriguing experience Katie also shared was the concept of rewarding good failure. This isn't meant in the sense of "Dodgeball with no outs". This is meant in the sense of a person or group of people striving to achieve a goal and missing it, but in missing it they learned some critical lesson. Learning is more about failure and trying again than it is anything else. A company Katie was exposed to had an award for the group who had the highest aspirations but missed the mark. Maybe they failed due to execution or lack of technology or funding or some other thing, but in the end, they learned a profound lesson to be shared with everyone else in the organization.
This brings us back around to not shooting the player.
- People need safe zones to learn skills in, then chances to apply them.
- Learning is social. Remember this piece: there was no level hard enough that two players couldn't solve.
- Rewarding lessons learned through failure is as important as rewarding success.
I had a realization while listening to Katie speak regarding our hackathons here at the office. A hackathon is a great place to employ all three of these concepts. As great as that is, I feel there is plenty of room for application in the day-to-day work experience.
What would you apply with your work or children? Is there a key concept you find that stands out to you? Feel free to comment below or leave a G+ comment/message!