How to Write Better OKRs for Platform and Infrastructure Work

The practice of creating Objectives and Key Results links what you do to why you do it, a simple idea that Google popularized. When implemented correctly, it works brilliantly. The implementation, though, is another story.

I’ve worked at companies that introduced OKRs, removed them, switched to initiatives, then back to goals. At enterprise-sized companies, different formats will come and go. Your goal should be to make the best use of whatever structure you have.

Platform and infrastructure OKRs are different from feature team OKRs. The work sits deeper in the tech stack, requires coordination across multiple teams, is systemic by nature, and often isn’t easily understood outside of engineering. But they still need to be crystal clear, because vague goals lead to wasted quarters and frustrated teams and leads.

If your company uses OKRs, this is how to write better ones for foundational work.

When Writing Objectives: Be Boring and Clear

Choose clarity over excitement

Your Objective’s main purpose is to explain what will be done, not hype it up. Avoid empty words like “awesome,” “delightful,” or “empower” that sound good in a slide deck but mean nothing when you’re trying to figure out what to build.

Avoid: “Empower developers with a delightful authentication experience”

Use: “Implement company-wide SSO authentication for all internal tools to reduce security incidents and onboarding friction”

The second one might spark less emotional response but is way more useful, because six months from now when someone asks what you were supposed to deliver, you’ll know exactly what it was. Infrastructure is whole grain, not fast carbs. You need stability and predictable delivery of fundamental value over time, not momentary excitement.

Maintain consistency over time

Infrastructure work often spans multiple quarters or even years. Your company wants quarterly updates, but your work doesn’t fit neatly into three-month cycles. Account for this by labeling your Objectives with the phase or focus area in parentheses.

Example of multi-quarter labeling:

• Q1 2026: “Migrate legacy monolith to microservices architecture for product teams to enable independent deployments (Discovery and service mapping)”
• Q2 2026: “Migrate legacy monolith to microservices architecture for product teams to enable independent deployments (Core services extraction)”
• Q3 2026: “Migrate legacy monolith to microservices architecture for product teams to enable independent deployments (Traffic migration and monitoring)”

People change roles, teams reorganize, context gets lost. Explicit labeling keeps everyone aligned on where you are in a multi-year effort.

Template for writing clear Objectives:

[What] + [for whom] + [outcome]

Examples:

• “Build CI/CD pipeline for mobile apps to reduce deployment time from days to hours”
• “Consolidate logging infrastructure across backend services to enable centralized monitoring”
• “Establish data governance framework for customer PII to meet GDPR compliance requirements”

When Writing Key Results: Make Them Measurable and Specific

Structure your KRs with 3 to 5 results per Objective. At least one should measure impact (or at least progress). The rest can be deliverables, but every single one needs a clear Definition of Done.

Measuring impact in infrastructure is not as standardized as in other parts of the tech stack. Your measurement maturity might be low, or you’re at a phase where the impact is too far downstream. If you can’t measure impact yet, measure progress in any way you can and build the capacity to improve over time.

Example of a KR with Definition of Done:

KR: “Launch developer portal with SSO authentication and onboarding documentation for all engineering teams to reduce new service setup time”

Definition of Done:

• Portal accessible at internal.company.com/dev-portal
• SSO authentication working for all employees
• Onboarding guide published with at least 5 common workflows documented
• At least 10 developers from 3 different teams have successfully onboarded a new service using the portal

Template for impact KRs:

[How] + [Metric] + [outcome]

Examples:

• “Reduce P1 incidents related to auth from 12/quarter to 2/quarter to improve system reliability”
• “Increase platform adoption to 60% of engineering teams (30 out of 50 teams) by end of Q2 to establish standardized deployment practices”

Template for delivery KRs:

[Ship/Launch/Complete] + [specific deliverable] + [outcome]

Examples:

• “Ship observability dashboard with CPU, memory, and request latency metrics for all microservices to enable proactive incident detection”
• “Complete data migration to new warehouse with zero data loss and less than 2 hours downtime to meet Q2 analytics requirements”

Account for discovery work in your KRs

Platform work requires significant upfront research and decision-making. You need to figure out what to build, evaluate vendor options, prototype solutions, and get buy-in from multiple teams. This work might require the support of multiple teams.

If you need to complete meaningful discovery this quarter, use KRs to validate it. Don’t let it disappear into a black hole where three months pass and all you have is “we talked to people.” (Unless you already have a great way to track discovery work)

Examples of discovery KRs with clear outputs:

• “Complete working prototype of new deployment system that validates these 5 use cases: [list them], tested with at least 3 product teams to confirm technical feasibility”
• “Finalize technical design document for data pipeline approved by Data Platform, Security, and Infrastructure leads to establish implementation approach”
• “Complete vendor evaluation with final recommendation and cost analysis for top 3 options, decision made by end of month 2 to enable Q2 implementation”

Label Stretch Goals Explicitly

Stretch goals encourage ambitious thinking by setting targets that push beyond what’s certain. The concept comes from John Doerr’s “Measure What Matters,” where achieving 60-70% of an ambitious goal is considered success because it drives teams to reach further than they would with conservative targets.

However, platform work is often a prerequisite for other teams’ work. If you’re 85% done with authentication, the teams depending on it might be 0% able to ship their features.

When to use stretch goals:

• For KRs measuring progress over time where you could achieve more if you pushed for it
• Exploratory work where you’re not sure what’s possible

When NOT to use stretch goals:

• Prerequisites that block other roadmaps
• Baseline functionality that needs to work, period

Mark stretch goals clearly so teams know what’s committed versus aspirational.

Example of labeled stretch vs committed goal:

Objective: “Build centralized secrets management system”

KR1 (Committed): “Launch secrets vault with support for API keys and database credentials, integrated with CI/CD pipeline”

KR2 (Committed): “Migrate 100% of hardcoded secrets from top 10 critical services to secrets vault”

KR3 (Stretch): “Achieve automated rotation for 50% of secrets with zero manual intervention”

Common Writing Mistakes to Avoid

Mistake 1: Using unmeasurable language in KRs

Words like “improve,” “enhance,” “optimize,” or “strengthen” without numbers or success criteria are useless.

Avoid: “Improve API performance” Use: “Reduce API p95 response time from 200ms to 100ms, measured across 1M requests”

Mistake 2: Writing KRs that are activities instead of outcomes

Avoid: “Hold weekly meetings with product teams to gather requirements” Use: “Requirements doc finalized and approved by 5 product teams, covering at least 15 distinct use cases”

Mistake 3: Forgetting to account for dependencies

When your infrastructure work is a dependency for other teams, they need 100% of your baseline, not 85%.

Avoid: “Migrate 85% of services to new deployment pipeline”

Use: “Deploy new deployment pipeline to production, fully replacing legacy system, with all 40 active services migrated and legacy pipeline decommissioned”

The second version leaves teams in limbo and the first version closes the loop.

Mistake 4: Not including Definition of Done

If you can debate whether you hit a KR at the end of the quarter, it was poorly written. Add Definition of Done criteria that make success unambiguous.

Bonus tip

In pressed planning periods, OKRs can shift a lot before being finalized. You risk having something submitted created late at night without buy in. To avoid this

• keep all team OKRs in one shared document so you anyone can spot overlaps and gaps,
• Make sure the people you need support from can contribute in the OKR writing, provide a template and clear example. This way you scale the work

What’s worked, or not worked, for you with OKRs and infrastructure work?