3 Reasons OKRs Are Great For Software Engineering Teams (And Some Drawbacks)
Objectives and Key Results (OKRs) are great for software engineering teams! Before we dive into the why, a few words on how we define OKRs for the sake of this article:
- A way to write down goals for organizations and teams as an objective (a sentence which describes your goal in clear and inspiring language) and a set of key results (metrics which tell you if you’re making progress towards the objective), for a cycle of several months, usually three.
This ☝️ is what most literature on OKRs focuses on, but to work effectively with them, there should also be:
- A planning process wherein all teams autonomously draft their goals, balancing contributions to company and department goals with their own, internally motivated goals. For example, an engineering team might set a goal to ship features in order to drive revenue, but also propose a goal to address technical debt.
- An alignment process, during which all teams plan their capacity to check if their goals are realistic, and request support from other teams, where needed. This step is why it’s important for all teams to do their planning at the same time — before you lock in your goals, you need to know what other teams need from you.
So, how can OKRs help engineering teams?
🏚 Tackling Tech Debt
OKRs provide a frame to plan and negotiate large technology investments.
At the end of an OKR cycle, the whole company is busy planning the next one. This is the opportunity for software engineers and their leadership to step up and throw their hat in the ring, too: Let’s finally upgrade those outdated dependencies … Let’s work on bringing down pipeline runtimes … Let’s rewrite that legacy component …
I’ve seen an alternative approach all too frequently: Allotting some capacity, say 20% of every sprint, to “technical tickets”. This is bad for two reasons: Some large initiatives can’t effectively be chopped up into small bits of (bi)weekly progress. Not to mention that those “technical tickets” are usually the ones to spill over to the next sprint …
Secondly, this avoids discussion with the product manager (PM) on what engineering work gets prioritized. I argue that this discussion is healthy and necessary — without context from product management, engineers might prioritize the wrong refactoring work. Conversely, aligning refactoring projects with the product strategy is your best bet of actually securing investment in technical debt.
Discussing the business impact of refactoring is difficult, and engineers should be prepared to take no for an answer when suggesting initiatives. But it’s a muscle that should be trained early and frequently.
🤝 Collaborating With Other Departments
OKRs, if used company-wide, put all departments on the same planning rhythm, using shared vocabulary.
If you’re in the software industry, this may seem familiar: Sales approaches product after a client pitch meeting, and requests features so they have a chance of winning the deal. Product talks about just having kicked off a “sprint”, being in the middle of a “refactoring”, and putting their requests on a “backlog” … These sounds like excuses to sales, leading to frustration.
OKRs force you to zoom out from individual events (client pitches, sprints in this example), and express mid-term goals instead. Sales and product will also be on the same planning process and tooling, making collaboration easier.
And requests can go the other way, too: If product management initiates the launch of a new product, they may request support from sales and marketing to kickstart it. Without further direction, sales might stick to selling the company’s cash-cow products. But product can negotiate with sales leadership to introduce a spiff, basically paying higher commission for selling the new product while product-market fit and the pitch may not be perfect yet.
🎯 Knowing What Success Looks Like
The best OKRs measure customer value and impact on company results, empowering engineering to know the value of their work.
At this point, let us distinguish OKRs from agile processes such as Scrum and Kanban:
Good OKRs work well with agile processes, instead of competing with them. Generally, OKRs measure outcome, while agile manages work, or output. “Ship 4 Features” is a bad key result, even worse if it nails down specific features. “Reach 1M Monthly Active Users” is a better one — leaving it open which features, and how many, are needed to achieve the goal. Said another way, OKRs can help you deliver on the agile promises of “customer collaboration” and “responding to change”, by stating goals related to customer value without locking you into a specific plan.
Software engineers have a unique perspective on their product, which a company should leverage: They should have a forum to present their feedback and ideas for product improvements. They might have ideas for reducing scope while reaching nearly the same outcome. Not to mention what knowing their purpose does for employee engagement … All this becomes possible if engineering has visibility on the impact of their work, for example through OKRs.
OKRs have some costs and drawbacks to be aware of:
- Not everything fits neatly in three months. Putting your company on a fixed planning cycle might cost you some speed. Ideas or priorities that come up during a cycle will either have to be pushed back, or will force you to replan. The inverse is true as well: Some initiatives take longer than three months to show customer value, and are awkward to express as OKRs.
In the companies I’ve worked, a planning horizon of three months is a good compromise between stability and agility — your mileage may vary, especially in early-stage startups. And look for opportunities for incremental value delivery in your long-term initiatives. Working on multi-month projects without any customer feedback is risky.
- Lots of time invested in planning and meetings. Good OKRs take time to put together. Especially the alignment with other teams is costly — many companies have in-person workshops or hour-long video calls, followed up by many individual alignment meetings. Even if you manage to do much of your planning asynchronously, it can take as much as a full work week out of your quarter.
- Writing good OKRs is difficult. Some engineering efforts just don’t lend themselves to being expressed as an OKR. Often, that’s the case for DevOps teams, or for investments which are about managing risk instead of immediate payoff, such as security. I’d rather let teams set an OKR that reads “Migrate to AWS” instead of forcing them to write a convoluted sentence. But then you better have good metrics in your key results to show the impact of your work!
I’d love to hear about your good and bad experiences with OKRs in software engineering teams!
If you’re interested in learning how to conduct an OKR cycle, check out my company’s online training. For teams of ≤100 people, Workpath Light is a dirt-cheap way to get started using an OKR tool. And if you’re interested in experiencing the benefits of OKRs, and bringing them to other companies, check out our open jobs!