Stack Exchange is using nice way to motivate contribution through Badges. I was thinking of implementing this same idea for my project team members. Badges will be awarded to project team members in recognition of their contributions to the project.

I thought I would use the three ranks of badge: Bronze, Silver, Gold. Rank depends on the volume of the effort through the project sprints.

Badges example for development project

Committer: commits working code changes into project repository (e.g. Bronze Committer=10 commits during 1 sprint, Silver Committer=25 commits, Gold Committer=50 commits)

Tester: test release and report bugs (e.g. Bronze Committer=2 bugs during 1 sprint, Silver Committer=5 bugs, Gold Committer=10 bugs)

My questions are:

  1. Do you think this will be a good idea to motivate people and get the project on-time with good quality?
  2. Did anyone use similar idea to motivate his team members? If yes, how do you implement it? Giving examples is much appreciated...
  3. What metrics would you suggest to implement this idea and how to measure them? Metrics I thought of like: coding, commiting, completing tasks on time, testing, recording spent time, commenting in code, objectizing, organizing, integrating, standardizing, creativity and designing.
  4. For above proposed metrics in point #3 (and if you are proposing new metrics), how do you suggest to measure each of these metrics?
  • 3
    +1, as I thought about something like this a while ago... didn't progress on it yet, though. either way, I believe this link might give you good insights about the metrics you mentioned: pm.stackexchange.com/questions/5289/…
    – Tiago Cardoso
    Commented Sep 10, 2012 at 19:15
  • Hi Rami, how old are the people on your team?
    – jmort253
    Commented Sep 11, 2012 at 0:42
  • @jmort253 - How is the age important to this? Anyway, majority is under 30. Commented Sep 11, 2012 at 21:33
  • @RamiSedhom - It depends. Are you looking for a cooperative team or an internally competitive one? The former would collectively focus on a common goal, the latter individually on their badges!
    – PhD
    Commented Sep 23, 2012 at 6:22

12 Answers 12


If this is a project that people are currently getting paid to work on: ABSOLUTELY NOT!

First of all, the goals on the project should be plain and obvious, and on a software project, those goals can already be complicated. Get thorough designs in on time, get code completed on time with as few defects as possible, incorporate feedback from code reviews, fix the unit tests you broke working on this new feature, get new units tests done on time, get doc/doc notes done on time.

Now on top of that, you want to add a bunch of "fuzzy" goals you mention in #3? "Objectizing"? If you propose a badge for that, before you finish your first sprint you are going to regret ever coming up with that idea. People are going to be arguing that their objectization is better than someone else's objectization. All kinds of time will be wasted on this. And worst case: people are going to start getting personal because someone didn't like their objectization. Goals like "organizaion" and "standardization" are equally fuzzy.

You already have enough goals. Leave your developers alone to achieve those. You don't want people spending time chasing badges (for which your organization receives no credit). You want them trying to achieve real goals.

StackExchange can use these badges because we aren't getting paid for this. And if it doesn't get done, only StackExchange loses out (though certainly the communities benefit from this assemblage of knowledge and people). StackExchange also has an automated process for awarding badges. How are you going to automate the awarding of the "designing" badge? You can't. So you're going to have to spend a lot of time doing it manually.

Developers are notorious for gaming any system you put in front of them. The gaming of systems often leads to wasting energy while completely missing the point (real goals). Your current goals are important and tough enough. Keep your people focused on them.

  • 5
    "Developers are notorious for gaming any system you put in front of them." Yep. And circumventing, enhancing, altering and or outright cheating at said game. Commented Sep 11, 2012 at 0:17
  • The idea is called "gamification" for a reason!
    – Burhan Ali
    Commented Sep 15, 2012 at 14:06

There are already a lot of theories and studies about motivation. Extrinsic motivators, like badges, awards, and money, have been studied and I believe the results show they are marginal at best, do nothing, or maybe even decrease motivation. The strongest motivators are intrinsic and are mastery, purpose, and autonomy.

