3 ms·

As suspected it's useful only to the higher-ups and specifically to manage drones who need military discipline, same as scrum. If it has an acronym it's useles

As suspected it's useful only to the higher-ups and specifically to manage drones who need military discipline, same as scrum. If it has an acronym it's useless to functioning contributors. The original purpose has disappeared with the name.

xiphias2 8y ago
Not at all. If you achieve your OKRs regularly, you can expect to get promoted. If not, you can expect not to get promoted. Being clear with it helps everybody. If you don't get promoted although you achieved most of your OKRs, you should run from that team / company.
asdfasgasdgasdg 8y ago
Everybody's acting like OKRs are this enormous heavyweight process. Why? You just write down what you're planning on doing this quarter in a prioritized list. The purpose is to broadcast your view of your priorities, so interested parties can ask that they be adjusted. At the end of the quarter you look back and review what you actually accomplished. It's really not that big of a deal. The process gets heavier at the level where OKRs are getting aggregated across multiple teams, or teams of teams, but that's a cost paid by managers, not by "drones," so I don't see why line employees should be concerned with it. FWIW I spend about four to six hours a year thinking about OKRs, and that's assuming I'm paying attention for the entire OKR team meeting (fat chance).
- LolNoGenerics 8y ago
  > The purpose is to broadcast your view of your priorities, so interested parties can ask that they be adjusted. Concrete team stories are usually quite clear. OKRs force you to encode a bunch of them into objectives and key results. This produces utter nonsense if the duties and opportunities are generic or fragmented. Not every team can write a clear OKR which makes it obvious what's happening, especially if you servicing multiple departments.
- falsedan 8y ago
  > four to six hours a year thinking about OKRs As a non-IC, I'd spend that much time per week on OKRs: writing the OKRs for a team involved planning out the next quarter's topics, which required aligning the team (with individual meetings & group ones) for the 2-3 weeks at the end of the quarter. Then drafting them, aligning with the department/VP's topics for the quarter, finishing them, getting feedback from other team leads, dry-run presentation for the dev manager meeting, then live run-through for the department all-hands, mid-point scoring updates, end-of-quarter scoring, back to the beginning
killjoywashere 8y ago
Ah, so are you a higher-up or a drone? I'm confused. Oh, no, you must be the "individual contributor". Right? I'd say I have some pretty smart people working for me but large orgs are large because they have lots of work that needs doing and the big chunks are big enough the people doing the work tend to self-organize. Some work never stops (e.g. healthcare) so you have to establish shift work. Does that mean those people are drones? They might be young, they might enjoy a sense of belonging and camaraderie, even when things suck, and maybe they would benefit from some additional experiential learning of discipline, but does that mean they're drones? Did you consider the fact that my direct reports themselves have advanced degrees? A word of advice ... the worst thing I could have done to you right now is ignore you and let your opinion fester. Maybe step back, have all the disdain for me you want, but I hope you at least read this far.
Jorge1o1 8y ago
I implemented OKRs among my small team of 10 devs who are all pretty awesome rockstars and good contributors, but still early in their careers. It turns out that OKRs made the employees happier, because it served as a “more abstract” form of feedback. Before, they were receiving feedback, but it was too specific and narrow. Things like “this class can be refactored to X pattern” or “You missed a few unit tests covering X Y Z cases.” But when we started tracking things like time to ship a new feature, bugs per implemented feature, hard deadlines for certain product releases, etc. it really helped to give some better feedback. You could tell people who were writing code very fast to slow down in general, and write more stable, thought-out code. For example, there was one dev who tended to have substantially more bugs in his code than the others, and slower ship times. It turns out that he was always being assigned to more complicated Tasks and Stories, and the poor guy was overworked to shit and he didn’t even realize it. It’s got nothing to do with being a drone, and everything to do with not being able to improve until you measure. Do you think Usain Bolt doesn’t have a stopwatch when he runs?
- slow_donkey 8y ago
  I'm curious why this is OKR specific. Shouldn't you be tracking those metrics anyways?
  - Jorge1o1 8y ago
    Recently our sales guys got some hefty clients, and have started to bring in serious money. In order to keep up, we needed to turn development time from just a metric, into an OKR. Moreover, our clients sometimes put pressure on us to ship out X feature immediately, in response to a competitor. This means that sometimes the 10 devs are working on different features for different clients. So, just like the book, “Measure what matters.” Don’t measure useless things like commits per dev or features shipped last quarter, the important thing for our division is development time. Presumably when we get development times down, our OKRs will change to other things, like overall client satisfaction. But for now, the top concern is to meet sales volume, so our OKR is development time

