Following on from this question, I wondered if folk might be able to suggest some samples of what might be considered a "good" objective in a periodic review cycle for a programmer?
Let's define SMART from the most popular definitions in the Wikipedia entry:
I have come to realize that SMART goals are best used when people have a deficiency they need to correct, and are not so good for times you want people to grow or go from good to great. If someone is not doing timesheets, for example, and this is hurting the company because you sometimes have to delay invoicing, you could have a smart goal like "over the next 6 weeks, at least 5 weeks' timesheets will be completed by 10am of the next Monday morning." 6 weeks later you have a true or false; the developer made it or missed it. Either the new habit is in place or you get to decide if you want to still employ someone who doesn't mind delaying your invoicing. Works for people who have other bad habits too: "over the next two weeks, at least 75% of your checkins will have a checkin comment that follows the checkin guidelines (link to internal document)." Again you have a nice crisp did/didn't at the end of that short time.
Where I find these constructs less helpful is when the timeframe lengthens, when the achievement you want is fuzzy (learn a language, be more helpful), or when it's ok if the goal is not achieved (you may value certifications, but if someone failed their test you probably wouldn't take disciplinary action.) Suddenly all the benefits of the smart goal fall away. Don't try to use them for anything other than corrective actions, and they're easy to write, they help the developer get up to the expected level, and they're easy to test for when the time's up. Having trouble writing them means they're not the right tool for this goal.
Since I'm about to go into an objective-setting conversation with my boss, I thought I'd add a few examples that are similar to some I'm considering suggesting for myself:
I expect additional work to materialise within the times I've specified (it always has before, after all) and that work may have an effect on the "Timely" aspect in particular. That shouldn't be a problem: objectives should be reviewed regularly to make sure that they continue to meet the "Achievable" criterion. I'll need to make sure that I keep my manager in the loop on this - nobody likes unpleasant year-end surprises...
If you sell software or a product with software in it...
Increase sales n%.
Really.
If the software didn't work, you would not sell much of it.
If the software worked REALLY RALLY WELL , you would sell lots.
(This will have the software guys watching the sales guys like hawks making sure they don't blow their performance bonus.)
If you software is an in-house system:
cut cost of business n%.
If the new software systems takes 10x as long it costs the company money. If the new system is fast and prevents errors, the company saves money.
This approach seems like it applies to sales guys or maybe the VP of business change process, but really, the software developers are the front line for both kinds of process.
My underlying idea here is to try to explicitly align the employees reward structure with teh best possible outcome for the company.
Implementation of X module within
+-10% of the estimated time (40 hours) within 5% range of 10 defects/KLOC
It is specific - as long as "Implementation" has an accepted meaning across the team.
Usually it refers to "Coding + Unit Testing"
It is Measurable - you can measure defects, effort and time
Achievable - As long as estimate is based on previous actuals from similar modules / expert judgement, it should be achievable
Relevant - Its specifically talking about a particular module
Time Bound - I think there could be an end - date added to it to make it explicit.
However usually in projects where people multi-task on different things at the same time, that's a lot more difficult to do. But as long as the tasks are prioritized correctly, it shouldn't really be an issue not having an end date in it
