Not Just Gamficiation, but Teamification

There was a post over on Boy Genius Report about a sales manager who used fantasy sports to improve individual AND team performance. This was shared with me by a close friend with a thought exercise - "Which of the techniques could be used in other industries with similar success. Ex: Coding, Recruiting, Data Analysis" The gist of the article is using fantasy football style statistics collection and reporting to create a result-reward cycle in a sales organization. The critical bit that several of us pulled out of the article was that managers could draft "fantasy teams" of sales persons for the seasons. It was these teams whose synthetic scores were visible across the organization and not those of individuals. Individual statistics were only visible within teams. This method was coined as "teamification" and seems interesting since it relies on publicly demonstrating.

Enough background let's attack the thought experiment.

Synthetic Scores

One of the requirements in the article is a synthetic score that can be used to rank teams. In the sales organization they were able to use metrics on calls, conversions, etc... Everyone was effectively doing close to the same thing and so everyone's efforts were both measurable and comparable.

Using online games as an example for similar synthetic scores, a guild (team) might have a level, some valuation of their assets, renown for doing things, etc... Generally these values being higher means that a guild is more successful and thus you can use this as a metric to compare and pick the "top teams". These synthetic scores can also provably create negative behaviors as well. For instance, there may be game provided ways to increase renown or reputation that are more efficient (thus more lucrative to the players/guilds) but less valuable to a yet larger roll-up (guilds are likely in some faction or alliance against some other similar grouping of guilds). Guarding a castle on the frontier for little renown while other guilds are not helping and are away doing instances can be quite an interesting and frustrating night on the server ;-)

So let's apply the synthetic scores to the proposed areas:

Coding - More generally software engineering, has a ton of data metrics that we can track, but NOBODY agrees on what a developer should be measured on. Positive measures like bug fixes, lines of code, code review defects found can be hard to agree on. More code is not necessarily better code, while not all bug fixes are the same difficulty. Negative measures, like defects introduced per k-loc, over/under on costed work items can be even worse and lead to "overly safe costing" or lobbying for less complicated tasks.

Recruiting - This has strong synthetic scoring potential. A hire is a hire, and while there will be some argument on the quality of a hire, this will generally be vetted during the hiring process. There is a built in validation phase (by the team who is accepting the incoming hire) that can be used to stabilize the synthetic score. In this case the simplest score is number of hires. The team spin is that acquisition of a hire will have many phases which will enable multiple team members to all contribute at their best. Whether it be technical screening, talent spotting, selling the hire on the package, etc...

Building the synthetic score will be more effective in environments where all "players" can agree on what is a correct measurement for the area. Using a synthetic score is likely to not work well when the metrics can be gamed too easily, there is no validation of quality function or there is a lack of general consensus that the metric being measured is even valuable.

Seasons

In the article there is a period of measurement that helps to build on this idea of using fantasy teams. In sales there are well organized sales seasons. They might be around the introduction of a new product, a flash sale on a discontinued product to reduce inventory or even a universally observed time period such as a holiday. Not to be overlooked, this is a very critical aspect of gamification on a large scale so we have to apply it to our proposed areas.

Nearly every major competitive eSport has seasons (I'd say all, but some appear more organized around specific yearly tournaments, than on a true season). LoL or League of Legends is a poster child for showing how seasons work. First, they establish a fixed period of engagement to which a player will have to agree. Not lasting through the entire period and quitting early results in degrading in the rankings. Also, staying on top of the leader boards or getting to the top is not something that one can do simply by popping in at the end. You'll simply lose to the better more experienced players who trained throughout the entire period. Second, the organize seasons into general performance play that ends up in a final record. Once the general season is over, you play in brackets and the emphasis shifts from consistent play game to game, reducing injuries (burnout), etc... into a more highly skilled, risky, burst style of play for the end. This later part gives everyone who makes the finals a chance to win regardless of their past play and entices them to work harder at the end. For LoL, this obviously means higher quality games, more viewers, more excitement and more money. To the tune of billions of dollars. For the sales organization this means a really good month ;-)

Now let's apply seasons to our proposed areas:

