I work as a software developer at a company that is in the business of lending developers to other companies. Internally there's a yearly performance evaluation process where we (as employees) are supposed to set a few OKR (objective and key results) for the next year. My problem is - what OKR shall I set? Due to the nature of the business I can't really set anything software project-related (e.g. "increase test coverage to 75%") because at the moment I'm waiting for my next assignment, so I don't know what kind of project I'll be working on next month (if I'll be working on anything at all). "Personal improvement" OKRs ("read two books on software development") don't seem to be neither objective nor key.
Welcome to a very unsolved problem in software development.
As an industry, we have never figured out a reasonable set of OKRs. Everything from lines of code to tickets completed to number of points completed to bugs fixed to lack of bugs has been used.
There is no consensus on any development OKRs and plenty argue that nearly any implementation of numerical OKRs is going to cause unwanted behavior.
I would choose something my organization values
The lack of an industry consensus on OKRs for developers makes them a matter of business values and therefore highly political.
In one company, increasing test coverage to 75% would be a worthy goal.
In my organization, management would shrug at that and while it would be considered a good achievement, it would not be considered an important one.
In a startup a friend of mine works for, he would receive a lower performance review for focusing on that instead of focusing on new features. Increasing unit test coverage would be considered wasteful.
Only you can answer what matters to your boss. Is it client revenue? Is it client satisfaction (be careful here though)? Is it speed?
Here is what I would choose based on what matters to my organization:
- Successful completion of a minimum of 20 points per sprint with an average of 25 points per sprint over the long term.
Here's what I understand about OKRs: the setting of them should be a collaboration between you and your manager. The manager sets the objective and you come up with they key results to show you're meeting the objective. In addition, the objective should be linked to objectives set at a higher level in the business as well.
The setting of OKRs in isolation isn't really providing value, so if I were you I'd be going back to my boss to see if they will work together on it, and find out what the higher level objectives of the company are so that yours are aligned
The use of annual goals when the time on a project is much shorter than that doesn't make a lot of sense. I know many companies that keep to the annual cycle, even when their own documents say that when you switch projects/teams you should be evaluated and then new goals added based on the new position.
Trying to write goals that aren't linked to your daily activities limits your ability to write specific relevant goals.
Depending on the project I was assigned to the goals could be linked to improving a metric, fixing a specific problem or completing a new feature. The goal should be based on what the customer wants and what the company wants. Writing a goal related to points in a sprint wouldn't make sense if the project doesn't use that method.
Multiple evaluations during the year seems daunting, but it is the only way to get specific goals that are linked to your projects. Sure there can still be non-project related goals such as training, or getting a certification, but to get ones that show that you are helping the customer you need ones linked to the customer.