Several organisations I know use SMART goals for their programmers. SMART is an acronym for Specific, Measurable, Achievable, Relevant and Time-Bound. They are fairly common in large corporations.

My own prior experience with SMART goals has not been all that positive. Have other programmers found them an effective way to measure performance? What are some examples of good SMART goals for programmers (if they exist).

  • While I'd like to believe the answer is yes, I have yet to experience the big level-ups that this should give me when it comes to my powers. ;)
    – JB King
    Commented Dec 22, 2010 at 5:01
  • 18
    "Specific Measurable Achieveable Relevant and Time-Bound" - nothing with that boring name can be of any use.
    – user8685
    Commented Dec 22, 2010 at 12:52
  • It would require strict waterfall process. Meanwhile that's considered obsolete and various version of agile are used instead for more than a decade now.
    – vartec
    Commented Mar 20, 2012 at 10:25
  • 1
    possible duplicate of Metric by which to hold developers accountable
    – gnat
    Commented Apr 12, 2013 at 5:49
  • 1
    I would submit thay are not useful for pretty much any profession. Measuring what is easy or possible to measure numerically results in measuring the wrong thing generally.
    – HLGEM
    Commented Apr 12, 2013 at 19:35

10 Answers 10


In a word


First : I've never had my projects remain stable enough that I could establish the SMART goals with any meaning. The time scales between when my roles change on a project and when perf reviews are done are just too far out of sync.

Second: Measuring individual performance is a great way to create a "not my job" mentality and negative competition between individuals and/or the various sub teams in an organization. It's very easy to game the system and make sure you're looking out for yourself and not really helping out the entire team. We should be encouraging people to be team players, but then our organizations do the exact opposite.

Most of these sorts of systems are antithetical to team building. Mary Poppendieck's done a far better job of articulating this than I can ever do in LeanEssays: Team Compensation.

Sue got a call from Janice in human resources. “Sue,” she said, “Great job your team did! And thanks for filling out all of those appraisal input forms. But really, you can’t give everyone a top rating. Your average rating should be ‘meets expectations’. You can only have one or two people who ‘far exceeded expectations’...”

... One of the greatest thought leaders of the 20th century, W Edwards Deming, wrote that un-measurable damage is created by ranking people, merit systems, and incentive pay. Deming believed that every business is a system and the performance of individuals is largely the result of the way the system operates. In his view, the system causes 80% of the problems in a business, and the system is management’s responsibility. He wrote that using exhortations and incentives to get individuals to solve management problems simply doesn’t work. Deming opposed ranking because it destroys pride in workmanship, and merit raises because they address the symptoms, rather than the causes, of problems.

...let’s take a deeper look into employee evaluation and reward systems, and explore what causes them to become dysfunctional...

  • Good piece, but not related to SMART...
    – gbn
    Commented Dec 22, 2010 at 13:40
  • I see it similar to gbn: not related to SMART. The development-team will get goals from management (or directly from the customer) anyways, if they are following SMART-criteria or not.
    – Mnementh
    Commented Dec 22, 2010 at 14:29
  • 3
    My reason for citing it is that SMART goals are usually done with the purpose of measuring individual performance with an eye towards setting bonuses etc. individually. Another article that dances in the same space of how most corps handle performance review... joelonsoftware.com/articles/fog0000000070.html
    – MIA
    Commented Dec 22, 2010 at 16:54
  • 3
    That's not the purpose of SMART. SMART should help you (or management) to make better goals. You will have goals in any project, if they are SMART or not. See en.wikipedia.org/wiki/SMART_criteria
    – Mnementh
    Commented Dec 24, 2010 at 9:29
  • 4
    @Mnementh - Purpose vs implementation are two diff't things. SMART's usually a smell indicating that an organization is going to reward individual performance over team contribution. I'm sure there are organizations that get it right, but I've yet to personally encounter one.
    – MIA
    Commented Dec 24, 2010 at 15:45

We've used SMART goals in the large corporation where I work. They're meaningless for the most part.

Goals come down from upper management and are lofty and abstract. Relating them to concrete projects and development is usually a joke. Most of the projects that come into the group come from the business and are to meet a specific business need. So you code the project, put it in production and do an awesome job as usual. How does that relate to a goal that someone in upper management came up with?

We do much better as a group when we come up with our own goals. Sometimes they include training on a specific topic or implementing a new process change, something that can actually be related to what we do. They're still not really related to the day to day operation of coding by they're at least things that help move the group foward in the corporate environment.


