Companies with the newer “sharing economy” business models are gamifying work. They are making people work hard in ways that resemble how they play video games.

To better understand this, I compare their models to the components of a game as given by Reality is Broken by Jane McGonigal:

Goal: A game has a very specific outcome, a sense of purpose. Where as at work you might wonder what the purpose is, in a game it’s usually very clear what you are trying to do.

Rules: In a game there are clear limitations on how you are supposed to accomplish the goal. These limitations make it really clear where people can experiment encouraging creativity and strategy. At work, the limitations are often not clear. Maybe you can ask for more budget, maybe another department will help you, maybe …

Feedback system: all games have a scoring system or a way of knowing how close you are to the goal. I think this is often the most missing thing at work, especially if you don’t have a clear goal (besides making money).

Voluntary participation: everyone who is playing the game knows and accepts the goal, rules and feedback. This allows people to play together and makes it safe and fun as you always have the freedom to leave.

Companies like Airbnb and Uber have all these components, and people have fun trying to see if they can gain new levels and statuses. I recently talked to an Airbnb host who is obsessed with making “Super Host” status.

Here’s how these new sharing economy models compare to games.

A goal. With the sharing economy businesses, your goal is very clear. With Uber you want lots of rides, or maybe money from rides. With Airbnb you want lots of guests. The goal, what the business and the app are all about, are obvious.

Rules. With the sharing economy businesses, the apps make it very clear what the rules are. They make it clear what you are supposed to do. For example, pick up a client at this address and take them to this address.

Feedback. Both of these systems, and many like them, excel at feedback. Uber has every driver and every rider rate each other before they are allowed to do anything else. Airbnb works hard to get people to rate each other and gives Super Host status to those that maintain high ratings. At Grace Hopper, I went to a talk by an Airbnb data scientist where she talked about the ways they try to make feedback more honest. They’ve made lots of changes (like not letting hosts and guests see each others’ reviews until after they both have left one) to encourage more and more honest reviews.

Voluntary participation. As long as people participating in Airbnb and Uber are doing it as supplemental income or as long as there are alternatives like HomeAway.com and Lyft, people can leave whenever they want. I tried driving Uber one afternoon and decided it wasn’t for me. The “game” is fun because the people playing it got to choose to leave if they didn’t like it.

What do you think? Do you think the new “sharing economy” businesses are gamifying work? Is that making the world a better place? Should traditional businesses try to gamify work as well?

Last night at kickball, a young woman on the other team decided to start bunting and she changed the preferred strategy for women on both teams. She was a strong player and she obviously thought her best option, maybe her only option, was to bunt. So quickly the feel became, to be a “team” player, all weak players should bunt. Never mind that by bunting you give up all chances of kicking a home run or even a double. Or of feeling proud of your kick.

She kicked a few good balls early in the game but got out on the way to first. So the next inning she decided to take advantage of the rule that helps weak kickers, and she bunted. There’s a line between first and third base, through the pitching mound, and no fielders are allowed in front of that line until the ball has been kicked. Pretty soon, the weaker players on her team (all women) were also bunting. Then the women on my team debated whether they should bunt. Then the stronger players on my team started encouraging the weaker players to bunt! That’s when I got upset. Upset at a world where teams encourage newer and weaker players to avoid risk, and therefore to avoid the chance to grow.

This is rec, co-ed kickball. Most of us haven’t played kickball in decades. Many of us haven’t played a sport in years. And several people don’t know the game well enough to know where the play is. The umpires are awesome. They encourage and help everyone. In addition to their umpire role, they often play surrogate coach and cheerleader. They don’t just say “1 out”, they say “1 out, play is at first”. And they check in with players. I think last night’s umpire could tell I was getting really annoyed. He checked in with me to make sure I was alright.

I remember learning to play kickball. It was a new school and a new sport. After my first “at bat” it became very clear I’d never kicked a ball. So my next at bat, everyone moved in for the kill. I had a wall of fielders all 10 feet from me. There was no where to kick the ball. So I love the rule that no one can be in front of the line until the ball is kicked. Rules that help new or weak players get started are good. When experienced players use those rules to their advantage, you end up with politics.

