🖤 Open Works #037 Rolling Out KPIs In Product & Tech Without Causing A Mutiny

Welcome to Open Works. Every edition we solve a ‘people and culture’ problem crowd-sourced from the Open Org Community of 480+ Startup and Scale-up People Leaders.

This edition is sponsored by peoplemetrics.fyi–the benchmarking platform for scale-up people leaders.

Get instant access to verified data from 600+ startups and scale-ups across 18 x people and talent metrics. Gain the insights to make smarter decisions and give stakeholders the context they crave.

📚️ Recent Editions

If you’re new round here, not yet a subscriber or you straight up missed it, here are some of our recent editions.

💰️ Edition 36: How To Think About Executive Compensation - a mental model and stage by stage guide to approach it.

🔋 Edition 35: How to Manage Change Fatigue - diagnostic, approach and framework for dealing with a real threat.

💻️ Edition 34: Tech Hiring SOS! How To Increase Candidate Quality – practical sourcing tactics and hidden gems.

💭 This Week’s People Problem

🖤 Our Take On How You Solve

🏃 TL;DR:

• Start with the why and if you’ve not got a good one, don’t start at all.

• Frame KPIs as health signals, not scorecards.

• Use a metaphor to frame it. People remember stories more than slides.

• Introduce metrics they already trust (hi, DORA 👋).

• Co-create not mandate.

• Avoid the big three: top-down orders, vanity metrics, and KPI overload.

⚡️ The Problem

^ That’s how a KPI rollout can land if it’s not done carefully in Product and Tech.

The issue isn’t resistance to measurement, it’s that most KPI systems are rolled out without real input from the teams they affect and become a reporting time sink.

They often feel disconnected from how work actually gets done, misaligned with how decisions are made, and overly focused on top-down visibility. And where does that leave us? A bad place. Low trust, poor adoption, and metrics that don’t drive meaningful action.

Bleurgh.

Here’s how to avoid that 👇️ 

💡 Step 1: Nail Your WHY

Before you talk about what you’re rolling out, get clear on why. And if you haven’t got one. Go next.

Bad WHY: “To help us measure success.”

(bad because this is a vague generic textbook reason for wanting to do KPIs)

Good WHY: “To help us see where delivery risk is building up.”

(good because it’s a very specific org pain)

Great WHY: “Remember that major launch last year that shipped with 13 bugs and took us 3 months to recover from whilst we built a mountain of tech debt we are still trying to tackle? This is how we avoid that happening again.”

(great because it’s a very specific pain org pain that can translate to Product and Eng feeling it themselves.)

💡Tip: Make the pain you’re solving real. The moment teams feel it, you’ve got buy-in.

📡 Step 2: Use a Metaphor People Can Actually Understand

Tackle this one with a simple metaphor. My favourite:

🚦 Sat Nav vs. Dashboard.

• OKRs = Sat Nav. They show where you’re going, and adapt along the way.

• KPIs = Dashboard Gauges. They tell you how the engine’s running. Fuel, speed, engine temp. You’re not driving toward them—but if one’s blinking red, you should probably pull over.

It shifts the conversation from “What are we being measured on?” to “What should we be paying attention to so we don’t crash?”

Shout out to my friends at Stellafai for teaching me this one 🙏 

🔧 Step 3: Start with KPIs They Already Trust

For Engineering, don’t invent new metrics. Use ones they already respect.

Enter: DORA Metrics (📦 DevOps Research and Assessment)

1. Deployment Frequency – how often do we ship?

2. Lead Time for Changes – how long from code to production?

3. Mean Time to Recovery – how quickly can we fix failures?

4. Change Failure Rate – how often do we break things?

These are trusted in the DevOps community because they correlate with real business performance, and they reinforce a culture of fast, safe delivery not micromanagement.

🛠 Step 4: Run Workshops, But Let Them Drive

Don’t show up with a finished dashboard and a lecture.

Instead, turn workshops into co-creation sessions. Ask questions like:

• “What would help you know earlier if something’s going off-track?”

• “Where are we currently flying blind?”

• “How could we use data to protect our focus and flow?”

Let teams sketch their own starter KPIs. Help Heads of to facilitate not dictate.

🚫 Pitfalls to Avoid

Rolling out KPIs with no shared WHY. 

Resistance is guaranteed.

Tracking too many things. 

Stick to 3–5 metrics max. You’re not building Google Analytics for delivery teams.

Doing nothing when a KPI tanks. 

If there’s no follow-up, you lose trust fast.

Using story points or velocity as KPIs. 

These are game-able, subjective, and almost universally loathed as a KPI by teams.

📚️ Good reads and resources...

📔 Accelerate by Nicole Forsgren – where DORA metrics were born.

📈 DORA Metrics 101 – if you’re new to them, start here.

📔 Measuring Product Velocity - Laura Tacho (via Lenny’s newsletter)

🤓 Want to Get Your Current “People Problem” Featured?

We’re here for the trickiest challenges you’ve got. Hit reply to this email, and let us know what’s keeping you up at night, and we’ll feature next time anonymously!

🖤 Psst! Did You Know We Are Launching An Exclusive Annual Content Membership For People People?!

Well my friend, now you do.

👉️ Adam wrote words about this here. 

TL;DR- it’s all our past/current/future playbooks we’ve written for People People bundled up into an affordable yearly subscription (£120) as well as thousands of pounds of HR tech discounts and some other free stuff.

Early bird discount of 25% off for year 1. If that sounds fun, get your name on the list here 👇️ 

With 🧊 & 🔥 

John & Adam

👉️ Know someone who’d love this newsletter? Forward it their way so they don’t miss out, and make my day whilst you’re at it! 🙂