OKRs for Technology Teams

Technology teams are busy. They have roadmaps, backlogs, incidents, security patches and requests from every department. Without a way to focus, effort scatters, and it is hard to say whether a quarter’s work moved anything that matters.

Objectives and key results, known as OKRs, are a goal-setting method used by many technology companies. They give teams a few ambitious goals and a clear way to judge progress. This guide explains how to write good OKRs for engineering, product, data, security and IT operations teams, and how to avoid the usual misuse. It suits a start-up with one team and an enterprise with dozens.

The basics

Google’s guide to setting goals with OKRs describes the elements:

• Objectives are ambitious goals that answer “where do I want to go?” They should be tangible and unambiguous, and describe an endpoint or new achievement, which leaves ongoing maintenance out. The guidance is to pick three to five per team or organisation, since more can spread effort too thin.
• Key results are measurable milestones that answer “how will I know I am getting there?” Each objective should have about three. Key results should describe outcomes, and each needs evidence of completion that is easy to find and verify.
• Scoring: each key result is graded on a scale from 0.0 to 1.0, where 1.0 means fully achieved, and the objective’s grade is a rough average. The suggested sweet spot is 60 to 70 percent. Consistently scoring 1.0 suggests goals are not ambitious enough. Low scores are data for refining future OKRs.
• Cadence: annual and quarterly OKRs, with check-ins during the quarter.
• Transparency: OKRs are visible, so everyone can see what others are working on. They are not a shared to-do list.

Why technology teams use them

• Focus: a few priorities guide trade-offs when demands compete.
• Alignment: team goals connect to company goals and to each other.
• Outcome orientation: the conversation moves from “what did we ship” to “what changed”.
• Ambition: stretch goals encourage creative solutions.
• Transparency: other teams see priorities and dependencies.
• Learning: regular scoring shows what works.

Writing good objectives

An objective is a qualitative, inspiring statement of the outcome you want. Tips:

• Describe a change in the world, such as “Customers get answers to support questions in minutes”, and leave project names like “Launch knowledge base v2” for the initiative list.
• Make it ambitious yet plausible within a quarter or a year.
• Use plain language that anyone in the company can understand.
• Tie it to strategy. Our guide to strategic roadmapping shows how goals relate to priorities.
• Keep it distinct from business-as-usual work, which also needs attention but is tracked elsewhere.

Writing good key results

Each key result should answer “how would we know?”

• Measurable: a number, with a start value and a target, such as “reduce median support response time from 6 hours to 30 minutes”.
• Outcome-based: measure what changed for users, systems or the business. “Ship five features” is an output. “Increase weekly active users of the new feature from 8 to 20 percent of customers” is an outcome.
• Verifiable: the data source is clear and agreed.
• Within the team’s influence, while still stretching.
• Limited in number: about three per objective.
• Time-bound: achieved by the end of the period.

Avoid vague verbs such as “improve” or “support” with no number.

Examples for technology functions

Product and engineering

Objective: New customers reach value on their first day.

• Cut median time from sign-up to first successful use from 3 days to 4 hours.
• Raise day-seven activation from 35 to 55 percent.
• Reduce onboarding support tickets per new account from 1.4 to 0.6.

Platform and reliability

Objective: Our platform is dependable enough that customers stop thinking about it.

• Keep availability of the core service at or above 99.95 percent, measured monthly.
• Cut mean time to recover from incidents from 90 to 30 minutes.
• Reduce repeat incidents from the same root cause by half.

Our guides to observability and DORA delivery metrics provide measures that suit such key results.

Security

Objective: Attackers find us hard to compromise and we spot problems fast.

• Enforce multi-factor authentication for 100 percent of staff and contractors.
• Reduce the time to patch critical vulnerabilities from 21 to 7 days.
• Complete an incident response exercise with all key roles, and close 90 percent of findings.

See our guide to incident response planning.

Data and analytics

Objective: Leaders make decisions with data they trust.

• Publish agreed definitions for the ten most used measures.
• Bring data freshness for core dashboards to under two hours, 95 percent of the time.
• Increase weekly active users of the executive dashboard from 12 to 40.

IT operations and internal platform

Objective: Engineers can ship without waiting for infrastructure.

• Reduce median time to create a new environment from 5 days to 1 hour.
• Move 80 percent of services onto the standard pipeline.
• Achieve a developer satisfaction score of 8 out of 10 in the quarterly survey.

Our guide to platform engineering explains why internal platforms need product-style goals.

Committed and aspirational OKRs

Many organisations distinguish:

• Committed OKRs: expected to reach 1.0, such as meeting a regulatory deadline. Failure is a problem to explain.
• Aspirational OKRs: stretch goals where 0.6 to 0.7 is a good result.

Label them so people understand the expectation.

Setting OKRs: a practical cycle

1. Start with company or department priorities. Share them early.
2. Draft team objectives with input from the whole team, managers included.
3. Write key results with baselines and sources.
4. Check alignment: do these support higher-level goals? Do they depend on other teams?
5. Cut the list: fewer is better. Say no to what is not a priority.
6. Review in a session with stakeholders, to test clarity and ambition.
7. Publish where everyone can see.
8. Check in weekly or fortnightly with a simple status: confidence, progress and blockers.
9. Mid-period review: adjust plans, or change a key result if it proves wrong.
10. Score and reflect at the end: what did we learn? What will we change?

OKRs and roadmaps, backlogs and metrics

• Roadmap: the plan of initiatives. OKRs state the outcomes the initiatives should achieve. The roadmap can change when evidence shows a better route to the same OKR.
• Backlog: detailed work items, which should link to key results.
• Health metrics: reliability, quality and security measures that must stay healthy while you pursue goals. Track them separately, as guardrails.
• Performance reviews: keep OKR scores out of individual evaluations. Linking them to pay or ratings encourages sandbagging, which means setting safe goals.

Common mistakes

• Too many OKRs. Everything is a priority, so nothing is.
• Activities as key results, such as “run three workshops”.
• Vague wording with no number.
• Setting and forgetting: OKRs written in week one and reviewed at quarter end.
• Using OKRs as a task list. Google’s guidance warns that they are not a shared to-do list.
• Punishing low scores, which kills ambition.
• Cascading rigidly, forcing each team’s OKRs to mirror those above, which removes local insight.
• Ignoring dependencies between teams.
• Metrics that can be gamed, such as counting tickets closed.
• No baseline, so progress cannot be judged.

Technical debt and non-feature work

Teams often struggle to place maintenance, security and technical debt. Options:

• Include them as objectives when they are strategic, such as “Our platform can handle ten times today’s load”.
• Reserve a fixed share of capacity for health work, and track it as a guardrail.
• Express the business effect, such as reduced incidents or faster delivery, so it competes fairly with features.

Making OKRs work in practice

• Leadership model: leaders share their own OKRs, and discuss scores openly.
• Training: brief teams on writing and scoring.
• Simple tools: a shared document or lightweight tool is enough at first.
• Regular rhythm: same day, same format.
• Celebrate learning: discuss missed key results as well as achieved ones.
• Review the process itself every few cycles.

A starter approach for one team

1. Pick two or three objectives for the next quarter.
2. Write two or three key results each, with baselines.
3. Review as a team, and trim.
4. Check in every Friday for ten minutes.
5. Score at quarter end, and write down three lessons.

How SoftSapien supports goal setting

SoftSapien’s advisers help technology leaders define outcomes, choose measures, set up OKR routines and connect goals to delivery. See our business advisory consulting and business services.

To set up OKRs for your team, use the contact page to chat with our team, send a message or schedule a free consultation call.