OKRs for engineering can be tricky if the team is not used to outcome based goals.
There are almost as many engineering setups as there are teams. The roles, and responsibilities differ a lot between teams and so should their OKRs. Overall however, engineering teams are many times far from the business outcomes and there is no value in putting up key results about profit or growth if the team has too little direct impact on those metrics. The same goes if an engineering team gets their work from a product team with a list of projects. Instead, most engineering teams start to measure process, how fast they ship, how good they are at estimating ticket size or the quality of their features delivered.
Software development OKRs work best when the delivery system itself is the objective: speed, reliability, and the trust engineers place in their own pipeline.
Mål: Green means go: make the test suite worth trusting again
Coachens poäng ★★★★★
Measurable ★★★★★
Outcome-based ★★★★★
Focused ★★★★★
Niklas Olsson · OKR-coach
Mål: Turn incidents from firefights into routine
Nivå: Team Team: Engineering Bolagstyp: SaaS
Measurable ★★★★★
Outcome-based ★★★★★
Focused ★★★★★
Niklas Olsson · OKR-coach
This looks like a team with a lot of incidents, and maybe this is their only OKR for the quarter, to really get this part of the work in order. From that perspective it is a good reminder that OKRs are just for the changes you want to achieve. Of course they will do lots of engineering work that is not about incident management, but the core change they need this quarter is how they manage incidents. It is a strong OKR.
The main gap is that the objective could be a little more inspiring, or connect stronger to strategy, to the business, or to the customer. "Turn incidents from firefights into routine" is just the what. An alternative could be something like: enhance our customers' experience of the software through best-in-class incident management. More inspiring, and it makes clear why this matters.
Features are the plan, not the goal. An OKR earns its place by naming what the features are supposed to change: activation, reliability, speed of delivery itself. When a roadmap item is genuinely the point, track it as a project and keep the OKR for the outcome it serves.
They are a strong starting point because the baselines are already in your tooling. The caution is that they measure the delivery system, not the product. A team can deploy twenty times a day and still ship things nobody uses, so pair a delivery metric with at least one key result about what reaches the customer.
OKRnest ger ditt team strukturen som exemplen bygger på, och en veckovis check-in-vana som håller dem vid liv. Gratis för upp till 3 användare.
This is a strong OKR overall, well crafted. We could wish for the objective to have a little more inspiration, or to more clearly give a why: why this is important, connected to strategy or business goals. It is often hard for engineering teams to identify real core outcomes and key results, but all of these are examples of just that.
What you see with engineering OKRs is that key results are often very hard to make understandable for the rest of the organisation. That makes it even more important to have an objective that clearly connects to business outcomes, or to how this actually helps the team, and is not framed as an internal matter like in this example. Overall, very strong.