惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Vercel News
Vercel News
Recorded Future
Recorded Future
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
The GitHub Blog
The GitHub Blog
Application and Cybersecurity Blog
Application and Cybersecurity Blog
Google DeepMind News
Google DeepMind News
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
Microsoft Azure Blog
Microsoft Azure Blog
K
KPMG report finds enterprise disconnect between AI and its ROI | CIO
M
MIT News - Artificial intelligence
云风的 BLOG
云风的 BLOG
Y
Y Combinator Blog
N
News | PayPal Newsroom
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
Help Net Security
Help Net Security
博客园 - Franky
SecWiki News
SecWiki News
Recent Announcements
Recent Announcements
T
Troy Hunt's Blog
The Register - Security
The Register - Security
The Last Watchdog
The Last Watchdog
Webroot Blog
Webroot Blog
S
Security Affairs
博客园 - 司徒正美
S
Schneier on Security
I
InfoQ
博客园_首页
www.infosecurity-magazine.com
www.infosecurity-magazine.com
T
Threat Research - Cisco Blogs
Forbes - Security
Forbes - Security
腾讯CDC
N
Netflix TechBlog - Medium
N
News and Events Feed by Topic
Cloudbric
Cloudbric
T
The Exploit Database - CXSecurity.com
P
Proofpoint News Feed
A
About on SuperTechFans
Engineering at Meta
Engineering at Meta
Recent Commits to openclaw:main
Recent Commits to openclaw:main
B
Blog
V
Vulnerabilities – Threatpost
C
Check Point Blog
Google DeepMind News
Google DeepMind News
Google Online Security Blog
Google Online Security Blog
C
Cyber Attacks, Cyber Crime and Cyber Security
Hacker News - Newest:
Hacker News - Newest: "LLM"
C
Cisco Blogs
Schneier on Security
Schneier on Security
O
OpenAI News
K
Kaspersky official blog

Arpit Bhayani

Temporal Primer - Building Long-Running Systems What Matters in Production RAG Structure of Every LLM Chat How LLMs Really Work Your Monolith Is Already A Distributed System Databases Were Not Designed For This BM25 JOIN Algorithms Venting at Work Comes at a Reputation Cost Why Half Your Skills Expire Every Few Years Multi-Paxos - Consensus in Distributed Databases MySQL Replication Internals Bloom Filters When You Increase Kafka Partitions Product Quantization The Q, K, V Matrices The Day I Accidentally Deleted Production How LLM Inference Works What are Blocking Queues and Why We Need Them Heartbeats in Distributed Systems How Writes Work in Apache Cassandra Redis Replication Internals How to Handle Arrogant Colleagues at Work How Does a CDN Handle Content Replication You Can't Fix Everything on Day One When Emotions Spill Over at Work Why gRPC Uses HTTP2 Meetings With No Agenda Are a Waste of Time Career Longevity Beats Constant Job Hopping Stay Relevant at Higher Salary Levels Why Distributed Systems Need Consensus Algorithms Like Raft Why Do Databases Deadlock and How Do They Resolve It Why and How Cache Locality Can Make Your Code Faster Why Eventual Consistency is Preferred in Distributed Systems Why does DNS use both UDP and TCP Should You Do a Master's My Honest Take Empathy Makes Great Engineers Unstoppable Good Mentors Build People, Not Just Skills Why You Should Always Have Back-Burner Projects Before You Push Back, Know What You're Standing On Be the One They Can Count On How Much Are People Willing to Bet on You How to Get Leadership to Say Yes to Your Project Don't Let Your Best Ideas Die in Silence Be the Person Everyone Wants to Work With The XY Problem and How to Avoid It The Startup Hiring Lie Nobody Talks About You Won't Be Promoted Unless You Ask It's Not Enough to be Right; Learn to be Heard No One Ships Great Software Alone You Don't Win by Proving Others Wrong Appreciate Generously; It Costs Nothing, But Builds Everything Your Soft Skills Aren't Soft at All Before you form an opinion, experience it Why You Need Both Curiosity and Action to Thrive A Daily Worklog Changed Everything How We Handle Mistakes Defines Us Own Your Mistakes Don't Wait. Step Up. Temporary Fixes Are Permanent Why Interviews Are Biased And What Sets You Apart Saying 'This isn't my problem' is actually the problem Never Lose a Battle due to Miscommunication When In Doubt, Code It Out How to Follow Up Without Annoying People Lead Projects That Land, Execution Over Everything Abstract Thinking Will Define Your Next Decade We Engineers Suck at Task Estimation Shiny Obect Syndrome in Tech When to Change Jobs - The 3P Framework Comfort and Competition - Know When to Switch Gears Paper Notes - On-demand Container Loading in AWS Lambda Paper Notes - SQL Has Problems. We Can Fix Them Pipe Syntax In SQL Paper Notes - NanoLog - A Nanosecond Scale Logging System Don't Wait, Learn - The Best Resource is Mythical Paper Notes - WTF - The Who to Follow Service at Twitter The Unexpected Benefit of Reading Random Engineering Articles Roadmaps Are Limiting Your Growth Stop Leaving Money on the Table - Negotiate Your Job Offer Never Bad-Mouth Your Past Employers Show You're a Culture Fit Quantify your resume, Know Your Numbers The Importance of Being Likeable in Interviews Questions to Ask Your Interviewer How to Build Trust Through Collaboration Do This, Once You Are Out of the Interview Cycle Stop Pitching Ideas, Start Pitching Projects Read Those Design Docs, Even the Ones That Seem Irrelevant The Best Engineering Lessons Happen During Outages Great Engineers Start Broad LLM Summaries are Ruining Your Learning Turn System Design Interviews into Discussions Title Inflation At Work, Find Your Own Projects 6 Simple Strategies to Cracking Any Tech Interview How to Remain Unblocked Solving the Knapsack Problem with Evolutionary Algorithms Generating Pseudorandom Numbers with LFSR Local vs Global Indexes in Partitioned Databases Partitioning Data - Range, Hash, and When to Use Them
How to Write Effective OKRs
Arpit Bhayani · 2025-02-07 · via Arpit Bhayani

