How I Stopped Dreading OKR Season (with a Kiro Agent)

It's that time again.
The quarter is ending. You're already uncomfortable about approaching deadlines and work leaking into next quarter, and now Slack lights up: "Q3 OKR drafts due by Friday." Other EMs are already sharing theirs.

Your calendar is full. And somewhere between meetings you're supposed to produce a compelling strategic narrative for why your platform team's work matters - with measurable outcomes, clear dependencies, and a believable execution plan.

Not too ambitious (shooting yourself in the foot), not sandbagged (underpromise to overachieve).

Every. Single. Quarter.

For most of us - engineering managers, team leads, staff+ engineers who somehow ended up owning the roadmap - OKR season is a recurring source of dread. Not because we don't know what matters. We do. But translating technical work into business-aligned goals is a completely different skill. And doing it while context-switching between PR reviews, architectural decisions, and people management can be exhausting.

Building the roadmap

My team and I run proper roadmapping sessions - with post-its and stuff (virtual or real) - brainstorming topics that matter: security gaps, governance blind spots, maintenance burden, ownership pain points. We discuss deeply technical issues with genuine passion and clarity. By the end we have a wall of well-understood problems - some important, some urgent, some nice-to-have.

We then prioritise through multiple lenses: Eisenhower Matrix (Urgent x Important), Impact-Effort Map, and Bezos's Decision-Making Matrix (Consequential x Reversible) to determine what we really must work on, what's a filler, and what's a quick win.

Then comes the hard part.

I need to translate those post-its into a language that business stakeholders understand. "Update EKS node groups running unpatched AMIs with no automated rotation" gets enthusiastic nods from the team. But what does a director hear? Nothing useful. What they need to hear is "we're one CVE announcement away from an emergency maintenance window that takes the product offline for hours."

And every goal must have success metrics. Not just "we made it or not" - actual data, KPIs, key results. Metrics that make sense. That can't be unconsciously optimised in ways that defeat the purpose. That don't ruin the goal by optimising for the wrong thing.
I don't want a metric that steals all the attention and time away from the real problem.

I don't want to spend more time gathering data for the metrics than doing the actual work. And of course, the good old "Once a measure becomes a target, it ceases to be a good measure."

Goodhart's Law hits platform teams especially hard because our work is foundational, indirect, and hard to quantify without creating perverse incentives.

"Reduce MTTR to under 10 minutes" sounds great - until teams start auto-closing incidents early.

"100% tag coverage" sounds perfect - until everything is tagged misc.

"Zero critical vulnerabilities" sounds too good to be true, and in fact your team likely stopped scanning things they're unsure about.

So what's the measurable outcome (not the output)? What's the baseline? What metric genuinely captures progress without distorting behaviour? And can I explain all of this in a narrative that a director reads in 30 seconds and thinks "yes, this matters"?
And would I be able to answer their trickier follow-up: "So what?" What is really the value of it? Who is better off? What can product teams do now that they couldn't before?

If you can't survive two rounds of So what? you don't have a goal. You just have a set of tasks.

Iteration 1: Prompts and Conversations

My first attempt was just chatting. Copy-paste the company strategy into ChatGPT or Gemini, later into Kiro, describe what my team does, ask it to draft OKRs.

The results were predictably mediocre. Generic objectives. KRs that measured outputs ("implement X"). No baselines. No connection to our specific context.

But what did work was using AI as a thinking partner for the intermediate steps:

• "Here's what my team did last quarter. What patterns do you see?"
• "I want to reduce deployment failures. Help me think about what metric actually captures this."
• "Challenge this KR - how could someone game it?"

The back-and-forth was valuable but slow, repetitive, and I lost context between sessions. Every quarter I'd start from scratch, re-explaining who we are and what we do.

Iteration 2: The Executive Tech Translator

Next I built a dedicated agent. I called it the "Executive Tech Translator" - its job was bridging technical platform work and business language.

It knew cloud infrastructure, DevOps, SRE, FinOps. It could translate "Kubernetes autoscaling with HPA and VPA" into "smart automation that adjusts computing resources based on demand, reducing costs by 30%." It used the Minto Pyramid Principle. It produced roadmaps, initiative pitches, and executive reports.

