I email every Thurday with the latest insights from my work and clients about product, business and tech. Sign up below! I will never spam or sell your info. Ever. Unsubscribe anytime.
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 ClearChoose clarity over excitementYour 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 timeInfrastructure 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:
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:
When Writing Key Results: Make Them Measurable and SpecificStructure 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:
Template for impact KRs: [How] + [Metric] + [outcome] Examples:
Template for delivery KRs: [Ship/Launch/Complete] + [specific deliverable] + [outcome] Examples:
Account for discovery work in your KRsPlatform 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:
Label Stretch Goals ExplicitlyStretch 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:
When NOT to use stretch goals:
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 AvoidMistake 1: Using unmeasurable language in KRs Words like “improve,” “enhance,” “optimize,” or “strengthen” without numbers or success criteria are useless. Avoid: “Improve API performance” Mistake 2: Writing KRs that are activities instead of outcomes Avoid: “Hold weekly meetings with product teams to gather requirements” 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 tipIn 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
What’s worked, or not worked, for you with OKRs and infrastructure work? |
Ylva Fredriksson
I email every Thurday with the latest insights from my work and clients about product, business and tech. Sign up below! I will never spam or sell your info. Ever. Unsubscribe anytime.
You’ve outgrown your current team setup but find it hard to figure out a better one that fits your reality. When setting a new org structure it’s easy to pinpoint a few areas that are cleanly scoped and valuable, but then there is the rest. You still need to maintain the technology you built, there are domains that might be less clear on what value they bring and who their customers are, but you know they’re needed. And you need to figure out where to put your leaders (you probably lack some...
Hand on your heart, are you doing as much product discovery as you should? If there's a gap, you're not alone. I've worked with teams skipping product discovery because they "don't need it" or "don't have time for it" since their backlog is already full of things the business asked for, the users, or tech debt. I've worked with PMs who want to do discovery "right" and therefor never get started, and I've seen seasoned PMs using the same tools and methods who could use a little inspo to...
You know you need to improve product discovery in your teams. You know what good looks like, some of your leaders as well, but somehow teams are not spending enough time doing proper product discovery. Instead they work off requests from customers, from stakeholders, from the one year kind of promised roadmap. And all that work is important and keeps them busy, so you struggle to push for different ways of working on top of everything else and keep deferring it to 'soon, after xyzzy is...