Coding - So software does have seasons. In fact, you could argue that Agile and Extreme and other types of planning and team execution processes that stepped in to replace the older waterfall models, was a form of gamification of the software process. This even shortened the seasons to reasonable periods of time that a software engineer might want to dedicate their full attention to. We can also break down our work into coding, testing, bug fixing and planning periods, which together could represent different quality metrics within a given a season. What we lack is the final brackets, which means we can't get the added benefit and burst from the playoffs and grand master finals. At least I've never seen a manager willing to play their teams against one another in the end game of a software product. If you have feel free to let me know how it went!

Recruiting - Hiring certainly has seasons. While you can get some free agents during the seasons as people change companies. Most hires are from college and there are fixed periods of college recruiting and internship. At least in fields whose primary injection of talent is from university. You can even arrange your seasons to maximize for a playoffs and finals. 2 out of 2 for recruiting, they should probably start building fantasy teams immediately ;-)

Data Analysis - I didn't talk about data analysis in synthetic scores because it seemed obvious. Everything in data analysis is pretty much scorable. It is also easy to organize seasons because you can manage when and how datasets are provided to the teams, how long they have to provide insights, etc... I would say of the proposed areas data analysis is already a game waiting to happen. Note: I'm kind of cheating here, if you frequent PAXDev or GDC or some other game development conference you'll find several enterprising game designers talking about data analysis insights. Coincidence? I think not!