A solid step forward. I could throw technical context at it and get back something a non technical stakeholder would understand. Also great for ad-hoc Slack messages announcing initiatives or short pitches for All-Hands.

But it had a fundamental limitation: it didn't know our OKR format. It produced generic OKRs - objectives with key results, sure, but not in the specific NCT (Narrative, Commitments, Tactics) structure our company uses. Every time, I'd manually restructure the output to match what our Notion template expected.

And it had no opinion about quality. It wouldn't tell me "this KR is an output, not an outcome" or "you're missing a baseline." It was a translator, not a strategist.

Iteration 3: The Company OKR Coaching Skill

Meanwhile, internally, someone built an OKR Mastery skill for our Copilot setup. Impressive - deeply embedded in company context, connected to Notion with its MCP, aware of the org chart, team missions, tribe objectives, and the full NCT format.

It would interview you: "Which team are these OKRs for?" It pulled past OKRs from Notion. It had a 10-criterion review rubric. It knew the difference between Outcome and Discovery goal types. It would red-team your KRs for unintended incentives.

The methodology was excellent. But for my use case, it was too much coaching and not enough doing.

What I really wanted was the methodology of the coaching skill combined with the document-generation speed of the translator. Plus things neither had: a private "what could go wrong" analysis, implementation tasks ready for Linear, and a self-validation step that catches mistakes before I submit.

Iteration 4: The Roadmap Strategist Agent

So I built it. A Kiro agent called roadmap-strategist that combines everything I learned from the previous iterations:

From the prompts era: the outcome-forcing technique. Every KR gets pushed through a ladder that forces you from "what we'll build" down to "what actually changes, and how we'd know."

Most post-its from roadmapping sessions live at the top of this flow - they describe work, not outcomes. The ladder won't let you stop there.

Each step strips away implementation detail and asks "so what?" The top is where engineers naturally start. The bottom is where a director can read it in 30 seconds and understand why it matters.

Most badly-written KRs are just tasks rephrased to sound strategic: "Implement X" becomes "X is implemented." The ladder catches that before you commit to a metric that measures activity rather than progress.

From the Executive Tech Translator: the business-value framing, the platform-to-business translation, the Minto Pyramid Principle structure.

From the OKR Coaching Skill: the exact NCT format our company uses (Narrative, Commitments, Tactics - with per-KR Goal Type/Owner/Dependencies), the quality checklist, the review rubric, the quantity-quality pairing rule, and committed vs. aspirational classification.

New additions that address the metric-quality problem:

• A Red Team Report (EM eyes only) - for every KR, it identifies how a metric could unintentionally distort behaviour, and gives me probing questions for check-ins. My Goodhart's Law defence: before I commit to a metric, the agent stress-tests whether it actually captures what we care about.
• Quantity-quality pairing as a hard rule. Example: "100% AWS resource tag coverage" sounds great as a KR, but your team can hit it by tagging everything team:misc or env:unknown. The number is green; the data is useless. So you pair it with a quality counterpart: "95% of AWS spend attributable to a specific team/product without manual corrections." If tags are junk, cost reports are broken - spend can't be attributed, finance challenges the numbers, teams argue over shared bills. The quality metric fails even though the quantity metric is green. You can't satisfy both by slapping misc on everything.
• Committed vs Aspirational classification - infrastructure dependencies and compliance deadlines are committed (must hit 1.0); developer experience and adoption targets are aspirational (70% is success). This stops the sandbagging-or-burnout cycle.
• A Tech Debt OKR Gate - the agent challenges any tech debt objective that doesn't meet one of four criteria: security risk, primary driver of unplanned work, blocks a strategic goal, or requires cross-team coordination. Most debt should be embedded in normal delivery, not given OKR status.
• Implementation Tasks separated from the OKR narrative - ready for Linear ticket creation.
• Self-validation - it scores itself against a 10-criterion rubric and fixes anything below threshold before presenting.

What it produces

I give it the output of our roadmapping sessions - post-its, technical problems, constraints, company-level goals to connect to - and it produces:

