Teams who are used to being told what tactics or outputs to deliver often fall into the trap of duplicating their plans and reports in their OKRs. At best, they may be able to “slice” a major project into delivery milestones which fit into various quarters. But these are not OKRs. When this happens, teams will feel frustrated because they’re doing the same planning and tracking work in two different places: calling it “project management” in one area and “OKRs” in the other. At worst, teams with rigid, long-term, tactical aspirations won’t be able to identify any quarterly OKRs at all and may choose something arbitrary simply to feel like they’re complying with (what feels like) a useless, externally mandated process.
This can make your OKR adoption process very difficult.
When this happens, it helps to remember that OKRs describe an ideal end-state and how you will measure the degree to which you’ve “arrived”, but NOT how you will reach that end state. It may require dreaming up, trying, discarding, and pivoting away from many different tactics before you see any movement in your key results. This is fine. As you gain experience (and data), allow your list of tactics to become a constantly evolving backlog of things to try next to achieve your outcomes. Conceiving, refining, and delivering initiatives (or tactics) is standard discovery and execution work. You already know how to do this. But let your OKRs be the constant which guide your choice of tactics and give you permission to experiment freely. Think of OKRs as your North Star while you wayfind the most direct path.