Creating OKRs for Dev Teams
OKRs can help your team to focus, measure and communicate better. Let me show you how to successfully implement them in a Development Team
When a year comes to an end many people run internal retrospectives to depict what went well, what could be improved and what needs to be changed. Then we usually set a number of goals waiting to accomplish all of them but, unfortunately for the majority of us, after 3–4 weeks, we quickly forget them. The same problem for organizations, we put so much effort to visualize and plan towards next year’s objectives but after some setbacks, the urgent usually, overtake the important.
That’s one of the reasons why Andy Grove, former CEO at Intel and author of one of my favorite books High output Management, invented the OKRs. OKRs is a framework that tries to set specific and measurable goals in order to track them over a quarter or a year.
I can see 3 major advantages to implement OKRs at department and organization level.
- Measure, track and improve what matters
- Align your team efforts towards a common goal
- Improve company’s communication and collaboration
Writing OKRs is not an easy task, you have to get it wrong many times before getting it partially right. In my personal experience, it took more than a year until we were comfortable with them. Those common mistakes are easy to avoid if you stick to these 4 simple rules:
- Key Results must be measurable, otherwise, they could become impartial
- OKRs must reflect what is really important for your team/company.
- Keep always in mind the organization’s objectives
- Don’t use them as a justification that everyone is working towards the same goal.
O1 — Help the company achieve Objective X
As you can see this objective is aligned with the 3rd rule. One of the things that makes this objective complex to formulate is that your development work depends on other departments, so take special attention to formulate the KRs in a way that your team can work towards the KR with a high level of self-sufficiency.
In our example, one of the KRs in the company was to increase customer LTV by 7% monthly.
- Reduce the number of signup/login errors < X %
- Release Feature X with less than X major bugs
- Come up with a report that helps Customer Care to easily track LTV
- Set up an engagement marketing tool so Marketing Department can design their workflows
O2 — Improve main services quality
You need to decide what areas of your department should be improved, tracked, or measured. As I mentioned earlier urgent matters overtake the important ones. That’s why one of our priorities in a year is the stability of the running services. If your services are stable and free of major bugs your team can be focused on adding value to the company. Some examples of OKRs are:
- Number of failures in service X < Y
- Number of incidents reported in the Backoffice tool per week < Y
- Number of technical incidents reported by users in the main website/service < Y
- Number of internal bugs reported after a mobile APP is deployed < Y
O3 — Improve Team Productivity
Another good option for your OKRs is team productivity. Some time ago I wrote an article, which was my biggest hit, about how to measure team productivity in dev departments, you can take some of the ideas from there, but remember before setting an objective, measure first. Here are some ideas of KRs that could fit into this objective:
- Lead time to production < X days
- Number of deploys per week > X
- Change fail % < X%
- Bug Creation vs Bug Resolution Ratio > 0.X
- Average time to production from committed code < X minutes
O4 — Improve Team Technical Quality
As you already know, we work in an industry that is constantly evolving, for that reason is crucial to set some of your focus on improving your team’s technical skills:
- Code coverage on new services over X%
- Present at least an internal Tech Friday per developer
- Organize training in area X
- Introduce X new technology in our technical stack
- Organize an external meetup
The easiest way to get clarity on impact is to have OKRs where it’s easy for people to understand how their work lines up to the OKR. Get the right OKRs is difficult because it requires trial, error and analysis in order to craft them properly, but with the set of suggestions described above, I hope you find easy to apply them.