Seasons are going to be the easiest bit of organization you can do since it falls into your standard scheduling practices. It might require some clever insights in order to create play-off and grand master finals experiences (yeah, I'm going to keep calling it grand master finals, because this is a gamification article and the winner MUST get a super cool name).

Teamification

So the final bit of this story is really whether or not you can structure your event to promote this teamification concept. Per the article, teamification is supposed to create an environment in which the transparency impacts of revealing everyone's performance numbers, doesn't negatively impact the low performing team members. By rolling up to the team level, there is a friendly and social opportunity for the team within to help the lesser performing individuals.

In practice, you will have to do quite a bit of work to ensure this is true. In most cases the statistics which play into the scores are easily available to everyone in the organization. In software we have the ultimate transparency. I know how often you check in, how many bugs you fix, how many k-locs you add/delete. It is all stored in the source history and there isn't much you can do to hide it.

In a sales organization, you can potentially hide some of this information from everyone except for the managers and direct team members. Similarly for recruiting, the hiring records can also be kept within teams until the end.

One thing I like about the promises of teamification is that we form our world views based on our interactions within our team. We very rarely come up with new principles and practices in a vacuum. It takes many people trying them out to validate them and often it takes quite a bit of support. For example, in coding, test driven development is a very strong practice. But if you are not good at testing, and you don't have anyone near you who is, you aren't going to be very efficient at TDD. In fact, you might shy away from writing tests. You might even be the top coder for a bit. And then you are going to be the top of the bugs introduced list and the owner of the most buggy features. The places where we need teamification can often be the places where it is hardest to introduce the concept.

Quick Wrap

If you want to elevate your team through gamification practices, you certainly can. It can be as simple as a synthetic score, a schedule (season) and promoting either individualized or team based statistics and results. From the original article, one major takeaway for me, is that designing the experience around teams instead of individuals can be extremely powerful. It requires a slightly different design and may even require some sportsmanship (stop running private bug queries) to pull off, but the positive social impacts are pretty clear. Engaging employees who shy away from competition and elevating the lowest performing members within a team to do their best is one sure fire way to build a stronger organization.

Live Streaming at Work to Augment Training Videos

So over the years my team has done a lot of training videos. We generally do them between major releases. Mostly one hour presentations on a major architectural area and as such are complicated to put together and not in-depth enough to be considered for training a new team member in that area. To be more precise, they are videos about the previous versions architecture and are always done after the fact. This is a good way to archive knowledge, but it also has a lot of downsides. The biggest downside in my opinion is their scheduling as most videos are made later than when I need them and they are generally out of date as soon as they are published and even more so 6 months later once we've changed huge pieces of architecture again.

So how can we reduce the cost and make them more timely? Or rather, could they be more timely IF we reduced their cost and where do the costs come from anyway?

The Traditional Talk

Recently, since we just had the GDC, I've been following a lot of people talking about how long they spent on their slides and the processes they went through. Those were also one hour talks for the most part and they constituted a bunch of information that you have to get out in a set cadence. You also have to demonstrate some showmanship and thus take time to slip in jokes and other form of entertainment to keep people from snoring. Once of my development managers once told me, that for every hour of talk, he generally set aside 10 hours of preparation. That is for an ad-hoc internal talk. The amount of time you spend increases dramatically the larger the audience and the more formal or upscale the setting is.

Your talk will often go through many stages. Outlining to start, to get a rough feel. Then creation of slides. Then creation of resources for the slides like source code, graphs, graphics, etc.... Finally timing of the slides to make sure everything fits. You'll probably go through the same process a couple of times to come in on time and to make room for your wow factor moments. 10 hours, at least, to prepare a 1 hour presentation seems like a bit much. This doesn't even count the actual hour, the AV setup before hand, practicing the talk, and other preparations which are nice to do. When you are done, if you are lucky, someone will have taken solid audio and video of the presentation and you'll be able to grow your impact from the 100 or so people in the audience to a few thousand.

Live Streaming

This is the opposite of the traditional talk. Here you stream everything you are doing live. You stream your voice live. You might even stream a webcam of yourself live as well. Whatever you do, people get to see that happening. This is popular among eSports players who spent copious amounts of hours demonstrating their game playing abilities online and having hundreds or even thousands of people watching them, supporting them and most importantly learning from them!

Oddly the showmanship and presentation of these talks is quite high. The chat comes across as quite natural since the casters as they are called get used to having a live audience and become comfortable and focused at presenting themselves.

Some hacker spaces are now live streaming their hack-a-thons. This is less eSports and more code related. During Ludum Dare hundreds of developers live stream their entire creative process, recording it while they go, and later providing amazing time lapse creations of the 48 or 72 hour process. While there is a Ludum Dare coming up, if you would like to see a game made in real-time you might want to check out a very popular stream called Handmade Hero.

With proper recording of these sessions, all of my complaints about long presentations are resolved. Recordings are about the now and are focused on the latest state of your project. No preparation is required other than a microphone and some screen recording software. You can generally go from recording to publishing in just a few minutes after your talk is done. The recordings can be done in smaller increments. A collection of 5-15 minute videos may be far more valuable to your team than a 1 hour architectural video.

Preparing for Live Streaming

To prepare for live streaming I pretty much suggest following the way of the eSports casters before you. They already know how to do it consistently day to day, hours at a time, and make a small living off of it. So if you can do half as well as them then you are probably in good shape.

Start yourself off by figuring out your software. There are two great pieces of software for this that I've found. The first is OBS or Open Broadcaster Software. This can be optimized to stream up to a service like Twitch/YouTube or you can have it record to disk for later upload or editing. The setups on this software are super simple. You basically set up a scene or scenes, then you set up some sources which can be as simple as a static image, a browser, a web page or just a normal window. I tend to stream a Remote Desktop instance running at the resolution of the video that I'm taking. The microphone setup is pretty much automatic. If your mic is plugged in, it will just work.

The second piece of software is Camtasia. Its expensive, at around 300 bucks for a license, but I think the cost is worth it if you want to do a lot of post production on your video. I tend to use it to show fixed slides that I then "extend" to the length of my talk time. That way I don't have to match slides and audio in real-time. But hey, that isn't live streaming and we want to reduce the cost right? Right! So grab something like Camtasia later once you've had some fun with OBS.

The last step is that you'll want a really good microphone. The last thing you want is your voice to echo a bunch, not get picked up, or be terribly out of level. You'll also want to make sure that it comes in loud and clear over the ambient noise in your room. I'm using the CAD U37 USB Studio Condenser Recording Microphone and so far I'm super happy with it. Most likely the best 40 bucks I've ever spent. There were a lot of recommendations for a headphone/mic combo set and I don't recommend those at all. You tend to fiddle with them a lot and get caught up in the wires. You want to be comfortable. With the CAD mic you can walk around and talk from anywhere in the room if you feel like doing that.

Upload Your Videos

The software is literally that easy to use, so once you have your videos you can start uploading them to your team. I just make mine available on a share and send some links. If people have questions they can ask and maybe I'll post another short video. I can create training for new problems, problems that happen that day if I want, and then make that available to the team immediately. This sure beats the 1 year turnaround from before.

I was thinking of creating a short live stream of configuring OBS and some of the other steps in the process, but honestly the Internet beat me to it. Every question I could ask on OBS has a video tutorial already online that you can view that will step you through it. Setting up OBS, hooking it up to Twitch or YouTube, and even a short video on how to switch from FLV to MP4 output (you literally just change the file extension) was available and done by an 11 year old kid.