As Mnementh has so correctly pointed out, my answer is based on SMART goals not being, well, SMART. I would add to my answer that if you are a manager of programmers and want to implement SMART goals, be sure that they are SMART. Use my mangagers' example as a way NOT to implement SMART goals. If you don't manage programmers and someone tells you that you're now going to start using SMART goals and they end up like ours did, then understand that you've got people in upper management who likes buzz words and being able to check them off a list of things they've implemented.

  • 4
    If the goals are lofty and abstract, they are not SMART. S = specific. So your experience is not about SMART-goals, it is one about goals, that are not match smart-criteria.
    – Mnementh
    Commented Dec 22, 2010 at 12:41
  • 1
    @Mnementh - That's true. Perhaps you'd like to educate our senior management??
    – Walter
    Commented Dec 22, 2010 at 13:19
  • 3
    If you educate my boss. He even had a project-management-cource with us, SMART was explained. But nothing changed, his goals are as cloudy as ever.
    – Mnementh
    Commented Dec 22, 2010 at 13:24
  • OK so the key problem seems to be that the SMART acronym tends to be used by people who realize their goals aren't but haven't realized that SMART isn't an ingredient you can add to non-SMART "goals" you've already picked, instead it's an admonishment to pick different kinds of goals. Commented Mar 20, 2012 at 11:19

There's plenty of research to show that programmers will do an excellent job at whatever criteria are presented to them, at the cost of other possible goals.

This means that they will do well at achieving specific and measurable goals, and less well at anything not specifically listed. That means you have to be extremely careful at setting goals.

You don't want to set lines of code as a goal. Trust me. Setting bugs fixed leads to writing buggy code to begin with. Asking for bug fixes in existing code will result in very liberal definitions of "bug" (and maybe "fix"). (Also, the "achievable" part depends on how buggy the code was.) Asking for feature completeness in a certain time, well....

What you want your programmers to do is to write useful stuff in a reasonable period of time with good code quality, and enhance and modify it while maintaining code quality. I've never seen specific and measurable goals that would be good criteria myself.

  • 3
    Could you link to some of that research?
    – nicbou
    Commented Mar 7, 2016 at 10:05

We go through this exercise every year. The problem is that developers here tend to have very little autonomy over what they do (tasks determined by product manager). We are fortunate that, at least on paper, we have time dedicated to pursuing our goals. Realistically, we get far less than that, however.

Within that framework, I've found that setting self-developmental goals works really well. For example, two of my goals from last year were:

  1. To read Design Patterns and write toy projects to learn and demonstrate each pattern by next year. This has ended up taking 2 years, but the improvement to my coding has been noticeable.
  2. To study .NET 3.5 language features and do a presentation to my co-workers each quarter. This ended up being 1 presentation on LINQ which my co-workers appreciated in various degrees between apathetic and mildly interested. However, I learned lots, and having demonstrated my C# knowledge I've been moved to work on a pretty cool new project.

So, yeah, I've benefited and had fun while doing it.

Honestly, in our company, I think the lack of good developer SMART goals has more to do with knee-jerk aversion to corporate-speak.


Yes, if set correctly.

If set correctly, the objectives can improve both the team and the individual people. They should be aligned to the job too and designed for the individual.

I've been in places where a whole DBA team has the same bland objectives, as well as high level hand me downs such as "conform to global and regional KPIs as determined by the the KPI committee". Which no-one knows of course..

Then again, I've been at places where the manager sets individual objectives with thought up front.


I've read the Mary Poppendieck article and it isn't about SMART. "The Perception of Impossibility" fails "Achievable" for example.

Objectives should be set for the individual, to share their strenghts, help rectify weaknesses, contribute to the team. Measurement is for the individual.

There should be no comparison of x vs y.

The objectives for x and y should be commensurate with their rank or position inside a system though: one does not set the same objectives for seniors and juniors. That's unfair.

Some benchmark is needed to set bonus or payrises from a limited pot: should we count lines of code instead? Peer reviews?

And show me valid alternatives that won't require me to change my global corporate ethos. I have no criticism of SMART: I do have criticisms of piss poor managers...


As a performance framework, SMART is only as effective as how closely your objectives are aligned with those of your managers. Sometimes your SMART objectives have to DUMB down first, ie. make them:

  • Doable
  • Understandable
  • Manageable
  • Beneficial

As strange as that might sound.


SMART-type objective-setting can be useful in a programming context but it has to be done intelligently or, as pointed out in other answers, it's likely to be time-wasting (or worse).

