Team Level OKRs

Objective 1: Create a high performing engineering team

Key results:

1. Hire 10 new engineers by end of Q2 FY 2017-18
2. Agree & document performance measurement metrics for individual contributions
3. Increase knowledge & enhance skill sets of team members by ensuring each one participates in at least one of the industry-wide hackathons

Discussion:

Look at the objective & it will become crystal clear that the same objective can be equally applicable to any company. The actual difference is made by the key results, how are you measuring your success. These key results will definitely be different for different teams, although they may have the same objective.

Also, whether this is a team level objective or a company level is going to be dependent on the size & stage of the company. If the company is at an early stage & engineering is its core function, this can sure be a top level objective.

Objective 2: Increase quality of releases and and make sure they are timely

Key results:

1. Less than 2 major priority bugs found in production
2. Increase unit test coverage to 75 % from current 45 %
3. Engineering teams contribute 1200 code reviews by end of every sprint
4. Not a single release to go beyond planned date, meeting the condition that story points delivered every release are at least 90

Discussion:

Similar to the first example, the objective here can be quite common to any software team. Definition of key results is what differentiates every team from one another.

Be as detailed as possible in defining the key results. Try to counter the (somewhat natural) tendency to compromise on one aspect while trying to succeed at another. As an example, look at the 4th key result above. While not exceeding the planned release dates is the primary measure of success, it shouldn’t happen at the cost of delivered story points every release. Thus there is a minimum acceptable limit defined as ‘at least 90 story points are delivered every release’.

Objective 3: Increase efficiency of QA processes

Key results:

1. Test cases for all P1, P2 stories are completed & handed over to dev before development starts (compliance to be measured every sprint)
2. 1 week before release date, no blocker & critical bugs should be open
3. Bug leakage to production for critical issues is less than 1%
4. Less than 3 bugs reported by end users per release

Discussion:

First key result defined above is an interesting example. While there is nothing wrong with its definition, what we have observed almost always is – it is never measured at all in reality. The point we are trying to send home is – if you are not already measuring something & are introducing it as part of a key result, make sure the details for measurement are carved out right there. For example, by adding the sentence ‘compliance to be measured every sprint’ we are ensuring that there is no space for different interpretation.

Objective 4: Increase data security and prevent breakdown incidents

Key results:

1. 100% data recovery due to daily backup of critical data
2. Review and improve existing security measures
3. Number of breakdowns reduced to 1 per quarter
4. Upgrade processes and reduce data migration time by 80%

Discussion:

2nd key result above (the one that is struck through) is a very common mistake that we have come across, frequently. There is no measurable parameter that can tell whether the key result was achieved. It leaves too many things open to interpretation that it doesn’t suit definition of an ideal key result.

Objective 5: Increase infrastructure reliability

Key results:

1. Provide state-of-the-art tools and softwares to increase productivity by 30%
2. Reduce breakdowns in the peak hours by 90% (in the last 6 months some of the APAC users have experienced intermittent outages during US-Mountain time office hours)
3. Conduct a training program for employees to impose best practices in infrastructure configurations (we want to avoid a repeat of the John Doe incident, where an inefficient configuration led to burnout of application servers)

Discussion:

Provide as much context as possible with the key results. Notice KRs 2 & 3, in the above objective. Additional information available in the brackets can be a quick reminder of the importance of these key results. Also it can surface contextual data that may actually help in achieving the key result.

Do note that this additional bits of information does not need to be added to the key result title itself, it can be available within the KR description.

Objective 6: Implement Agile project management across engineering organisation

Key results:

1. All the projects within engg department are fully agile before end of quarter (definition of ‘fully agile’ is available in objective id OBJ-123)
2. External agile coaches are hired, 1 coach for every 2.5 projects
3. Tweaks, deployment parameters for Acme agile (our flavour of agile) are agreed upon, documented with all project managers & COO

Discussion:

Notice how KR1 above clearly articulates relationship with another objective. This can be a little tricky if your OKR software does not offer the linking/alignment feature.

Individual Level OKRs

Objective 1: Build a product that our customers love & is successful

Key results:

1. Achieve Net Promotor Score (NPS) of 9
2. 25% pre-signups come from existing customers
3. Get 1 referral for every 3 customers (aka viral coefficient)

Discussion:

More accurately measurable your key results are, better are the chances of achieving them & thereby the objective. This becomes especially true in case of engineering team members who are more inclined to measuring numbers.

Objective 2: Increase quality of coding

Key results:

1. 40% reduction in runtime warnings
2. Create a checklist of standard procedure to follow
3. Introduce a test automation framework that runs all tests on each code commit
4. Practice mindful thinking and meditation to increase concentration and productivity

Discussion:

Your KRs don’t always have to reflect things related to work. One can always be creative about achieving goals by doing things a little differently. For example, the 4th KR above is markedly different than the others. But at the same time it is equally important in achieving the parent objective.

Objective 3: Improve performance of the product

Key results:

1. Reduce number of critical bugs by 15%
2. Increase stability of performance from 25% to 35% (definition is available in the description)
3. Create FAQ sheet and enable customers to optimise use of the product

Discussion:

None