[sandGorgon]

I don't fully agree on this notion. Because implicitly doing this is also surfacing the gaps in achieving those targets.

Most okr are dependent on someone else - the Android app guy will not achieve their okr if the API guy is off doing something else. In that way, the whole aspect of goal setting and achieving that is probably more inefficient using an okr structure than thrashing it out on slack (and most likely in a dedicated channel called "planning")

[russfrank]

If you only have six people, maybe :] But we're commenting on a post that's talking about the best time to introduce an OKR process. At my company we don't have an "API guy" and an "Android app guy", we have 30 or so different teams that my team interfaces with in a company with thousands of engineers. We can't just "thrash it out" on Slack at a company of this size.

You need to try and think about what things look like when the company is much, much larger.

[Jtsummers]

OKRs aren’t supposed to directly depend on anyone outside the team or organization. I, personally, can’t fix my contracting office so I can’t set an OKR to improve production rates of our (few) physical products when contracting is always the bottleneck (supplier agreements for materials we need). If we used OKRs, with respect to that element we could only set OKRs that they could achieve on their own (quality, design updates, production rates when they do have material). A couple levels above me are the people who can directly impact the contracting people and set about improving their performance, though.

If you’re setting them and always missing them because of entities with other objectives, then your organization is obviously misaligned and needs to evaluate its goals.

[titanomachy]

OKRs can help solve this problem, if they're done well. Your OKR that depends on the API guy should derive from some common OKR that's owned by a guy up both your reporting chains. You can point at that to help make sure you get unblocked.

[NewsAware]

We use OKRs on a team level with the teams of 6-8 people being cross-functional. So the Android and the API persons would have the same OKRs working towards to.