Follow the science....

  • I agree that "The strongest motivators are intrinsic and are mastery, purpose, and autonomy". I am reading Danial's book: Drive and I like his theory. But what I'm thinking of is a simple badgets game, it's not awards or money, it's just for breaking stress and having more fun while working. Commented Sep 10, 2012 at 21:56
  • David, surely there's no harm in having a little fun though, as long as the fun doesn't get in the way of the actual goals, right?
    – jmort253
    Commented Sep 11, 2012 at 0:41
  • 1
    Sure, like a teaming event. Rami, your original message implied you wanted the badges to be a motivator, i.e., worker exhibits behavior, receives badge, behavior increases. However, if it were simply a token as part of a broader teaming event, that could be okay, I suppose. I have read (though I cannot reference at the moment) some discussion that contraindicates teaming events due to lack of real efficacy. However, the jury's likely still out on that, though. Commented Sep 11, 2012 at 2:18
  • +2 for science, -1 for using team as a verb (well, gerund, but bad enough).
    – psr
    Commented Sep 12, 2012 at 3:14

Is it a good idea?

As for mostly everything: it all depends on your team.

Some might be very receptive, some absolutely not. If we are talking of an in-house team, I believe it would work more easily with people who already trust you, and who have some sense of humor, as they will have to cope with something that looks un-corporate and hence, at first sight, perhaps “unprofessional” to some. I personally had this issue when I tried to add some other “social improvement” fun-yet-serious artifacts, and backed off when I realized the team was not receptive and considered it more as a game I wanted to play rather than an actually useful PM practice.

Do others do so?

Well, not exactly badges, but along the same lines, and most certainly more impressive  ;)  check out for example the Swords and Shields Ceremony at Blizzard.


  • coding: this is not a metric (what exactly are you measuring?).
  • commiting: this is a bad metric, quantity does not mean quality, and it is usually the opposite in software.
  • completing tasks on time: possibly, but on scope too, and in such a way that the completion was not done in such a terrible way that it will raise bugs later on…

Actually, I'll stop here. This has already been addressed.

You have to notice that the whole SE reputation and badges system relies on a community of human beings evaluating stuff. The only automation that takes place is in counting scores and associating badges to that score.

For testers, it should be a bit easier. The amount of spotted bugs, possibly weighted by severity, could be an easy metric. You could also consider the time before the report as another metric.

Philosophical considerations

Such a system is simply a model for reputation, and thus a way to simplify human trust attribution. However, for such a system to work, it has to map precisely to events fellow humans would acknowledge as impressive, or at least good in some way.

And I'm afraid this is exactly where you'll hit the limit of automation. By this very definition, automatically computable metrics cannot compute how good creative work is. Computers are very good at calculating stuff, not really at evaluating creative work. And coding is creative work.

Hence, I don't believe such a system would actually be sustainable to ask for contributions, as it would quickly raise doubts on whichever metric is used. Anything but fellow human evaluation will most probably be disregarded by other programmers, removing the very intention of improving reputation. It could even have the opposite effect, depending on the metrics used (“gold contributor? huh, this guy most probably did 30 shitty commits…”).

So, let's conclude. Adding a badge system is a cool goodie that simplifies such an evaluation by adding discrete steps to a continuous spectrum of evaluation, but for it to have any meaning, you need to make sure the way they are attributed is consensual. For this, I think the only valid metric is peers evaluation. This is difficult to obtain reliably on anything but projects with a solid community.

Hence, I would advise to think twice before trying this reward system, as it could be disregarded quite easily, making you waste effort and look foolish, or even backlash if a subset of the population buys into it but not another, segmenting your community / team.

  • 1
    You make some great points here. I want to add that this shouldn't make up for a lack of a good team. You still need people who are intrinsically motivated; this reward system should really only be "for fun" or as you mentioned, a way to get the team to rally around one another and work together....... The moment this will fail is when it's required that you have 18 pieces of flair and 10 committer badges. ;)
    – jmort253
    Commented Sep 11, 2012 at 0:39

Looking at this from a programmer's side, there is some things that can be done and some potential bad thing lurking.

First the bad things - you don't want to encourage poor practices. The one that caught my eye was "number of commits". Indeed, submitting everything as just one commit is bad, but it is equally bad to submit one commit per file (or one commit to change the comment, another commit to change the code). Ideally, commits are done with a logical grouping - if it is one commit, its one, if its 20, its twenty. But to try to find an 'ideal' number of commits is folly.