xiphias2 8y ago

Not at all. If you achieve your OKRs regularly, you can expect to get promoted. If not, you can expect not to get promoted. Being clear with it helps everybody. If you don't get promoted although you achieved most of your OKRs, you should run from that team / company.

asdfasgasdgasdg 8y ago

Everybody's acting like OKRs are this enormous heavyweight process. Why? You just write down what you're planning on doing this quarter in a prioritized list. The purpose is to broadcast your view of your priorities, so interested parties can ask that they be adjusted. At the end of the quarter you look back and review what you actually accomplished. It's really not that big of a deal. The process gets heavier at the level where OKRs are getting aggregated across multiple teams, or teams of teams, but that's a cost paid by managers, not by "drones," so I don't see why line employees should be concerned with it. FWIW I spend about four to six hours a year thinking about OKRs, and that's assuming I'm paying attention for the entire OKR team meeting (fat chance).

LolNoGenerics 8y ago
> The purpose is to broadcast your view of your priorities, so interested parties can ask that they be adjusted. Concrete team stories are usually quite clear. OKRs force you to encode a bunch of them into objectives and key results. This produces utter nonsense if the duties and opportunities are generic or fragmented. Not every team can write a clear OKR which makes it obvious what's happening, especially if you servicing multiple departments.
falsedan 8y ago
> four to six hours a year thinking about OKRs As a non-IC, I'd spend that much time per week on OKRs: writing the OKRs for a team involved planning out the next quarter's topics, which required aligning the team (with individual meetings & group ones) for the 2-3 weeks at the end of the quarter. Then drafting them, aligning with the department/VP's topics for the quarter, finishing them, getting feedback from other team leads, dry-run presentation for the dev manager meeting, then live run-through for the department all-hands, mid-point scoring updates, end-of-quarter scoring, back to the beginning

killjoywashere 8y ago

Ah, so are you a higher-up or a drone? I'm confused. Oh, no, you must be the "individual contributor". Right? I'd say I have some pretty smart people working for me but large orgs are large because they have lots of work that needs doing and the big chunks are big enough the people doing the work tend to self-organize. Some work never stops (e.g. healthcare) so you have to establish shift work. Does that mean those people are drones? They might be young, they might enjoy a sense of belonging and camaraderie, even when things suck, and maybe they would benefit from some additional experiential learning of discipline, but does that mean they're drones? Did you consider the fact that my direct reports themselves have advanced degrees? A word of advice ... the worst thing I could have done to you right now is ignore you and let your opinion fester. Maybe step back, have all the disdain for me you want, but I hope you at least read this far.

Jorge1o1 8y ago

I implemented OKRs among my small team of 10 devs who are all pretty awesome rockstars and good contributors, but still early in their careers. It turns out that OKRs made the employees happier, because it served as a “more abstract” form of feedback. Before, they were receiving feedback, but it was too specific and narrow. Things like “this class can be refactored to X pattern” or “You missed a few unit tests covering X Y Z cases.” But when we started tracking things like time to ship a new feature, bugs per implemented feature, hard deadlines for certain product releases, etc. it really helped to give some better feedback. You could tell people who were writing code very fast to slow down in general, and write more stable, thought-out code. For example, there was one dev who tended to have substantially more bugs in his code than the others, and slower ship times. It turns out that he was always being assigned to more complicated Tasks and Stories, and the poor guy was overworked to shit and he didn’t even realize it. It’s got nothing to do with being a drone, and everything to do with not being able to improve until you measure. Do you think Usain Bolt doesn’t have a stopwatch when he runs?

slow_donkey 8y ago
I'm curious why this is OKR specific. Shouldn't you be tracking those metrics anyways?
- Jorge1o1 8y ago
  Recently our sales guys got some hefty clients, and have started to bring in serious money. In order to keep up, we needed to turn development time from just a metric, into an OKR. Moreover, our clients sometimes put pressure on us to ship out X feature immediately, in response to a competitor. This means that sometimes the 10 devs are working on different features for different clients. So, just like the book, “Measure what matters.” Don’t measure useless things like commits per dev or features shipped last quarter, the important thing for our division is development time. Presumably when we get development times down, our OKRs will change to other things, like overall client satisfaction. But for now, the top concern is to meet sales volume, so our OKR is development time