1. A strategic roadmap (executive summary, context, timeline)
2. NCT-format OKRs with outcome-forced, quality-paired metrics (paste-able into Notion)
3. Rough Implementation tasks (for Linear)
4. A red-team report (private, for my check-ins)
5. A self-score showing where it's strong and where it's stretching

The Red Team Report - the unexpected favourite

This was the piece I didn't know I needed until I built it. For every KR, the agent asks:

• "How could this metric be unintentionally optimised in a way that defeats the purpose?"
• "If pursued aggressively, what could go wrong?"
• "What should I watch for during the quarter?"
• "What questions should I ask in check-ins?"

And then it gives me an overall "so what" check: if everything is achieved, does it actually matter? What's still missing?

This is the question platform teams dodge the most. We're builders - we love solving hard technical problems. That love can quietly become a trap: staying busy with interesting infrastructure work that enables exactly nobody. Migrating to the latest service, refactoring modules for elegance, building internal tooling only we touch. End of quarter: a list of completed tasks that wouldn't survive a simple "so what?" from a stakeholder.

The red-team report acts as that annoying colleague poking holes in your goals before you commit a quarter's capacity to them. If your best answer to "so what?" is "it's cleaner now" or "it follows best practices" - it's not an OKR.

This section stays private - it's not for the team. It's my management tool. It makes me better at asking the right questions during the quarter, instead of just tracking green/yellow/red on a dashboard.

And it's teaching me to write better OKRs. Every quarter, the "Lessons for Next Quarter" section captures what I'd do differently. A feedback loop built into the process.

What I Learned Along the Way

This journey confirmed something I keep re-learning: work in small iterations. Short feedback loops. Don't try to build the perfect agent on day one. Start simple, try it out, fine-tune, vibe-code the session, then ask Kiro to update the skill or steering file for next time. Consolidate learnings into steering files (your writing style, your format preferences, your team context) so the next session doesn't start from zero.

Format without methodology is dangerous. Perfectly-formatted NCT OKRs that are actually a disguised task list are worse than having no format at all.

Goodhart's Law is the biggest trap in OKRs. I used to quote this cynically as an IC when past managers presented poorly-written top-down OKRs. "When a measure becomes a target, it ceases to be a good measure." Now that I'm on that side, I have a way to make sure I don't fall into the same trap. The quantity-quality pairing and the red-team report are both defences. Every metric needs a counterpart that catches unintended optimisation, and every KR needs someone asking "how could this number look good while reality is worse?"

Tech debt mostly doesn't belong in OKRs. This isn't really a learning - it's been my mantra my entire career. Be good scouts, fight entropy, be aware of shortcuts, plan immediately how debt gets paid. But I appreciate seeing it codified as part of OKR definition for the first time: debt only deserves OKR status when it's a security risk, the primary driver of unplanned work, blocks a strategic goal, or requires cross-team coordination. Everything else is just doing your job well.

Separate what's for alignment from what's for execution. The OKR body is for communication (shared with stakeholders).
The implementation tasks are for the team (becomes tickets).
The red-team report is for me (becomes check-in questions).

Why This Matters

If you're responsible for a platform team's quarterly strategy - connecting infrastructure work to business value, coordinating with product teams who speak a different language, and executing while also managing people - then having an agent that produces the full package in 10 minutes instead of 3 mornings is a good use of AI.

But the strategic thinking is still yours. The agent doesn't decide what matters or why. It doesn't prioritise security over developer experience, or know that last quarter's incident changed your risk tolerance.
You do that. What you no longer do is spend three mornings finding the right words, formatting templates and hunting for meaningful metrics.

OKR season still comes every quarter. But now I spend that time on what actually matters: thinking about what my team should focus on and why.

---

The roadmap-strategist agent is part of my Kiro global configuration. If you're interested in building something similar for your team's OKR format, the key insight is: embed the exact format, the methodology, AND the self-validation into one agent. Don't separate them.

Once I have a version stripped of company-specific details, I'll publish it on the Lead, Multiplied project repo - an open collection of AI-native leadership tools I'm currently preparing.

---

Other articles you might be interested in:

• No Time to Code: AI as Leverage for Engineering Leadership
• Vibecoding in Between Meetings: Learning MCP Servers and Building a PoC