Similarly, I've seen goals for bug reporting go bad. If one rewards (or requires) a certain number of bugs then instead of "this bug occurs under this set of circumstances" you will find "this bug occurs under this set of circumstances on page A", "this bug occurs under this set of circumstances on page B", ... "this bug occurs under this set of circumstances on page Z". And there is dozens more bugs reported that don't help anyone (it has wasted time time of the reporter, and the person who has to prioritize the additional bugs, and the person who has to fix them, and the person who has to close them).

Measuring lines of code written is also a faulty metric. Consider Bill Atkison writing -2000 lines of code

When the Lisa team was pushing to finalize their software in 1982, project managers started requiring programmers to submit weekly forms reporting on the number of lines of code they had written. Bill Atkinson thought that was silly. For the week in which he had rewritten QuickDraw’s region calculation routines to be six times faster and 2000 lines shorter, he put “-2000″ on the form. After a few more weeks the managers stopped asking him to fill out the form, and he gladly complied. (from Computer History on QuickDraw)

For a possible solution, look at Jenkins continuous integration game plugin where the build server examines the static analysis information from a build and gives (or subtracts) points for a number of things (code style, coding practices, unit tests, compiler warnings). Note that all of these things are programmatic and do not involve human interaction or judging.

That said, its interesting to look at how I score on the local build CI game tab. But I don't "play" it. I strive to write good code because I want it to be good code, not because I would get points or a badge.


I would share the idea with your team and ask them about opinion.

You can do it by variety of means:

  • ask your team to share ideas about how to gamify the work; propose your idea then

  • ask your team directly what they think about your idea

  • ask for permission to make a 30 day experiment to see how it works
  • ...

The fact is, that none of us have ever tried this before. Especially in your team. It's all guessing. But if your team is opened to try new things - go for it and be the first one to try the idea at work and share your insights.


I don't know the management theory of this, but I would be extremely wary of introducing badges in the way that you describe. When I put together a team to deliver a product, I want everyone achieving the best overall team outcome - whatever that means - rather than competing as individuals and potentially undermining / failing to help each other.

The only way that I could see a scheme like this working would be for people to be awarded badges by the rest of the team, not by achieving arbitrary goals that are of unclear value. Maybe there would be some merit in having a "Helpful" badge, or a "great contribution" award, or a "problem solver" certificate - but don't make it a competition. Teams pull together - players may compete to be part of the team, but once they are in, they should work for each other.

  • Like the last line Iain. (Y)
    – ViSu
    Commented Mar 19, 2015 at 5:36

Be careful! There is a fine, subjective, line between motivating and manipulating. If your team decides that this is the latter you may not get their trust back again.

Are you sure you aren't, in fact, attempting to manipulate them? It kind of sounds like you don't think they will do a good job without more motivation. But that giving them imaginary rewards will provide that motivation. Based on metrics of project quality that you plan to come up with. Which implies that you believe you can measure the project quality better than your team (otherwise why try to change their behavior if they know better than you what their behavior should be?).

Sorry, but if I were you I would hope my team didn't find this question.


The reasons given in other answers that this is a poor idea are mostly true, however I think they are missing the bigger picture. The number one issue with such an approach is you are treating the team as a bunch of individuals, and not as a team. You want to give team accolades? Awesome. But you should never intentionally divide your team in such a manner.


I still feel that any gaming system moves the focus from the development and introduces a strong individualism inside the organization. Gamification was introduced in applications in order to use the game to keep the customers. They return to your service partly because of the gaming experience.

Let's take Diablo 3 for example. Getting badges won't get you closer to the final goal, and in order to get some of them, the players may do a lot of unnecessary activities, and it is still a solo task. Back to software development: what will prevent the appearance of the unnecessary comments, commits, refactoring and features?

You can have rewards for common activities in order to solve the solo achievement issue, but those where really hard to track, and you'll need a gamekeeper for sure. Or two.

I'm not in favour to use such things in order to get people motivated and bring the projects forward. However, gamification can improve certain parts like knowledge sharing (e.g. FedEx example) and education (e.g. codeschool).

A personal example. I tried to motivate people to be more agile using the Agile Trophy in 2010. I was given it to the colleague who made the more valuable contribution to our agile way of working during the week. The ceremony was fun - we did it during the weekly all staff meeting - the person who got the trophy was proud of it, but not everybody played. Partly because did not care about my stupid trophy, or they did not like the rules, or they found it hard to get (I didn't gave the trophy out for a good comment during a daily standup meeting). The idea dead quite fast, it didn't bring the projects forwards, and hardly anybody remembers is, but it was fun :-)