OKRs are one of my favorite tools for staying focused on my goals. I’ve been using them to plan my life since 2020, even creating personal OKRs. This guide captures my thoughts and the techniques I use to craft effective OKRs.

I’ll assume you’re already familiar with the basics of OKRs and their benefits. However, I will summarize key points to keep us aligned.

This guide will be highly practical and actionable, providing concrete examples and best practices for all levels, from engineering managers and directors to VPs of engineering. You can also adapt these pointers for creating your own personal OKRs.

What are OKRs

Objectives and Key Results (OKRs) is a goal-setting framework used by all (individuals, teams, and orgs) to define measurable goals and track their progress. It consists of two key things (ofc) …

  • Objectives: qualitative statements that define what you want to achieve.
  • Key Results: quantitative metrics that measure how you’ll achieve your objective.

Objectives are usually ambitious and inspirational and answers one key question - “Where do I want to go?”. Key Results are specific, measurable, achievable, and time-bound; and they answer “How will I know I’m getting there?”.

I love this framework because it promotes transparency and alignment (with business impact), ensuring everyone understands the overall goals and how their work contributes to them. More importantly, it helps you think harder about things you should prioritize and be data-driven.

Core Principles and the Sweet Spot

  1. Keep objectives ambitious but achievable within the quarter
  2. Ensure key results are quantifiable and measurable
  3. Align metrics with business impact
  4. Focus on outcomes rather than outputs
  5. Limit to 3-4 objectives per quarter, with 2-4 key results each

Crafting Good OKRs

It’s worth investing time, energy, and effort in crafting good OKRs. This is typically what the entire team will focus on for an entire quarter. I’ll take the following OKR as an example and then explain the best practices I’ve followed.

  • O1: Reduce technical debt in the payment processing system

    • KR1: Decrease P1 incidents from 8 to 2 per month
    • KR2: Increase test coverage from 65% to 85% across all microservices
    • KR3: Improve API performance and make it more efficient
    • KR4: Test and deploy the Payments Batch API

Now, let’s examine the OKR above and see how to craft a good one.

Best Practices for Writing Engineering OKRs

  1. Index OKRs using labels like O1, KR1, KR2, KR3, etc. this makes them easy to reference

  2. Make objectives inspiring

This is one of the most important factors to consider when writing OKRs. Every objective should be inspirational - something that will excite people. Here’s an example:

O1: Reduce technical debt of the Payments service

While the objective above is acceptable, it isn’t inspirational. People working on it may not feel like they are doing something substantial. I recommend rephrasing it as:

O1: Maintain a state-of-the-art payment stack and uphold engineering excellence

Using impactful, positive words changes the outlook and inspires people to work on the task.

  1. Ensure key results are specific and measurable

Every key result should be measurable so the team knows what they are working toward. However, make sure you’re choosing the right metric, not just an easy one.

For example, the original KR3 is poorly written because it’s vague and only says “improve” without setting a specific goal. A better version would be:

KR3: Improve the p99 latency of the payment service from 100ms to 65ms
  1. Avoid setting purely activity-based objectives

KR4 is an example of an activity-based key result. It reads like a task

KR4: Test and deploy the Payments Batch API

Even if the task is lengthy, say it takes two months to complete, it’s essential that it’s tracked through a result, not just the activity. This activity can be rephrased as:

KR4: Roll out the payment batch API to 100% of users

This revised key result doesn’t mention testing—that’s implicit. You don’t need to include all the details in the key result itself. These details can be added as a description of the key result or tracked as an issue.

  1. Do not create too many objectives or key results

Focus is crucial. Too many objectives dilute effort and hinder meaningful progress. Limit objectives to 2-3 per cycle, each with 2-4 key results, to concentrate effort and maximize success.

Common Pitfalls While Crafting OKRs

  1. Your OKRs should not be the same as your JIRA dashboard

A common mistake teams make is treating OKRs as a checklist of tasks from their JIRA board. OKRs are not meant to be a to-do list; they are a reflection of impact and outcomes, not just activity. OKRs should focus on the bigger picture - what success looks like and how progress will be measured.

  1. There should be a 1:1 alignment between engineering, product, and business

There should a high overlap across engineering and product OKRs. The delta could be tech debt and engineering excellence items picked by engineering and product research and explorations picked by the product teams. But overall, there should be a 1:1 mapping across engineering and product OKRs when it comes to business outcomes.

When OKRs are too internally focused, they risk losing relevance to broader company goals. Ensuring that most OKRs directly contribute to business success creates a stronger sense of purpose and alignment across teams.

Other Aspects

OKRs are typically set top-down, planned quarterly, and require a regular cadence: setting OKRs at the start of the quarter, mid-quarter check-ins, and end-of-quarter reviews. This keeps OKRs relevant and drives continuous improvement. OKRs cascade from company objectives to teams and individuals, aligning everyone toward common goals and showing how individual work contributes to overall success.

For OKR tracking, a simple spreadsheet is often enough, especially when starting. Focus on defining and tracking meaningful OKRs before getting bogged down with complex software. You really do not need any fancy tool :-)

Ending Note

Remember that OKRs are tools to drive focus and alignment. They should evolve with your organization and be adjusted based on learning and changing circumstances. The key is to maintain ambitious yet achievable goals that inspire teams while driving meaningful business impact.