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.
> 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.
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.