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.
1Points per sprint as an OKR? Damn that would be easy to game! You could just make sure you never estimate smaller than 20 and boom, you're set Jun 20, 2020 at 17:58
6@tddmonkey I did not say it would be useful or representative of anything, just that it would be valued. :) Jun 20, 2020 at 18:25
My problem with such an OKR is that I might not even work on an "agile" project, might not even have sprints... I think client revenue is the thing that matters the most for my boss. I have only very indirect way to influence it (somehow persuade the client to extend my assignment). Actually this would make some sense as a goal, but I'm very reluctant to commit to it, because it's the decision of the client, not the direct result of my work. For example the client might not extend me if they managed to build in-house competence, so they no longer need outside contributors. Jun 21, 2020 at 13:30
@MyFullName And herein lies the problem with OKRs to begin with; it can be gamed, and it can become real shady. Pushing revenue can get real shady real fast.– NelsonJul 8, 2020 at 8:19
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
Thanks for your input! The "higher level objectives" are stuff like "be profitable", "low staff attrition" and "high customer satisfaction". These boil down to "do your job well" - which is both obvious and not that useful to set an OKR :-) The conversation with the boss wasn't really helpful, he just pushed me to set something. Jun 21, 2020 at 13:44
tbh if your management isn't providing any input - just come up with something you want to do and is achievable. At this point the entire exercise seems quite pointless! Jun 21, 2020 at 16:16
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.