3 ms·

The problem with setting very concrete goals like this, is that whenever you don't precisely meet them, they can be made to be a knock against you. As a result

by garenp 13y ago

The problem with setting very concrete goals like this, is that whenever you don't precisely meet them, they can be made to be a knock against you. As a result, it's then in your interest to set goals that are as easy to achieve as possible. I can't imagine that aiming for mediocrity serves the company or the employee well.

hopeless 13y ago
And setting vague goals which may, or may not, have been achieved is better for the employee or the company?! But you're right to an extent, and I skipped over it. There's a class of things (call them skills, behaviours or competencies) which aren't suited for evaluation through measurement: "teamwork", "leadership" etc. These are not goals and it's important to understand the difference. For competencies it's best to evaluate them on a simple scale (say 1-10, we don't even label the exact score) so the discussion naturally becomes a bit fuzzy and less concrete — because the concepts are fuzzy. Let's be honest, you want employees to improve in these competencies but there's really no effective way to evaluate them. Plans and reviews should be driven by the measurable stuff (goals) and the employee's development is driven by discussions not scoring of their skills/competencies/whatever-you-want-to-call-them
hopeless 13y ago
Also, the outcome when reviewing a goal doesn't have to be a binary achieved/failed. You could have something like failed/nearly-met/met/exceeded/wildly-exceeded
rpwilcox 13y ago
Yup. And after getting dinged once or twice in a review, metrics get gamed consciously or unconsciously. The mind tends to avoid pain. If management lays down some metric like "higher velocity by 20%" or "20% more bugs closed", don't be surprised when they get it and it turns out to not really be effective. (From imperceptible Story Point Inflation to 20% more technical debt, or bugs mysteriously skipping the bug tracking system...)

by garenp 13y ago

hopeless 13y ago

And setting vague goals which may, or may not, have been achieved is better for the employee or the company?! But you're right to an extent, and I skipped over it. There's a class of things (call them skills, behaviours or competencies) which aren't suited for evaluation through measurement: "teamwork", "leadership" etc. These are not goals and it's important to understand the difference. For competencies it's best to evaluate them on a simple scale (say 1-10, we don't even label the exact score) so the discussion naturally becomes a bit fuzzy and less concrete — because the concepts are fuzzy. Let's be honest, you want employees to improve in these competencies but there's really no effective way to evaluate them. Plans and reviews should be driven by the measurable stuff (goals) and the employee's development is driven by discussions not scoring of their skills/competencies/whatever-you-want-to-call-them

hopeless 13y ago

Also, the outcome when reviewing a goal doesn't have to be a binary achieved/failed. You could have something like failed/nearly-met/met/exceeded/wildly-exceeded

rpwilcox 13y ago

Yup. And after getting dinged once or twice in a review, metrics get gamed consciously or unconsciously. The mind tends to avoid pain. If management lays down some metric like "higher velocity by 20%" or "20% more bugs closed", don't be surprised when they get it and it turns out to not really be effective. (From imperceptible Story Point Inflation to 20% more technical debt, or bugs mysteriously skipping the bug tracking system...)