R&D Management 12 min read

How to Write OKRs for Technical Departments

This article explains the history and principles of OKRs, outlines a step‑by‑step process for defining a technical department’s purpose, identifying internal customers and their needs, reviewing past OKRs, and establishing practical guidelines for drafting, iterating, and communicating new OKRs.

Architecture and Beyond
Architecture and Beyond
Architecture and Beyond
How to Write OKRs for Technical Departments

What is OKR

Before writing OKRs, it is useful to understand that OKR stands for Objectives and Key Results, a goal‑setting and tracking framework popularized by Google and increasingly adopted by many companies.

History of OKR

The concept traces back to Peter Drucker’s Management by Objectives (MBO) in 1954, was refined by Andy Grove at Intel in 1968, and later introduced to Google by John Doerr in 1999, where it became a core management tool.

1954 – Peter Drucker introduced Management by Objectives.

1968 – Andy Grove adapted it into the modern OKR model.

1974 – John Doerr learned OKR at Intel.

1999 – Doerr presented OKR to Google’s founders, leading to its widespread use.

Our Understanding of OKR

OKR is not a performance‑evaluation tool but a management method that highlights the most important tasks and focuses on outcomes rather than merely meeting targets.

The benefits include aligning thinking, clarifying priorities, establishing measurable milestones, and concentrating organizational effort on achieving the objectives.

2 How to Write Technical Department OKRs

Key themes for a technical department’s OKRs are business goals, development quality, technical cost, development assets, efficiency, security, organization building, talent pipeline, and infrastructure.

The overall logic is: define organizational positioning, analyze customers and their core needs, review last year’s OKRs, generate new annual OKRs, then iterate, finalize, and communicate them.

2.1 Organizational Positioning

Before drafting OKRs, clarify the department’s purpose by answering three questions: why the company created this department, what unique value it provides, and how its value will be measured.

Why does the company set up this department? (top‑down view)

What unique value does the department deliver to ensure its continuity? (historical view)

Which dimensions will be used to evaluate the department’s value? (implementation view)

Consider three additional factors: focus on business boundaries and capability building, use positioning to precisely guide current work direction, and express the department’s real business value.

Take on strategic initiatives for specific products or services, monitor development efficiency and quality, and deliver top‑class products.

Lead development‑team efficiency measurement and professional skill development, continuously improving product stability and talent expertise.

2.2 Customers and Their Needs

Identify internal customers and extract their core requirements that relate to the technical department’s work, categorizing them into company‑level, business‑level, and department‑level dimensions.

Company level – understand overall corporate strategy and the department’s role (cost, product focus, core capability building).

Business level – align with business OKRs and derive technology‑related points.

Department level – address staff concerns such as personal growth, technical professionalism, and work methods.

This classification resembles a balanced scorecard, covering customer, internal process, and learning‑growth perspectives.

2.3 Review of Last Year’s OKRs

Reflect on the previous year’s OKR outcomes, lessons learned, and areas to continue, using these insights as inputs for the new OKRs.

Pay special attention to documenting failures and preventing repeat mistakes.

2.4 Principles for Writing OKRs

Focus on the most important items; avoid over‑loading.

Write what is within your control and influence.

Make Objectives qualitative and imaginative, then add concrete, measurable Key Results that satisfy the SMART criteria.

2.5 Iteration and Final Presentation

After creating a draft (Version 1.0), discuss it with your manager in one‑on‑one meetings and hold alignment sessions with sub‑team leaders.

The iteration process moves from top‑down to bottom‑up, ensuring unified thinking and focused objectives across the organization.

Finalize the wording, then have the department’s managers present the OKRs to their teams, confirming shared understanding and commitment.

Remember that the department’s OKR is not merely an aggregation of sub‑team OKRs; each team may define its own OKRs based on the department’s guidance.

3 Management Planning

Based on Liu Jianguo’s “Knowledge‑Action: The Path of Technical Management”, management planning consists of four parts: function (team mission and key value dimensions), goals (business, team‑building, and technical), team (structure, talent pipeline, development plans), and path (key tasks, resources, and methods).

These four elements align closely with the OKR creation process, expressing a technical department’s core value and the path to achieve it.

Both management planning and OKRs are tools for achieving team objectives and delivering ROI.

Reference: https://www.okr.com/intro/origin

OKRGoal Settingtechnical managementR&D
Architecture and Beyond
Written by

Architecture and Beyond

Focused on AIGC SaaS technical architecture and tech team management, sharing insights on architecture, development efficiency, team leadership, startup technology choices, large‑scale website design, and high‑performance, highly‑available, scalable solutions.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.