Every Monday I write about my leadership playbook. This week I will cover the following:

How to create objectives that motivate engineers and deliver business value

Once upon a time, I had to consolidate OKRs from two product managers who worked with my engineering teams. Their objectives were well-intentioned but suffered from a common problem: they read more like feature checklists than strategic goals. Here’s how we transformed them into OKRs that actually drove results, and the framework I now use for all engineering team goal-setting.

The Problem with Most Engineering OKRs

The original PM OKRs looked something like this:

• “Resolve all open user-reported bugs older than 30 days”
• “Complete a greenfield POC for a conference demo”
• “Implement 1 critical community request”

These aren’t inherently bad goals, but they share common OKR antipatterns:

1. Feature Factory Syndrome: They focus on outputs (features delivered) rather than outcomes (business value created)
2. Lack of Ambition: They’re essentially project lists rather than aspirational goals
3. Missing Strategy Connection: They don’t clearly link to broader business objectives

Engineer Disconnection: They don’t inspire or motivate the people doing the work

The Three-Layer OKR Framework

The following three-layer approach that connects business strategy to individual motivation helps when working with engineering teams:

Layer 1: Business Alignment (The “Why”)

Every objective must clearly connect to business outcomes. Instead of “Complete a greenfield POC,” we rewrote:

“Accelerate feature adoption through enhanced experience & user trust”

This objective immediately tells engineers why their work matters beyond just shipping features.

Layer 2: Technical Excellence (The “How”)

Engineering teams need objectives that recognize technical quality as a business enabler. We added:

“Deliver seamless product experience & operational excellence”

This acknowledges that stability, performance, and maintainability are just as important as new features.

Layer 3: Team Development (The “Who”)

Great engineering teams don’t just build products, they build capabilities. Our third objective:

“Build a high-performance product & engineering organization”

This makes team growth and process improvement explicit goals, not afterthoughts.

Crafting Key Results That Drive Behavior

The magic happens in the key results. Here’s how we transformed vague commitments into specific, motivating targets:

Example #1

• Before: “Resolve all open user-reported bugs older than 30 days”
• After: Multiple specific key results under “Deliver seamless product experience & operational excellence”

---

• [PM] Review and resolve 100% of open user-reported bugs older than 30 days
• [EM] Establish engineering on-call rotation with <2hr incident response time and achieve 99.5% uptime SLA
• [EM] Implement automated monitoring and alerting system covering critical user journeys with <5min detection time

Why this works:

• Specific success criteria (100%, <2hr, 99.5%, <5min)
• Role clarity (PM focuses on triage, EM focuses on systems)
• Systemic thinking (not just fixing bugs, but preventing them)

Example #2

• Before: “Complete a greenfield POC for a conference demo”
• After: Business-outcome focused key results

---

• [PM] Deliver a greenfield POC for a conference demo per XYZ partnership requirements
• [EM] Reduce average file download time by 40% through technical performance optimizations
• [PM] Publish public community roadmap and complete 5+ community user interviews

Why this works:

• Connects technical work to business partnerships
• Includes measurable performance improvements
• Adds customer feedback loop for validation

The Engineering-Specific Key Result Strategy

One of my key insights was that engineering teams need key results that acknowledge technical leadership as business contribution. I will continue about this next week.