Hacker News Reader

Comment by core-utility | Hacker News Reader

Nothing I've read in this article sounds more appealing than what I've dealt with in the past. Performance metrics at my recent careers have really become "Write what you did well in the last year aligning to these and we'll give you what we think you earn." It's a flawed system, but it's understood and doesn't get in the way all that much (especially when you start building templates year-after-year). Those who receive the highest performance rating are pretty well known by everyone, as are those who receive the lowest. Everyone else just wants to be left alone and will deal with this little bit of red tape to get by.

View on HN

What I've always dealt with is "goal setting": at the beginning of the year, you're supposed to write down all the goals you're going to accomplish by the end of the year - usually five or so. The goals you write down are usually based on whatever random priorities are most visible during goal setting time (if you actually try to make up your own goals, your manager just tells you you have to change them before he'll sign off on them), but then priorities change, management demands you work on dozens of other things, so at the end of the year you write down some lame excuse for why you didn't accomplish any of the things nobody cares if you accomplish any more and if your manager likes you he rubber stamps it and if he doesn't like it he uses it as a stick to try to get rid of you.

Try writing the goals for the year at the end of the year instead. Significantly more accurate.

I would love to do that but unfortunately every organisation I've been in demands that I set them at the start of the year. Then at the end of the year I can reflect on all the goals that were no longer relevant because plans change and being able change is agile.

You can also use goals as a shield. Since the company agreed it is high priority other work should not interfere with it. Of course if you manager thinks otherwise one can mutually change the list (which ppl only will do if the new thing is reeeaally important).

Surely you're joking.

It does make sense, though. This would be a great opportunity for deflection.

Why would they be? If my manager wants to constantly change priorities, then it’s THAT much easier for both of us when that same manager wants to know why the five things we agreed to do in January didn’t get done come performance review in November.

Just seems like logical record keeping to me.

Maybe you havent worked for a company which changes your priorities and then doesnt want to pay the performance bonus because the original (written down) goal was not met?

You sound fun.

I am. Want to hang out?

Sure, why not?

This mirrors my experience. Setting goals for what you will accomplish when you aren't in charge of what you are tasked with doing is classic responsibility without authority. It mostly feels to me that it's management trying to deligate out performance management to their reports.

This is so true. As a PM, it's very arbitrary to set OKRs, when you don't even have the KPIs in place to evaluate what is meaningful.

On top of that when you have a vision, roadmap, backlog what are you going to say other than, "yessir, I'll do more better" and will definitely help out more on the distractions or "quick-wins" as you like to refer to them.

In a matter of weeks l, it's clear who is moving the needle and think peer review would show this more than management alignment to OKRs.

I have this same experience, but goals are editable all the way through evaluations, so there's nothing saying you can't change your goals as you're writing your self-evaluations.

For sure. The theory of annual goals is you already know the most valuable ways to spend your time for the next year. But that's true only if nothing changes and nobody learns anything important. It's generally just fantasy.

I've never had goals that are project-specific. Some examples of the types of goals I have had:

To lead engineering on a project that has at least one other engineer attached to it.

Or go review 3 PRs/week from teams other than my own.

Or to give a presentation at least every other month to the engineering guild.

These types of goals would be much less affected by changing priorities.

Several of those goals are still subject to the whims of factors outside of your control.

E.g. "lead engineering on a project that has at least one other engineer." What if no project comes about? What if you start such a project and it gets canceled by strategic re-alignment? What if management keeps re-assigning the other engineer out from under you? What if executive leadership decides a larger project is priority #1 and demands 100% of your time? What if your division re-organizes how it assigns work and changes what it means to "lead" a team?

Not attaching goals to specific projects is certainly step number 1, and insulates you from some measure of change. But all of your goals are still subject to varying degrees of being de-valued or re-defined after a year's time.

When I went from contractor to permanent at my last employer the goal-setting really stressed me out as I knew I didn’t want to be held responsible for something that might change.

In the end I just decided to stop thinking about it to avoid the stress and my manager stopped asking. End of the year I filled in suitable goals based on what I had done and explained how well I’d met them.

It worked very well for me and I did the same for every year I was employed there.

Same here. This was at GE, the goal and review structure is elaborate, shifting, and based on a slew of cultural and corporate factors and cult bullshit. A real mess. You better have a cool manager that knows how to deal with it in an optimal way or it is a very very painful waste of time. My manager was brand new and by the book...greatly hastening my exit.

On top of all that it actually did influence your ability to progress (I just told them I had no aspirations of advancement beyond my current position...again, further hastening my exit lol).

Same at my company, biggest pile of shit waste of time.

Here's some goal setting: I shall endeavour to document how much monetary value I bring to the company and break it down as a dollar by the minute, then document how long it takes to fill in all of unnecessary the bureaucratic red tape so as to quantify their exact opportunity cost.

The problem with this kind of article is the dry, abstract, formal presentation, which feels devoid of content. A lot of us don't quite know how to operationalize it, and often the users of such language don't either. It feels like religious doctrine that everyone pays lip service to but doesn't really affect life in any meaningful way.

The manager-bureaucrat many of us are familiar with does not understand or care how to put these ideas to work, and reduces "OKRs" to forms to be filled and boxes to be checked.

We need context, examples, and explanations that show us when these ideas are working and when they aren't. We need them in plainer, more candid and more relatable language. And they need to be relevant to the problems developers and managers actually face. We need the why - why is it helpful to think in terms of OKRs rather than some other more familiar or simpler way?

Bottom line: the secret missing ingredient is often "actually use your brain when doing all these things".

Reply on news.ycombinator.com