Since the release of Measure What Matters, John Doerr’s book on the Objective and Key Results methodology, hundreds of tech startups have tried to roll it out internally. But, more often than not, especially for engineering teams, with little success. The main challenges I’ve heard from the CTOs I work with are the seeming incompatibility between OKRs and the daily job of software engineers. More specifically, there seems to be some confusion between OKRs and Roadmapping.
According to these CTOs, if there is a product roadmap, the software engineers’ objectives are clear: build and push the items on the roadmap to production. In this case, no need for OKRs: the objectives and the Backlog are the same. And if there is no roadmap (or if the roadmap is constantly changing), then it’s impossible to set any objectives. Again, no need for OKRs. Unfortunately, this conclusion is based on the fundamental misbelief that an engineering team’s goal is to execute the product vision. CTOs who believe this most probably measure their software engineer’s performance to code and ship features. A bit narrow. By the way, it’s also this misbelief that creates never-ending tensions between product (with infinite ideas) and engineering (with finite resources), since independently of the engineering team’s size, it’s never enough to ship new products.
In The Goal, the classic management novel that introduced the Theory of Constraints, Eliyahu Goldratt wrote that the goal of a company is to “make money by increasing throughput while simultaneously reducing inventory and operating expenses”. If we apply this definition to an engineering team:
- Making money is acquiring and retaining users;
- Throughput is the Time to implement, test, and deliver code for a feature (aka the Lead Time for Changes)
- Inventory is the Backlog
- Operating Expenses is the Time spent working on bugs and failures[1]
Using Goldratt’s (slightly modified) definition, the goal of an engineering team is to acquire and retain users by increasing Throughput while simultaneously reducing Backlog and the Time spent working on bugs and failures. You can then formulate objectives for an engineering team, independently of the product roadmap.
Let’s take, for example, a startup in a space with very high competition. The company’s OKR for this year is:
- Objective: Improve customer retention to drive up revenue
- KR1: Re-design in-product onboarding so that churn before 3 months < 1%
- KR2: Number of customer complaints related to bugs and platform failures < 10% of total complaints
- KR3: Improve customer success organisation to reach an NPS > 50
In this example, Key Result 2 is for the engineering team. More specifically, the objective here is to decrease the time spent on bugs and platform failures. Indeed, since the startup is growing fast, engineers have to take technical shortcuts and don’t have time for testing. To meet their objective, the CTO could formulate the following OKR:
- Objective: Number of customer complaints related to bugs and platform failures < 10% of total complaints
- KR1: Reduce bugs reported after the release from 20 to 5 on average
- KR2: Increase code unit test cover from 30% to 50%
- KR3: Hire a QA engineer in Q1 to design and implement automated testing
As you can see from the example above, this OKR is entirely independent of the product roadmap. And based on the above definition of an engineering team’s goal, a CTO could also formulate their objectives based on reducing the Lead Time for Changes (what can we do to ship features faster?) or reducing the Backlog (what can we do to limit the Backlog?). The resulting Key Results would be varied, impacting the team’s organisation, processes and tools, as well as individual team members.
If we keep the above example, but for the team member level, the engineering manager could have someone in their team who has a high bug rate. In this case, and after identifying that the problem is related to not having enough knowledge of the codebase and code quality, they could create the following OKR for them:
- Objective: Reduce bugs reported after the release from 20 to 5 on average
- KR1: Write/update documentation for the code they know less
- KR2: Spend 2 hours per week pair programming with a senior engineer in the team
Last but not least, remember that OKRs are not just handed over to team members but should also come from team members. Suppose multiple engineers feel that they should refactor the current codebase to meet the quality objectives. In that case, the CTO has to consider reducing the new products’ objectives in the process.
[1] Regarding operating expenses, I chose not to take it in the literal sense (operating expenses = salary) since it doesn’t make sense to reduce the number of engineers in a team, or worse, decrease their salary. It makes more sense to think of operating expenses as time spent not delivering value directly to users.
In Summary
Are you ready to scale your engineering team and grow as a leader?
Membership includes weekly live learning sessions, online resources, exclusive events and a community of 100+ engineering leaders