[stavros]

We do, but if people feel that it will be bad if they don't hit their immediate goals, they're unlikely to want to contribute to anything but those.

Of course, it's better to be flexible, but when you give someone a goal, the goal is, well, the goal.

[Jensson]

If the company need those team to help other teams, then those teams should have OKRs to help other teams. A good OKR is that they need to respond and/or fix things in X hours etc, depending on what kind of support they are expected to give.

OKR shows you the state of the current organization, if the OKR are dysfunctional the organization is dysfunctional, it would be even if you didn't see the OKRs. The fix isn't to remove the OKRs, it is to align the OKRs with what each team is really expected to do as I said above.

If the team you need help from had an OKR to help you quickly, so they focused on that, do you really believe that would be a bad thing? That is the only way to do it, such teams are slow to respond and provide help everywhere that doesn't give them OKRs to reduce latency on responses, they always have their own things to work in regardless if they are visible or not.

Such OKR also makes life easier for that team, now they get rewarded for what they are supposed to do: provide support. And, if they don't have enough people to provide that support, now they have a good case to get more resources to enable them to provide that support.

[stavros]

You're saying that OKRs should be SLAs, instead of hitting specific objectives? Our OKRs tend to be "release these features/fixes", not things like "hit team metrics".

[Jensson]

Depends on the team, but yeah often time that is the most important you can work on, improving SLA metrics are excellent OKRs since they are easily measurable and are grease to the orgs cogs.

[stavros]

Makes sense, thank you.

[dsugarman]

Sounds like a people issue