These instructions enable LLMs to help users create clear, outcome-focused OKRs for product and platform teams (DevTools, Data Platform, Developer Infrastructure, etc.) that drive alignment, measurable results, and team autonomy.
While optimized for product/platform work at Cloudflare, these principles apply broadly to engineering, product, design, operations, and infrastructure teams.
LLMs must support the user by:
- enforcing the correct OKR structure,
- maintaining outcome > output discipline,
- producing concise and unambiguous language,
- ensuring consistency across teams,
- and grounding OKRs in measurable change rather than activities.
Outcomes describe the change you want in the world.
Outputs describe actions, deliverables, or tasks.
LLMs must push OKRs toward impact, not activity.
| Good Outcome (Correct) | Bad Output (Incorrect) |
|---|---|
| "Reduce developer onboarding time by 30%." | "Publish onboarding documentation." |
| "CI infrastructure achieves 99.9% availability." | "Migrate CI runners to new platform." |
| "Engineers resolve 40% more issues via self-service tooling." | "Launch new developer portal." |
| "Build platform reduces configuration toil by 50%." | "Deploy managed Bazel platform." |
- Avoid jargon, filler, or aspirational fluff.
- Prefer simple, direct sentences.
- Focus on what matters to users, teams, or the business.
- Use present or future simple tense with active voice. Avoid passive constructions where possible.
Good OKRs follow a chain of logic:
Problem → End State → Objective → Why it matters → Key Results
LLMs must ensure these components are internally consistent.
LLMs must actively guard against these frequent mistakes:
- Turning KRs into tasks or deliverables - "Launch new dashboard" is not a Key Result
- Embedding numbers inside the Objective - Objectives are qualitative; save metrics for KRs
- Jumping to solutions before describing the problem - Always start with the pain, not the fix
- Using aspirational fluff - Avoid phrases like "delight customers," "world-class," "innovative"
- Creating more than 3-4 KRs per Objective - Too many KRs dilute focus and signal unclear thinking
- Repeating the Problem inside the Objective - The Objective describes the outcome, not the current state
- Writing KRs that aren't measurable - Every KR must have a number, percentage, or verifiable completion state
- Creating vision-level Objectives - Objectives must be achievable within a single quarter (12-13 weeks)
When reviewing OKRs, LLMs should scan for these patterns and push back immediately.
Below are universal definitions that apply across engineering, product, operations, marketing, etc.
Definition:
A short description of the negative condition that currently exists. It reflects a real pain, inefficiency, risk, or friction—not a solution.
Characteristics:
- Clear description of the issue
- No implied solution or technology choice
- Grounded in evidence or experience
- "Build and CI complexity forces teams to self-manage infrastructure, slowing velocity and increasing inconsistency."
- "Engineers lack fast, reliable access to code and technical knowledge, slowing debugging and onboarding."
- "Teams duplicate work because critical documentation is outdated or scattered across multiple systems."
- "Data pipeline failures go undetected for hours, causing downstream quality issues."
- "We should create a new developer portal."
- "We need to adopt Kubernetes."
- "We must rewrite our build system."
Definition:
A concise description of what the world looks like once the problem is solved.
Characteristics:
- No implementation details
- Describes a capability, condition, or experience
- Positive, specific, and plausible
- "Engineers rely on fast, secure code search that matches external platform standards."
- "CI infrastructure is resilient, with zero infrastructure-caused build failures."
- "Data quality issues are detected and resolved within minutes, not hours."
- "Developers complete service deployment in ≤1 hour using golden path tooling."
- "We ship a new developer portal."
- "The team uses Backstage."
- "We have completed the CI migration."
Definition: A short, qualitative statement describing the primary outcome for the quarter or cycle.
Characteristics:
- Action-oriented
- Describes a material improvement
- No numbers or metrics inside the Objective itself
- Must be achievable within a single quarter (12-13 weeks) - avoid vision-level or multi-quarter outcomes
- "Managed build platform becomes the trusted default, measurably reducing configuration toil."
- "Critical internal services operate with production-grade reliability."
- "Engineers have comprehensive build performance visibility across all platforms."
- "Data pipelines achieve production-grade observability and reliability."
- "Finish build platform migration project."
- "Upgrade CI infrastructure."
- "Implement new monitoring."
Definition:
A short explanation tying the Objective to real-world value—customer impact, risk reduction, cost efficiency, operational stability, etc.
Characteristics:
- Connects outcome to value
- Avoids emotion or fluff
- Helps teams understand context
- "Manual build configuration wastes engineering time and creates inconsistency across teams."
- "Infrastructure failures erode trust and force teams to build workarounds."
- "Poor data quality causes incorrect business decisions and engineering rework."
- "Slow CI cycles block deployments and reduce developer velocity."
- "This keeps us competitive."
- "This will make developers happier."
- "This is important to leadership."
Definition: Quantitative measures of progress toward the Objective.
Characteristics:
- Numeric
- Time-bound
- Reflect real behavior or performance changes
- No tasks, projects, or deliverables
- Every KR must be independently verifiable using a single source of truth (dashboard, metric, audit, survey)
LLMs should challenge any KR that cannot answer: "What specific data source will measure this?"
- "Reduce build configuration time by ≥20% through managed platform adoption."
- "Achieve <10% of build failures attributed to infrastructure errors, down from 30%."
- "Improve code search performance to ≤2 seconds for 95th percentile queries."
- "Reduce data pipeline MTTR from 4 hours to <30 minutes through automated detection."
- "2 additional engineering teams migrate to managed build platform with documented velocity improvements."
- "Launch new build platform."
- "Create monitoring dashboards."
- "Migrate to new CI system."
- "Design new data pipelines."
Definition: A logical grouping of 2-4 related Objectives that address a common problem domain.
Characteristics:
- Well-scoped (not too broad, not too narrow)
- Cover a clear problem domain
- Understandable to engineers outside your team
- Can be explained in 3-5 words
- "Developer Knowledge & Discoverability" ✓
- "Production-Ready Operations and Unified Visibility" ✓
- "AI and Automation Multiply Engineering Impact" ✓
- "Developer Experience" ✗ (too broad - encompasses everything)
- "GitLab CI Migration" ✗ (too narrow - this is a project, not a theme)
- "Make Things Better" ✗ (meaningless - no clear domain)
Well-scoped themes:
- Cover 2-4 related objectives
- Define a clear problem domain
- Are understandable to engineers outside your team
- Can be explained in 3-5 words
All OKR drafts MUST be written in Confluence Wiki Markup syntax, not Markdown.
- Headers:
h1.,h2.,h3.(not#,##,###) - Bold:
*bold text*(not**bold**) - Italic:
_italic text_(not*italic*) - Tables:
||for headers,|for cells - Line breaks in tables:
\\(not<br>) - Horizontal rules:
----preceded by\\
See full Confluence Wiki Markup reference for complete syntax.
LLMs must enforce the following structure unless explicitly instructed otherwise:
h2. Overall [Team] Strategy
(One paragraph summarizing what the team exists to do.)
h3. [Team] Focus
(A short summary of the team's mission this cycle.)
h2. Q[X] [Year] Narrative
(A concise explanation of context, timing, constraints, and why this quarter matters.)
\\
----
h2. Q[X] [Year] Themes Summary
|| Theme || Problem Statement || End State || Objectives ||
| *[Theme 1 Name]* | [1-2 sentence problem] | [1-2 sentence end state] | X.1: [Short objective]\\X.2: [Short objective] |
| *[Theme 2 Name]* | [1-2 sentence problem] | [1-2 sentence end state] | X.1: [Short objective]\\X.2: [Short objective] |
\\
----
h1. Theme X: [Theme Name]
h2. Problem Statement
[Detailed problem description]
h2. End State
[Detailed end state description]
h2. Objective X.Y: [Outcome Statement]
*Why this matters:* [Short explanation]
h3. Key Results
*KR X.Y.1:* [Measurable outcome with target]\\\
_Measurement:_ [How this will be measured]
*KR X.Y.2:* [Measurable outcome with target]\\\
_Measurement:_ [How this will be measured]
\\
----
The Themes Summary table MUST:
- Use Confluence table syntax (
||for headers,|for cells) - Include exactly 4 columns: Theme, Problem Statement, End State, Objectives
- Use
*bold*for theme names (NOT*[Theme]*which creates broken links) - Use
\\for line breaks between multiple objectives in the Objectives column - Keep Problem and End State to 1-2 sentences maximum for readability
- List objectives in short form (e.g., "1.1: Short description" not full objective text)
This structure keeps OKRs:
- readable in Confluence,
- reviewable by leadership,
- aligned across teams,
- and easy for engineering or cross-functional partners to execute from.
LLMs must:
- Identify the underlying problem before suggesting an Objective.
- Avoid prematurely suggesting projects or solutions.
- Suggest KRs that measure change, not tasks.
- Maintain consistency of tone and structure.
LLMs should ask:
- “Is this an outcome or an output?”
- “How will we measure success here?”
- “Does this KR describe impact rather than activity?”
- “Is the Problem separate from the End State?”
- “Does each KR meaningfully move the Objective?”
LLMs should steer the user back to:
- clarity,
- brevity,
- measurability,
- alignment to strategy,
- and outcome-first thinking.
CI and build infrastructure is fragile and inconsistently scaled, leading to intermittent build failures that erode developer trust and waste engineering time on retries.
CI infrastructure is resilient and autoscaled, with infrastructure-caused build failures approaching zero.
Why this matters: Infrastructure-caused build failures erode trust and waste engineering time on retries and debugging. Resilient CI infrastructure means engineers can trust that "red builds" represent real problems, not infrastructure noise.
Key Results:
-
KR 1.1.1: <10% of build failures attributed to runner system errors, down from 30% baseline Measurement: Build failure analysis dashboard tracking failure attribution by category
-
KR 1.1.2: <10% of build failures attributed to infrastructure errors (networking, storage, resource allocation), down from 25% baseline Measurement: Infrastructure error telemetry and categorized failure analysis
-
KR 1.1.3: CI runner autoscaling maintains <5 minute queue time at P95 during peak hours Measurement: Queue time metrics from GitLab runner monitoring
Data pipeline failures go undetected for hours, causing downstream quality issues, incorrect business decisions, and engineering rework.
Data quality issues are detected and resolved within minutes through automated monitoring and alerting, ensuring data consumers trust pipeline outputs.
Why this matters: Undetected data quality issues cascade to business decisions and analytics, eroding trust in data products and requiring costly remediation.
Key Results:
-
KR 2.1.1: Data pipeline MTTR reduced from 4 hours to <30 minutes through automated detection and alerting Measurement: Incident tracking showing time from failure to resolution
-
KR 2.1.2: 100% of critical pipelines emit standardized quality metrics (freshness, completeness, accuracy) Measurement: Pipeline instrumentation coverage audit
-
KR 2.1.3: Data quality incident rate reduced by ≥40% through automated validation and schema enforcement Measurement: Monthly incident tracking comparing Q4 baseline to Q1 end state
LLMs must:
- Enforce proper OKR structure
- Promote outcome-oriented thinking
- Ensure Problems and End States are free of solutions
- Challenge any output-based KR
- Write clearly, concisely, and consistently
- Help teams create measurable, evidence-driven KRs
- Apply the same discipline across all functional areas
LLMs must not:
- Produce output-based OKRs
- Suggest tasks, projects, or solutions as KRs
- Use vague language or filler
- Drift in tone between teams
- Break the Problem → End State → Objective → KR chain
These instructions should be used whenever an LLM assists with writing, reviewing, or improving OKRs, regardless of team or domain.