| My current employer use OKRs to align the different levels of the org and to help each team structure their work. We use an approach that is mostly owned on the lowest level; company leadership set long and medium term objectives for the company, area/department heads set goals for each 4-month period, and each team gets to work out their own OKRs for the next period. The team objectives do not not need to match area objectives 1-to-1; area objectives are mostly guiding. I started rather recently, and I'm in my second OKR-period currently. This has been my first experience with OKR, and so far it's been on the strong side of positive; we get some guiding principles to work towards (but nothing too concrete or checkbox-final) and it works well. Sure, we won't be able to solve everything we write down, but our team is aligned on our own direction and a course that we control ourselves , to a large degree, but still within the overall goals of the company. In my experience, software engineering is about 20% creating the solution, 15% tuning and debugging the solution and 65% understanding the problem. Within this perspective, the work of talking through the problems that your team is working to solve, and contextualizing why you're solving them, is highly valuable and counts towards understanding the problem. The process of defining OKRs, within the correct frame of reference and expectations, can work very well for this. IMO, using the backlog to define upcoming work can enrich this process as well; it brings context, but should not becone the final OKR "product" alone. I've only ever encountered OKRs on a team level, but I cannot grasp the value they bring as individual goals. The real value in OKRs lies in the process leading up to defining them, not the objectives and results themselves. A recurring theme in the horror stories I've read regarding corporate strategies is that they tend to be implemented with a goal of rigidity rather than fluidity. And making rigid processes that aren't compatible with team autonomy brings with helplessness and alienation between the goal-setters and those working to deliver. |
I couldn't agree more, and the article is headed in completely the wrong direction.
Companies fail at using OKRs when they are rigid about treating OKRs as a measure of successfulness of the team. In my experience, the true goals almost always become clearer as the quarter progresses, and hitting the OKR objectives you set months ago is a sign that your team is not flexible enough to solve the real problems. Oversimplifying your work into key results also hides the true status. It overemphasizes measurable, but meaningless, metrics over truly checking the work for quality.