You end up with people examining all the rules to see where the loop holes or advantages are. Last night we ended up debating how many men could be on a team, what order they could kick in, if you could rush the ball once it was bunted, … and it became about the rules and winning, not about the game.

My emotional reaction was out of proportion for a kickball game. But it’s because I realized that I see this in the world all the time. When someone who is clearly capable says “oh, I could never do that”, they make all those people that are still learning doubt their abilities. When you turn down that client presentation or that keynote, when you start your piece in the meeting with “I’m not sure but …”, you show that you don’t think that you, a competent, experienced person, should take that risk. And when you combine that risk aversion with a do what it takes for the team to win, you cripple people. You end up encouraging your newer players to not take any risks for fear of hurting the team. Some times an individual has to take one for the team. Some times the team has to take one for the individual in order to grow a strong team.

While each individual has to decide on their own whether a risk is right for them or not, the team needs to watch and make sure that risk aversion isn’t becoming the norm, enforced by peer pressure, for their newer or weaker members.

Kick hard. Work hard. Take risks. Learn. Make mistakes. Help others make mistakes. Cheer them on. Grow your team. Be a role model.

Many open source organizations start around code. Someone has an idea and they write some code to express it. If people like the idea, they add more code. That code gets reviewed and incorporated.

This works great while the project rallies around the original idea. However,when they go to add new products or plan new features, the culture of code reviews gets in the way of a culture of new ideas.

Why’s that? Because code reviews look for flaws. You need to make sure you don’t introduce bugs. Ideas, on the other hand, need a whole team of input before they are strong enough for the risk analysis. New ideas get stronger when people add to them, figure out ways they can help. Once ideas become a plan they need something like a code review but not before they become a plan.

Reviewing Code is about Eliminating Risk

When new code is submitted, it’s always reviewed before it’s accepted. And often there are very clear guidelines. You are reviewing to make sure that your project’s guidelines are met, that the code is well written and that it introduces no new bugs. Often this means you are looking for things that are wrong. You may also suggest improvements, but the focus is on looking for things that are wrong.

Reviewing Ideas is about Exploring Opportunity

When new ideas are reviewed, they are often not fully formed. Ideas, especially new product ideas, need the entire organization to help figure out the full potential, what each team could bring to the table and how people might react to it. New ideas need to be fully developed before you start poking holes in them. And new ideas cannot be fully developed by one person. They need a whole team of people to say, “yeah, that’s great, and I could help by linking it to this other thing I’m working on” or “yeah, I like that and it makes me wonder if we did this, if that would be even better.”

What happens when you apply code review techniques to ideas?

When you apply code review techniques to ideas, you kill them before they are fully developed. You look for everything that is wrong in an idea. You look for all the risks, all the holes, before you add your strengths to it. Just when the idea needs you to help figure out how it could succeed, you poke a hole in it.

Next time you see someone in your organization propose an idea, make your first reaction an additive action. Challenge yourself to make the idea even better instead of looking for the bugs.

Many app developers are secretly hoping to win the lottery. You know all those horrible free apps full of ads? I bet most of them were hoping to be the next Flappy Bird app. (The Flappy Bird author was making $50K/day from ads for a while.)

The problem is that when you are that focused on making millions, you are not focused on making a good app that people actually want. When you add ads before you add value, you’ll end up with no users no matter how strategically placed your ads are.

Then monetize. (You can think about this earlier but don’t focus on it until you are doing well.)

If you are a good app developer or web developer, you’ll probably find it easier to do well financially helping small businesses around you create the apps and web pages they need than you will trying to randomly guess what game people might like. (If you have a good idea for a game, that you are sure you and your friends and then perhaps others would like to play, go for it!)

Do bribes or fines work in your work culture? When your culture changes, some of it will feel like bribes and some of it will feel like fines. It all depends on your cultural background.

I was recently in a small town in Mexico and the (new) city government was explaining to us the changes they were trying to make. At first, I was a bit baffled about why they were spending so much time explaining how things worked. They were explaining how if you damaged someone’s property, it wasn’t that you shouldn’t compensate them. It was just that you should compensate them through a fine and a process, instead of a payoff. That it should be done through the system.

And then it clicked for me. They were trying to change their town’s culture.