To get useful objectives, it helps to agree what the SMART acronym will mean: a quick Google search found varying definitions:

  • S: seems to have consensus at Specific (although there's some disagreement about what that means)
  • M: Meaningful and Motivational are alternatives to the more common Measurable
  • A: seems most often to represent Achievable, but I've also seen Agreed-upon
  • R: depending where you look, you can find Realistic, Relevant, Results-focused
  • T seems always to reference Time, although the emphasis varies

So first, both sides of the objective-setting negotiation should be working from a common understanding of the process.

Next, the overall goals for the organisation, division, group, team (or whatever hierarchy is relevant) need to be explained and understood. At that point it should be possible for the individual (IMO, goals have to be set at the individual level to be worthwhile) to be able to agree on a small number of objectives that should inform that person's activities going forward.

If it ends there, it's still been a waste of everyone's time. Objectives need to be reviewed and adjusted regularly - where achieved, the possible need to set new objectives should be considered, where not achieved, reasons should be identified and corrective action prescribed where necessary.

Everyone concerned should be aware that this kind of exercise is not worthwhile if it's not taken seriously, or perhaps more algorithmically, the value to be extracted is proportional to the effort put in.

It might be instructive to see what people think might be useful/worthwhile SMART objectives. I've put up a question here...


The trouble with SMART goals is that they have to pick what is measurable. Since what is measurable and what important to organization success are often not the same thing (And virtually never are in programming), SMART goals always fail in performance appraisals in my experience. And sometimes things appear measurable but are not without far too much effort (Like the SMART goal I had one time to answer all emails within 4 hours. Really who wants to try to go through the thousands of emails I get a year, determine if it was informational or needed an answer and then look at my sent emails to see if I did answer it and then listen to recordings of all phone calls to see if I answered it, check my IM log to see if I answered it, etc. And what about that email that got sent to me on Saturday night at midnight...)


To all the people who answered NO, your Goals were probably NOT SMART enough.

I have used them and I find them incredibly useful. You might want to try something that works for us:

  1. Set Quarterly Goals.
  2. Set measurable goals.
  3. Set only one goal for the individual
  4. Make the individual accept the goal, if he says the Goal is too ambitious readjust till the time when both of you agree.
  5. At the End of the quarter, come up with a Boolean value. Goal achieved = true or false.

This is extremely powerful, it creates accountability for the Developer. The people who want to find excuses chicken out after 6 months or so.

P.S : I can understand people down voting the answer but please drop in a relevant comment atleast I wil learn something I dont know :-)

  • 2
    Geek, can you give me an example of a goal you found helpful? Commented Dec 22, 2010 at 11:54
  • 1
    @Craigs : Simple goals mate, like deliver XYZ component with 80% quality in 3 months or Deliver a service pack with 100 bug fixes in 3 months. The key here is ONLY ONE GOAL, dont mix things. Once you have only one goal you know what to focus on and the outcome is a boolean(true or false). Also Exceeds/Meets/Partially met can be defined very easily for eg 110 issue fixes = exceeds,100 = achieved, 90 = partially achieved.
    – Geek
    Commented Dec 22, 2010 at 12:01
  • 1
    @Geek - Delivering a service pack with 100 bug fixes is a rather poor goal. It is easy to game-- you can always split one bug into many different bugs. It gives the same weight to a bug that takes 100 hours of work to fix and test as a bug that relates to a typo on a screen that takes minutes to fix. And it gives the same weight to a bug that generates hundreds of high-priority calls to support every quarter as a bug that caused one low-priority call to support last year. Commented Sep 2, 2011 at 20:24
  • 1
    @Geek - Delivering some component with an acceptable level of quality may be a reasonable goal but probably isn't. It assumes that the specification of the XYZ component is complete, correct, and unchanging for the entire quarter which is unlikely. It assumes that you are the only developer working on the XYZ component otherwise it's not an individual goal. It removes all incentive to assist other developers in the group since that doesn't help you with your objective. And it makes your QA and development groups adversaries as developers fight with testers to hit their quality numbers. Commented Sep 2, 2011 at 20:31
  • 1
    @Justin : I probably am missing the point that you are trying to make. My answers : Fixing 100 bugs is just an estimate and the Manager(some one who understands the product and the technicalities of the bugs ) has to take a call on it. For example, fix 100 bugs that take 10 hours each or fix 500 bugs which are typos on screens. The key here is that at the start of Quarter you know, which bugs you want to fix and how much time it takes to fix each. Also there will be a 5-10% variance on some issues. You might as well want to review your goal in the middle of the quarter.
    – Geek
    Commented Sep 5, 2011 at 9:09

SMART is an acronym to remember some criteria for better goals. So introducing SMART means, your management has to make better following this principle. Without SMART management would set goals anyways, but they would be more likely too difficult.

So, for programmers should come no change, the management has to change it's style to implement SMART. And if they do right, your work as a programmer can become easier, because the direction of the project is more clear, timeframes are set and so on.

If management doesn't do it right, not much will change.

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