3 ms·

Not very sure if OKR should replace the KPI in most of IT companies since OKR mostly aims at developers. I've experienced one company that request their employe

Not very sure if OKR should replace the KPI in most of IT companies since OKR mostly aims at developers. I've experienced one company that request their employees to do OKR weekly and monthly. It actually helped a lot at the beginning coz everyone is curious and energized. But after a few weeks, indolence came out because someone forgot to submit the OKR. And other members also do the same thing. Pretty much of a "broken window effect". The workload was very high, so OKR wasn't attached any importance. Or maybe we did it in a wrong way. It doesn't mean that we might not have to align with OKR, but the method of implementing the OKR insistently and continuously should come first before it takes places.

jldugger 6y ago
> OKR mostly aims at developers Ops can totally have OKRs. Fewer incidents, faster resolution, faster deploy times, longer log retention, decreased AWS spend, the list of objectives I can think of off the top of my head is quite long. Same for project managers: on time projects and reporting, better estimates, faster issue triage, more a/b experiments, more features launched. OKRs done well are effectively a method of improving KPIs by recursively breaking work up into subtasks.
- pitayan 6y ago
  > OKRs done well are effectively a method of improving KPIs by recursively breaking work up into subtasks I strongly agree. (thumb up) Well, of course Ops can have OKRs as an HR evaluation method. KPI's shortcoming is obvious, most of the results need to have a quantified indicator which is not very appropriate for engineers' situations. But it still can be used as a complementary of OKR to provide clear numbers or date time as a target. I just guess that iterating the OKR every week and month is quite challenging. And most of the OKR stays unchanged even after months of iterations. HR and managers need to figure out the way to keep everyone update their OKR effectively.
  - jldugger 6y ago
    IMO, OKRs should be quarterly targets. Enough time to meaningfully make and measure changes repeatedly.

jldugger 6y ago

> OKR mostly aims at developers Ops can totally have OKRs. Fewer incidents, faster resolution, faster deploy times, longer log retention, decreased AWS spend, the list of objectives I can think of off the top of my head is quite long. Same for project managers: on time projects and reporting, better estimates, faster issue triage, more a/b experiments, more features launched. OKRs done well are effectively a method of improving KPIs by recursively breaking work up into subtasks.

pitayan 6y ago
> OKRs done well are effectively a method of improving KPIs by recursively breaking work up into subtasks I strongly agree. (thumb up) Well, of course Ops can have OKRs as an HR evaluation method. KPI's shortcoming is obvious, most of the results need to have a quantified indicator which is not very appropriate for engineers' situations. But it still can be used as a complementary of OKR to provide clear numbers or date time as a target. I just guess that iterating the OKR every week and month is quite challenging. And most of the OKR stays unchanged even after months of iterations. HR and managers need to figure out the way to keep everyone update their OKR effectively.
- jldugger 6y ago
  IMO, OKRs should be quarterly targets. Enough time to meaningfully make and measure changes repeatedly.