4 ms·

The biggest issue I've seen with OKRs is that it just turns into a game, and then proceeds to get "gamed". Separately, there has been more than one occasion whe

The biggest issue I've seen with OKRs is that it just turns into a game, and then proceeds to get "gamed". Separately, there has been more than one occasion where we chose to work on something OKR related but ended up providing less value to our end user as requirements changed mid quarter. Therefore making our initial OKR irrelevant, and preventing management from wanting to pivot to solve a real customer need.

Jensson 4y ago
OKR shouldn't look like a set of sprint tasks, they are supposed to mirror what results matters to your team. If your team is supposed to solve the needs of a specific customer then your OKR should be something akin to "implement features to solve customer X needs and keep them happy" and not list those features explicitly since what you build doesn't matter, all that matters is whether the customer is happy so that is the key result. Alternatively the team can be focused on developing new generic features or products to be sold to many, in those cases you can list the products explicitly since then the key result your team is delivering is that product to sell instead of keeping a specific user happy.
- dchftcs 4y ago
  In a sufficiently complex system with a big enough hierarchy, personal OKRs become quite far from the end product due to necessity. If the product objective is to grow an app to 100m users, the objective of a backend distributed systems team would be to scale the system to handle the load. If front end requirements change, for example the app needs to serve videos instead of images, entire OKRs of the backend team might need to be rewritten. If requirements change often enough the backend team OKRs just become meaningless. If they follow your model, the backend team objective would be to just "help the product scale", and the personal OKRs would be just to "help the team scale the backend and make my EM happy" because there's no way to really plan for what the product team wants next. That may well be the only thing that can be done, but it's a degeneration to a system that offers no clear accountability, and just points to the futility of sticking to the OKR model in a large organization that needs to move fast.

Jensson 4y ago

OKR shouldn't look like a set of sprint tasks, they are supposed to mirror what results matters to your team. If your team is supposed to solve the needs of a specific customer then your OKR should be something akin to "implement features to solve customer X needs and keep them happy" and not list those features explicitly since what you build doesn't matter, all that matters is whether the customer is happy so that is the key result. Alternatively the team can be focused on developing new generic features or products to be sold to many, in those cases you can list the products explicitly since then the key result your team is delivering is that product to sell instead of keeping a specific user happy.

dchftcs 4y ago
In a sufficiently complex system with a big enough hierarchy, personal OKRs become quite far from the end product due to necessity. If the product objective is to grow an app to 100m users, the objective of a backend distributed systems team would be to scale the system to handle the load. If front end requirements change, for example the app needs to serve videos instead of images, entire OKRs of the backend team might need to be rewritten. If requirements change often enough the backend team OKRs just become meaningless. If they follow your model, the backend team objective would be to just "help the product scale", and the personal OKRs would be just to "help the team scale the backend and make my EM happy" because there's no way to really plan for what the product team wants next. That may well be the only thing that can be done, but it's a degeneration to a system that offers no clear accountability, and just points to the futility of sticking to the OKR model in a large organization that needs to move fast.