Unlike Kent, I think this is an interesting idea that could work. The caveat is that you will need to integrate this tool with other HR practices. This could then feed into bonuses, promotions, etc etc. For example, a developer may have goals to achieve X bronze badges per project on average over a year, those goals need to be met to get a bonus of A%, but if you get your X bronze per project average and get Y silver as well your bonus goes up.

The bottom line I think is that you need a solid, integrated plan for implementing this with very clear standards and buy-in from corporate managers. Using a population of disconnected incentives is a recipe for confusion and disaster.

  • 4
    Bonuses and promotions from badges? Then why do you need badges in the first place, if the reward is bonuses and promotions? You're simply adding a layer of complexity (admittedly, of cartoonishly nice complexity) on the corporate objectives evaluation game.
    – MattiSG
    Commented Sep 10, 2012 at 20:17
  • 1
    In my opinion, this would make the game less fun. Example: If I don't get my gold Electorate badge by the end of the year, PMSE will fine me. That would totally take the fun out of it.... If this is anything more than a game, I tend to think it could be detrimental for the people who don't hit the mark.
    – jmort253
    Commented Sep 11, 2012 at 0:46
  • My thinking was that tying these into bonuses or whatever you may be able to provide clear goals to team members while giving them some flex on how to meet those goals. Given the HR teams/policies I've worked with in the past any "complexity" added would be marginal at most.
    – Doug B
    Commented Sep 11, 2012 at 12:57
  • @jmort253 - The thought of fining someone for not meeting their goals never crossed my mind. I assume that is just a hypothetical you're putting out there rather than something you've experienced, the labour laws where I live would cause an employer any number of problems if they tried to implement that kind of activity.
    – Doug B
    Commented Sep 11, 2012 at 13:00
  • Sorry, bad example. But "fining" could have the same effect as, let's say, losing one's bonus.
    – jmort253
    Commented Sep 11, 2012 at 14:45

It's an interesting idea, and I could see what it seem like a good one at first. But I would advise against it. Partly because I think it's based on a fundamentally flawed basis. I know for me, the badges provide no motivation at all. They're simply a by-product of continuing to try to answer questions in a way others find helpful. My ranking motivates me, as it means I'm providing value.

The second issue is that the idea seems, well sorry, but a little 'elementary school'. You're (presumably) talking about a team of adults and professionals here. I question the need to motivate in this way. It's almost the reverse of the gaming that Kent mentioned - you're gaming the team to get them motivated? Is that really necessary?

No, I understand why you might go this direction, but if you feel it's really necessary, then I think you have a bigger issue. You need to look at 'why' you feel motivating like this is necessary, and address that issue. Why does your team need additional motivation to do their job outside of the existing situation.

  • 2
    I don't think it's a bad idea if executed in the manner that MattiSG suggests. Sure, the badges are irrelevant, but they make it fun, whether it's answering questions on PMSE or encouraging a fun way to build teamwork on the team. I just don't think the badges can be official or used to officially evaluate someone. For this to work, I still think you need to have a good, strong team.
    – jmort253
    Commented Sep 11, 2012 at 0:37
  • 1
    @Jmort - I think that's my point - if you have a "good, strong team", then this type of motivation is unnecessary. Sure it could be fun. But is the extra work 'necessary' for motivation, or just something that's being done as part of the culture? These are two different things. Rami's question seems to say that he's trying to 'motivate to contribute', indicating that lack of contribution is a problem. If this isn't the case, and he's looking at the company culture, then I see no problem with it. Commented Sep 11, 2012 at 1:59

Software development process is a team work and measuring individuals productivity through some objective goals might work against the Team bonding/dynamics. I suggest if you want to rewards individuals make it a annual activity based on contributions to the project which made significant difference.

100 check ins with useless code is not something you want to reward, but 1 check in which improved the performance of the software should be awarded.

We had exercise to measure individuals productivity and then give pay hikes using this productivity number and it was counterproductive for us. People stopped cooperating with each other as helping others would push their productivity higher.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.