The town had a culture of just settling it between the two parties. And they wanted people to obey the laws, the process and the judicial system. Where I live, it just taken for granted that if you get in a car accident, you call the police and the insurance company. Then you, the police and the insurance company work out who owes who what. In their culture, that wasn’t the way it had worked. And in order to change how it worked, they were having to explain the new system and how it worked.

And it occurred to me that the same thing is happening in my work place. Mozilla has grown from 250 people when I joined to around a 1,000 people now. And we’ve added a bunch of awesome people with varied skill sets and backgrounds in order to make us stronger. And all of us have different cultures when it comes to how things get done. Some of us file a bug for everything – even a new cable that you need or an idea for an AB test on a website. Some of us create a slideshow for new ideas. Some of us expect a discussion on an open mailing list. Some of us expect a smaller team to come to an agreement before we open the discussion wider.

Some of the ways we decide as a group to do things are going to feel very natural (why would you have to tell someone to call their insurance company after an accident?) and some are going to feel a bit more like bribes or unnecessary process. (What do you mean I have to open 3 bugs and cc 4 departments?) But together we all have to come up with our new culture.

So, back in this small town in Mexico, I ate my bean and cheese stuffed poblano pepper, covered in a sauce that made my eyes water, and nodded. What do I know about turning payoffs into fines?

Anything You Want is a book by Derek Sivers, the founder of CD Baby. Derek shares how he created a muli-million dollar company (supposedly he sold it for $22 million) as well as his philosophy around why you should start a business and how he ran a company. It sounds like he’s a pretty unique individual and some of his ideas are pretty thought provoking.

Derek insists you should focus your business on what adds value to the customer. When he started CD Baby, he was really just looking for a way to sell his music without a distributor. He ended up creating a website and setting up a merchant Visa account. (This was in 1997, pre Paypal and pre lots of web tools.) A friend asked him if he could sell his CD too. Before he knew it, he had a warehouse of CDs from independent musicians and an online business. His goal wasn’t to make money selling their CDs (although he did) — his goal was to enable musicians to reach an audience.

When thinking about your “business plan”, he recommended pushing yourself. Ask what you’d do if you only had $1,000. If you wanted ten times as many customers. If all your first assumptions were wrong. If you had to do it without a website. If you wanted to franchise it. He recommends examining your life that way too. Plan your life for the next couple of years. Then think, “Now you’re living in New York City, obsessed with success. Go!” Or “Now you’re a free spirit, backpacking around Thailand, Go!” And keep imagining …

He also has some really unique views on running a company. It’s hard to tell if his tactics worked really well or if he’s just not telling us about the daily trials; he very successfully ran a very large distribution business and he doesn’t talk much about the logistics. His uniqueness comes through in things like hiring friends of current employees without an interview process and putting the friend in charge of making sure they are trained and successful. He also worked hard to empower people. When he made a decision, he made sure to explain why so that someone else could make the decision next time. It’s also worth pointing out that he didn’t seem very interested in running a business and was very hands off. His idea of success was a business that ran itself (which seems like a great business goal!) and eventually he realized he wasn’t very interested in running it at all. He put the company in a charitable remainder trust and sold it. Now he lives off the trust and the remainder will go to music education when he dies.

The book Anything You Want is a really short read if you want to give it a try. It took me about an hour on the airplane to read and I enjoyed it.

“Where there is no competition, there is no market. This is why start-ups who “have no competition” have trouble engaging partners and making sales.” – Geoffrey Moore, Escape Velocity

Open source projects often shy away from competition. They value collaboration and leveraging existing solutions. But competition is good for more than making you run faster. Competition helps define who you are.

This is why the Nike iPod sensor had such a hard time when it came out. There was nothing to compare it to except pedometers. In contrast, Fitbit and Jawbone’s Up have met with a lot more initial success. And just about every article about them compares them to each other. (Interestingly, Nike has a new, similar product called Fuel Band that is mentioned in very few of the articles.)

GNOME and KDE defined each other by competing in the Linux desktop space. Without an option between KDE and GNOME, very few Linux desktop users would know what a “desktop” was or what part of the Linux desktop was created by GNOME or KDE. By defining each other as competition, they helped explain who they were and what problem they were trying to solve. They also constrained themselves to the Linux desktop. That was good as it let them shine in a defined space, but if they want to move to new markets – like mobile, they’ll have to be careful to define new competition to explain to partners and users who they want to be.

