I am a programmer working at a mid stage startup reaching what I call its "corporate phase".

The company I am currently at is instituting an annual "Measurable Goals" initiative, tied directly to employee bonuses. They keep touting it as "SMART goals"(Specific, Measurable, Attainable, Realistic, Time-bound).

Unfortunately, being an Agile shop, long term goals are hard to explain as the specifics of what will be developed when are not known more then a month in advance, if that.

In such an environment, what constitutes a good annual programmer "measurable goal"?

| improve this question | | | | |
  • 2
    This is really a question for your supervisor, as is it is far too broad to answer. – user9158 Mar 19 '14 at 3:10
  • 2
    @Lego, I strongly disagree. keshlam made a great answer below in around 500 words. I see no reason this is too broad to answer, or that it's opinion-based. It seems to be a practical problem, and the solutions below are actionable and backed up. I hope you'll reconsider your vote. – jmac Mar 19 '14 at 4:21
  • 2
    Hey Abraham, and welcome to The Workplace! I made a small change to your title and added a goal to explain the SMART criteria concept. I think this is a great question and hope this will get you better answers, but if you think you can improve the changes I've made (or if you disagree with them), please feel free to make an edit of your own! Thanks in advance. – jmac Mar 19 '14 at 4:25
  • 3
    This question appears to be off-topic because it is about a specific job function and job roles. This question is better handled on programmers, where there are already answers for this. – IDrinkandIKnowThings Mar 19 '14 at 14:51
  • 2
    I think you could change the question to ask how smart goals should be defined in general but once you take it into the specific job and specific goals it is out of scope for this SE. – IDrinkandIKnowThings Mar 19 '14 at 14:52

This is a commonly-used set of criteria for goal-setting. The trick is to be specific, but not overly specific ... and when possible to derive the goals from your manager's goals for the department. I'm not great at this either, despite several decades of working with such a system.

If you're being completely Agile, you may want to write these as rate-of-progress goals rather than endpoints. "Maintain an average cadance of N function points per sprint" would be specific, measurable, time-bound and hopefully you can pick an N which is attainable and realistic. Keeping the backlog under control (and preferably decreasing in size, or at least maintaining a somewhat predictable rate of removing things from it) might be another which could be quantified.

Remember that since your company is just starting this process, everyone is going to be flailing a bit on setting goals. Draft something, ask your manager to review it, rework it and iterate until it's good enough ... then turn it in, tack a copy on your wall as a reminder of what priorities you agreed to, and stop worrying about how well or poorly written it was. Yours will probably be no worse than anyone else's.

And remember that in the end, you aren't being graded on this document. You'll be graded on your work; this plan is just to help make sure you and your management agree on what your work is. They'd like it if you could predict your productivity accurately since that would help your management plan how much they can commit to in turn... and they'd like to see you stretch a bit, of course ... but if you over- or under-estimate your predicted results, that's really less important than what those results wind up being.

I don't know which flavor of Agile you're doing, but one of the points in the Scrum book is not to take the sprint plan too literally. Eventually you want to have a realistic sense of what your cadance, and the team's cadance, will be, but that only comes with time and practice... and if you over- or under-estimate, that's just a chance to look at why and whether there's an adjustment needed either to expectations or to permit better productivity.

As I said up front, I've been dealing with a system of this sort for quite some time. My experience with it has been that its value depends heavily on how willing your manager is to work with you to make it a worthwhile tool. It can become meaningless, timewasting ritual, or it can become a tool for discussing exactly what you need to do in order to get that bonus. It can be a tool for protecting you against being graded for something you weren't told was part of your responsibilities, but only if management works with you to maintain this as a "living document" which is edited when the responsibilities change.

In other words: If your management expects it to be a silver bullet, they need to be reminded that there is no silver bullet. If they're willing to use it as a tool to help you understand what you're being judged on, it may be useful.

| improve this answer | | | | |
  • @JoeStrazzere: For ongoing tasks, yes, this is "time-bound" -- it can be answered for a specific time period. Re being measured exactly on the goals: That's a recipe for people under-promising, which does not achieve any of the goals of having the system at all. Yes, it can happen, but it shouldn't if management has half a clue ... and if they don't, you're schrod no matter what system they claim to be using or what you write. – keshlam Mar 19 '14 at 19:10

Not the answer you're looking for? Browse other questions tagged .