Field Notes From the Efficiency Era, Part 3: Metrics That Actually Matter
And far too much to say about the ones that don't.
Part three of a four-part series on what the Efficiency Era demands—and what it exposes.
🧭 New here? Start with the overview: No More Vibes in the Efficiency Era
When the CEO Starts Asking Questions
Your Cue to Lead
That calendar invite drops: “Metrics Review”. You peep the guest list. A veritable who’s-who of the prestigious top slice of the org chart. Your stomach climbs into your chest. You recognize… maybe someone from the board? And that cheeky advisor who keeps whispering “data-driven” in your CEO’s ear. The message hits slow, like a bruise coming up after the punch.
They want their receipts.
This is a crucial moment. It can go well, but only if you’re ready. Too many leaders panic. They freeze. Deflect. Get defensive. When your CEO is digging in because they “just want to understand what’s going on in engineering”, that’s your cue to lean in and get curious.
Here’s the truth (if you take nothing else away from this): something they care about isn’t moving up and to the right anymore. Or enough. Or as quickly as the board, the investors, or their CEO-whisper-network says it should be.
So, they’re sniffing around. And guess what? Engineering is fucking expensive. When things stall, we’re the first place the business pokes at for leverage.
And that’s actually fair.
You don’t spin up a company-wide metrics initiative because everyone has spontaneously developed a continuous improvement mindset. You do it because someone looked at a P&L statement, saw R&D as one of the biggest line items, and realized they couldn’t tell whether it was paying off.
They want to know where the hell their money’s going. And they’re entitled to ask.
This is your shot. Are you prepared? To shine a light on the efficiency-killing wait states? The excruciatingly long feedback loops? The hidden toil? The constant roadmap thrashing and context-switching patterns? Do you know what’s actually slowing down delivery and how to fix it?
This is the moment to lead. Not defend. Not distract. Here’s where the system is stuck. Here’s how we unstick it. And here’s what we’ll get when we do.
The New Playbook
There’s no more safety net of endless hiring. The Efficiency Era doesn’t hand out king-size goodwill candy bars just for building team culture and running solid 1:1s. Expectations have changed. So must your playbook.
Our job—your job—is to have a good story to tell. One that translates R&D spend into business leverage. One that proves our investments compound rather than evaporate. One that shows where we stack up against the industry. Not for bragging rights, or to feel the weight of some imaginary Velocity Olympics medal around your neck. Not to earn your Agile Purity Badge, but to build the kind of culture that improves year over year.
This stuff moves fast. Even high-performing orgs degrade if they stop investing in getting better. The DORA report reminds us each year: stand still, fall behind. You can’t “do a metrics project” and be done. It’s not a Q3 initiative. It’s a muscle. It’s the oxygen in the room. Companies that don’t measure and learn continuously quietly suffocate.
The Wrong Receipts
So the Efficiency Era CEO wants their receipts. OK. Too many engineering leaders reach for the wrong ones.
Those poor saps. They dust off the ol’ velocity chart. The commit frequency dashboard. Artifacts dug up from a past life.
Then some absolute sucker trots out their unit test coverage, head held higher than the handler of a wire fox terrier at Westminster. Proud of the wrong damn thing.
And then—get this—some masochistic sicko mumbles “sprint completion percentage” in a metrics review prep meeting. Like the pain is the point; the metric’s only the excuse.
I’m being harsh—that’s kinda my shtick over here—but no matter how well-intentioned any of this is, it’s all noise. None of it tells the CEO what they actually care about: Are we getting more leverage from our engineering investment over time?
Jesus. They want to know: Is the system I’m funding accelerating the business?
They want to take apart the black box. See you wrapped in plastic wrap, donning your glass shoes. If you don’t give them a clear, confident, evidence-backed “yes” with metrics that ladder up to business outcomes? They’ll make up their own story where you might be the villain.
Bullshit Metrics and the Cowards Who Love Them
Factory Floor Fantasy
Most metrics we trot out are built on a lie. A fantastical work of fiction that describes software engineering like factory work—predictable, partitioned. Perfectly plannable.
Product stumbles out of a cave with clean outputs. Signed, sealed, blessed by the chief-something-or-other and “totally going to turn that conversion slump around—if it ships in 12 weeks instead of 15”.
Engineering clocks in and gets to work.
But you don’t build great software by throwing packages over a wall. You do it by breathing the same air. Flexing into each other’s spaces. The best teams contaminate each other on purpose. PMs and EMs inhaling the same context, exhaling joint decisions.
Yet some companies still live on Henry Ford’s factory floor. “Here’s the spec, build the thing”. But inputs change. Priorities shift. Reality rears its ugly head. When you wall off factions instead of flexing together, you get neither predictability nor agility. You get bureaucratic cosplay and passive-aggressive CCs. You bicker over estimates and delivery dates. Or waste your time explaining Brook’s Law to someone for the twelfth time this planning cycle.
That’s the sickness. That’s what’s buried deep under these metrics. They measure the wrong things. Assume the wrong model.
Fantasy League Stats for Engineering Teams
🏃➡️ Velocity? Try “proxy for how aggressive your estimates were”, or “how scared your team was to miss them”.
🏎️ Commit frequency? Your team is a single incentive away from running a shadow project to rename all of your services after bird names.
🏁 Sprint completion percentage? You’re killing me, Smalls. It’s a fantasy league stat. It’s torture-per-iteration for your ICs. It’s fuel for insecure managers to repeat on loop: “Why didn’t this make it in?”
🔢 Lines of code? “Oh, you said lines changed? I thought you said lives changed! Yeah, that’s easier to instrument anyway.”
These numbers aren’t bad because they’re quantitative, they’re bad because they’re divorced from the system they’re allegedly describing. They’re disconnected from the product. From the strategy.
They reduce engineering to an output engine. The numbers might spike, dip, or hold steady, but the business impact stays flat. It’s like tracking how many steps the chef took in the kitchen and thinking it’ll explain why the food tastes bad. Your execs will eventually wonder why the numbers wobble to and fro, but the things they care about don’t budge.
Metrics That Map the System
At another stop on the startup trauma tour, the siren song of speed rang out: “We need to move faster”. Sound familiar? Already? Ouch, that stings.
The assumption was, as it always is, that the slowness lived inside the code. Or maybe the people writing it. Fix the thing, swap the team, and suddenly we’d be guzzling jet fuel. Lobbing features so furiously into the market that our competitors wouldn’t just tap out, they’d go full Bird Box. Eyes bleeding, minds breaking, gazing at our roadmap like it was some Lovecraftian horror. Growth so incomprehensible that they’d forget how math works.
But alas, we operated in a heavily regulated space. And everything—I mean everything—was friction. Security reviews you’d need a Sherpa to navigate. Privacy “partners” who treated shipping like a breach. Audits stacked on audits.
The mistake we made? Letting the story write itself. Engineering looked slow, so the execs assumed we were. If we’d had a mature metrics program in place, we could’ve told the story. We could’ve said: Look, right here. The day the new privacy policy dropped, cycle time quadrupled. Some drag? Fine. But that much? That’s not underperformance. That’s a system reacting to—writhing instinctively against—a stressor it wasn’t designed to handle.
And that’s what good metrics are for. Not to settle scores or dunk on your cross-functional peers. Not to stack-rank teams or assign blame. They’re how we make the system legible. How we see where decisions made outside the team ripple through it. They reveal pressure points. Prompt conversations. Surface tradeoffs. They give you the receipts you actually need.
The Real End-Game
The goal isn’t to juice these numbers, then smugly tell your CEO, “See? I was right! Even after we tightened up our sprint hygiene, Product is still lining up bush-league impact models and we’re shipping all the wrong things! We’re all failing, but at least it isn’t my fault!” 🤦
Metrics are not for winning arguments. They’re for finding leverage. It’s not about making engineering look good. It’s about helping the business succeed.
What Actually Matters
The Part Where I Don’t Tell You What to Measure
You made it all the way down here. I hate to break it to you, but there isn’t a tidy stack of ten shiny metrics waiting for you like a prize at the bottom of the cereal box. There’s no “ultimate starter pack”, or a magic dashboard that saves your strategy and mends your broken culture. Anyone selling that is lying, confused, or in consulting. Handing you a solution without your organizational context is malpractice.
Metrics aren’t neutral. They create incentives. They change behavior. They can be weaponized—instantly and catastrophically—by executives looking for leverage, managers trying to polish their reputation, or engineers padding their brag docs. Most of it isn’t malicious. It’s just the same old mistake of pretending software is an assembly line.
So no—I won’t tell you what to measure.
And if your plan for “solving” productivity is switching on a metrics program, flagging “low-performing teams”, and swapping them out for mythical 10x unicorns, I can’t physically roll my eyes hard enough. Metrics aren’t cheat codes. They aren’t substitutes for context or judgment.
The real work starts somewhere else.
Name the Problem
Forget the symptoms. Forget the executive whisper-network and whatever cute narrative is being spun to help people avoid owning the mess. What’s actually happening?
Has growth stalled? Are customers bleeding out because quality is collapsing? Is tech debt turning every roadmap discussion into a hostage situation? Are competitors shipping things you can’t even attempt?
Whatever it is? Name it. Say the quiet part out loud.
Then—and this is the step everyone tries to skip—you go collect reality. Talk to people. Run listening tours. Send surveys that don’t feel like DMV paperwork. Gather gritty context that never makes it into QBR slide decks. And look at the signals you already have instead of sprinting, head over heels, into the arms of whatever metrics vendor seduced your CTO.
Form a hypothesis you can repeat back with a straight face.
Start Small, Measure Reality
Once you have a real hypothesis, pick a handful of starting points. Three. Five if you’re feeling reckless. Signals that actually help you understand whether your hypothesis is even directionally correct.
Choose metrics that say something about value delivered, or reliability, or the customer experience, or systemic drag. Not “how many Jira tickets did we yeet into the Done column this sprint”. Not story points and other proxies for “busyness”. None of these tells you whether you’re solving problems.
If you can’t articulate how a metric would change your behavior, drop it. Metrics that don’t inform decisions are just another form of organizational self-harm.
And seriously—seriously: never measure individual humans. You’ll torch morale. You’ll create perverse incentives. You’ll lose trust in record time. Leave the factory floor behind.
Make the System Legible
Your actual job isn’t to juice the numbers. It’s to read the system. Expose the friction. Surface the bottlenecks. Shorten the feedback loops. Reduce work-in-progress. Kill thrash. Build an environment where normal engineers—well-meaning, thoughtful people—can do the best work of their careers without dragging boulders behind them.
Do that, and the metrics will take care of themselves. Ignore it, and no dashboard in the world will save you.
And Yes—You Still Need Receipts
The Efficiency Era isn’t asking for perfection, but it does demand clarity and intent. You must show clearly and confidently how engineering increases business leverage over time. Build that leverage on purpose, rather than by coincidence. Metrics won’t save you, but they will help you demonstrate that you’re solving the right problems, in the right order, for the right reasons.
That’s what actually matters.