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.
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
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.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.