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).
In a word
No
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...
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.
EDIT
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.
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.
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:
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.
Edit:
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:
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:
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:
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 :-)
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.