Firefox, Internet Explorer, Safari, Opera and Chrome have a long history of competing. They’ve helped define each other and the web.

So don’t be afraid of the competition. Choose your competitors wisely and let them help explain your story.

I recently listened to a talk by Michael Lopp about how to be a great manager.

During his talk, he stressed the importance of hallway conversations. Hallway conversations are informal conversations about projects, goals and status. As Shez says, they are great for bouncing ideas off people you might not normally interact with and just letting them know what you are up to.

Here’s how I do “hallway conversations” while working thousands of miles from my colleagues:

Chat informally. While most people will tell you it’s important to have an agenda for every meeting and to stick to it, I think that if you never see your colleagues at the water cooler, you need to build in some time for rambling. Maybe you’ll gripe about the latest project, maybe you’ll share the cool project you’ve been working on with your kids, maybe you’ll just talk about what you had for lunch. Or maybe you’ll have a great shared idea that inspires you to write that blog post that changes the whole project. It’s those relationships that enable you to informally share how you feel about the projects you are working on.

Send that trivial piece of feedback. Often I’ll send an irc message or an email that just says “I liked how you did this” or “here’s a piece of feedback I heard about your project”. Sometimes they seem too trivial for an email message. But if I don’t send the email, and I store them all up for the next time we talk in person, I might not send them at all. (I also keep a file where I keep track of things I want to talk to people about next time I interact with them. Things I think are easier to explain via interactive chats.)

Keep open channels. If at all possible, have some sort of real time channel where you can reach your colleagues. Best is a something like IRC where you can hang out and have informal chats. But if not a standing room, at least know how to find them via IM or txt messaging.

Be available. Be available in as many channels as possible. I’m regularly on irc, Skype, IM, email, txt messaging, Twitter and Yammer. And I try to respond in a timely fashion. Why? Because when someone thinks of something they want to tell you, you don’t want them to have to remember what they had to say until they get back to their desk. Right then, while they are standing in the hallway, you want them to be able to ask you “what do you think about …?” (You also need to make sure you aren’t letting your life be completely interrupt driven, but that’s for a different post.)

Get help. Ask others for help. I’ll regularly ask people I talk to what it feels like in the office or what they think about a paritcular project. What the mood is like, what people are talking about. Or I’ll say, “the next time you chat with so-and-so, can you ask him what he thinks about xyz?” I’ll also tell them I’m worried about a particular person or project and ask them to check in for me. After a meeting, I’ll check in with other folks that were at the meeting to share perceptions on how it went.

Meet regularly. If there are projects you care about, make sure you meet with the principal people on those projects regularly.

Meet in person. GNOME folks go out of their way to attend GUADEC – often taking vacation and time away from their families. It’s an important event because it’s the one time a year when much of the GNOME community gets together. Meeting people you work with in person is invaluable for community building. I love how humor in email makes much more sense after you’ve met someone in person.

Ask them. Ask how others are doing, how they are feeling, what’s top of mind, what keeps them up at night, what makes them feel so passionately that they are working at 3am, ask them … you never know what you’ll learn or what you’ll be able to do together.

Communicate effectively. I used to say “over communicate” but I now believe you have to communicate effectively. If you publish everything in the world on your blog and nobody reads it, or the important pieces get lost in the noise, you haven’t communicated. But it’s key to make sure people hear what you are worried about and the ideas you have for solving problems.

How do you effectively have hallway conversations when you don’t share a hallway with your colleagues?

Yesterday it was implied that I might not know everything about raising boys because I wasn’t in physical fights as a child. While I am sure I do not know everything about raising boys, I was startled to think that not engaging in physical fights would be a parenting gap.

I was even more taken aback to be told my career path was easier because I never had to engage physical fights. While I’m not afraid of controversy, I avoid physical fights. I consider that a wise decision that has advanced my career.

So I promised to get more data about people in “successful careers” like mine and whether they thought fighting was important or not.

I was able to find data on fighting in kids: fighting among school aged children is declining in the US. Whereas 43% of 9-12 graders had been in a fight in the past year in 1991, only 32% had in 2009. There is also a gender and race difference. 39% of boys had been in a fight and only 23% of girls.

