[russfrank]

No, they are completely different things. Real time chat doesn't make people feel like they understand the overall goals of an organization. If someone says in Slack "we really need to get x done because the customers want it" and other people decide to talk about StackOverflow's hilarious April fools day joke for 5 minutes, some are going to miss that "we really need to get x done".

Your OKRs put that sort of thing in one place. The process to determine what the OKRs are ensure that everyone's on the same page about the objectives. People in an organization want to feel like they know what they're working towards. When they don't they get stressed out and unproductive.

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