I write software that is used entirely internally by the company. We are building something completely new from scratch that is not yet live. OKRs were recently introduced at our company. The only OKR I can even think of is "get this thing functioning and in production". Just a boolean. I wanted to come up with something measurable, but what is there to measure?
I don't understand how OKRs are appropriate for employees without the power to make business decisions. My only goals are to come into work, do what is expected of me, get paid, not get fired, and go home. I do not have power to decide anything with quantifiable results. If I did, writing OKRs and working towards them would be extremely easy.
If I did have any power to make business decisions one of the first things I would do is make any employee without any power exempt from having to even think about stupid OKRs.
Break it down into milestones. What's the minimum piece you could complete that would be usable by someone (even just a beta user to gather feedback)? What's the next incremental piece that would be useful after that?
You can measure milestones completed, and you can also apply some type of scoring to the feedback you collect from your beta users. If your beta user feedback is "This is terrible, it doesn't do the key thing we need to do for our jobs!", that's actually a great outcome, because you can course-correct early, rather than having to revisit 1+ years of eng work to address the feedback.
> My only goals are to come into work, do what is expected of me, get paid, not get fired, and go home.
OKRs should just be the process of you writing down "what is expected of me" in a somewhat structured and measurable way. Team OKRs of "Hit milestones #1, #2, and #3 in development roadmap of system X" are fine, and are pretty common for greenfield projects. The main key is to have a "definition of done" for each milestone - does the milestone include documentation? Monitoring? Who decides that work is complete?
Software is usually written to help reduce effort. Measure effort with and without the software. Reduce effort usually means better bottom line for the company which give you a great positive for your next performance review.
Meaure the usual software engineering metrics, ie defect count, defect closed, velocity, delivery timing etc.
I think that everything that we do in a company has a cost for the company. At the most basic level, you and I cost money as the company is paying us money for the work we do. You need to think from that perspective.
I don't understand how OKRs are appropriate for employees without the power to make business decisions. My only goals are to come into work, do what is expected of me, get paid, not get fired, and go home. I do not have power to decide anything with quantifiable results. If I did, writing OKRs and working towards them would be extremely easy.
If I did have any power to make business decisions one of the first things I would do is make any employee without any power exempt from having to even think about stupid OKRs.