What is a good OKR vs a bad OKR for engineering?
Updated: Mar 29
OKR can be used in any industry, but here are a some detailed examples of bad and good OKRs just for the engineers.
A good OKR (Objectives and Key Results) for engineering should be challenging, yet achievable, and align with the overall mission and goals of the company. A bad OKR, on the other hand, can be vague, unmeasurable, or not aligned with the company's strategic priorities. Here are some examples of good and bad OKRs for engineering:
Good OKR: Increase code quality and reduce bugs by 20% within the next quarter. Key results: Conduct code reviews for all new features, implement automated testing for critical components, and reduce bug resolution time by 50%.
Why it's good: This objective is specific, measurable, and aligned with the company's goal of delivering high-quality products. The key results are challenging, yet achievable, and focused on improving code quality.
Bad OKR: Work on improving engineering processes.
Why it's bad: This objective is vague and unmeasurable. It's unclear what specific outcomes the engineering team is aiming for or how progress will be tracked.
Good OKR: Increase website loading speed by 30% within the next six months. Key results: Conduct a website performance audit, optimize images and videos, and implement a content delivery network (CDN).
Why it's good: This objective is specific, measurable, and aligned with the company's goal of improving user experience. The key results are focused on optimizing website speed and are measurable.
Bad OKR: Work on improving website performance.
Why it's bad: This objective is vague and unmeasurable. It's unclear what specific outcomes the engineering team is aiming for or how progress will be tracked.