But I did not find any data that broke down those that fought and what careers they ended up in.

So here’s a short survey for you. I will share all the data on my blog. (This survey is anonymous. I am not saving IP addresses or any other identifying information.)

I’ve spent a lot of time over the past few weeks talking about why we have so few women in open source and web development and how to encourage more women to join. (I even got to spend an awesome afternoon with a bunch of girls. I was supposed to be mentoring them but they were already Python game developers and small business owners – at the ages of 10 and 15!)

But the more I think about it, the more I realize that I am in this field because I really like the people. And 95% of those people are men and I appreciate them. I appreciate all the help they’ve given me whether they knew they were helping or not!

So I decided it’s time to thank all the men that I appreciate, who have helped me in my interests and my career.

First, there’s my dad. He not only told me I could do whatever I wanted to do, but promised to make sure I had the opportunities. I think he’s always been secretly disappointed I didn’t want to play football.

To my grandpa. He told me it was his sandbox, so I could play in it. He taught me how to defend my right to participate with out a leg to stand on — it wasn’t his sandbox. (And to Chris who taught me how to play toy soldiers in that sandbox. I still consider that to be one of the most boring games I know but it taught me how to steer the game or the conversation in the direction I wanted it to go.)

To my uncle John who saved all his computer magazines. He asked me once if I wanted to organize conferences. I stand by my firm answer of no, you’d have to be crazy. (But I do help out occasionally!)

To my uncle Larry who used to save me boxes of science fiction books. Boxes! Boxes of science fiction books! When you live in Spain and can’t get them that was a treasure.

To my great uncle Ted who was more delighted than I was when I finally managed to beat him in a game of cards.

To my boyfriend Frank who projects complete confidence that I can do anything. Except mow the lawn. But he is willing to get in a small boat in a big ocean with me. And he listens to my excited stories and my gripes and promises to beat up anyone who bothers me. I know he’s got my back.

To all my friends that I hang out with online and at conferences. I couldn’t possibly hope to list you all in one blog post but you’ve made all the difference. Especially those that welcomed me in the beginning. Meeting all the HelixCode guys. An afternoon hanging out with Havoc Pennington and the Eazel guys in Copenhagen trying to stay awake. Dave Neary encouraging me not just to be GNOME Foundation member but to run for the board! I didn’t run for the board then but he did later convince me to apply for the executive director job. Dinner with Bastien Nocera, Jeff Waugh and Glynn Foster. A cab ride with Daniel Veillard during which he explained why he didn’t trust OpenOffice. An afternoon hunting for saffron with J5. Conversations with Bradley Kuhn about free software and community and who was always helpful even when I was causing him great grief. All the questions that Vincent Untz answered for me when I started as Executive Director of GNOME – he was probably starting to get worried there! For Luis Villa, Brian Cameron, Lukas Rocha, Germán Póo-Caamaño, Behdad Esfahbod, Diego Escalante Urrelo, who took all my suggestions seriously and never acted like any question was stupid even when they were. For Jeff Schroeder who regularly pings me and encourages me on the ideas I’ve mentioned. For Paul Cutler for always making time to meet in person even when I delayed his trip home! For Ragavan Srinivasan who taught me we can be the ones to start something. And for all my new friends in the world of JavaScript and web development. Dave Herman, Christian Heilmann, Trevor Lalish_Menagh, Robert Nyman, Peter Svensson … Even after I’ve shown I have no clue how to write good JavaScript, you’ve still made me welcome.

And a whole bunch more people that I’ve talked to on IRC, IM, in hallways, over lunch or a beer, … I’m not leaving you out. But I do have to get back to work at some point.

Thanks to all of you. For all the conversations, for all the ideas you’ve shared, ideas you’ve given me feedback on, questions you’ve answered, trust you’ve shown, … I thank you. Hopefully I am successful in returning the favor or passing it on because I think it’s what makes our communities great. It’s what will continue to bring more men and more women to our communities.

That’s why I’m part of these free and open source software communities and why I’ve chosen this career path. For the people in the communities and the way we are making the world a better place together.

And I love the 5% that are women too! But I feel like I owe the guys a special thank you as we don’t often mention how encouraging and helpful they are.