| In my dysfunctional organization we spend half of every quarter planning OKRs for the next. First we have to collect all of the O's from top down and adjacent team blockers. Then we have to craft measurable KRs. Engineers are usually involved to size the effort of each. Then we need to make sure the total size maps to our bandwidth. We spend weeks prioritizing, and negotiating, pushing back up and to the side the work we can't take, and organizing cross-team dependencies to refine them to the final prioritized set. At this point engineers have been dragged far into the planning process for sizing and have been thrashed by hearing glimmers of a chance to work on project X only to find out it's de-prioritized for project Y and now they have to size that effort instead. The PMs will remind you if there isn't a number or a binary-sounding deliverable in every KR, and will hound you about getting a baseline and building the measurement tooling if there isn't one available. Sometimes making something measurable means instrumenting A/B tests, building dashboards, or instrumenting some metric capture. If it can't be measured, it can't be done in the OKR framework. Once we begin the actual work In the glorious 4-week period where we aren't planning our next quarter OKRs, we're meeting daily and weekly to report progress at different levels. It's exhausting. This is where a lot of blatant funny business occurs with how folks measure and report progress that destroys the whole process. I think on paper OKRs sound logical. Concrete goals and measurable deliverables are good. In practice it's a huge time suck and far less actual progress is made. It's a toilsome framework and a drain on morale. The only folks who seem to like OKRs are upper-management and PMs who are so detached from actual work that it's the only way they can feel like things are happening. |