I can’t help but cringe when clients ask me about relaying R&D metrics to the CEO or the board of directors. These KPIs, which usually have no business being discussed in those forums, are often something tech executives bring up themselves, not realizing that doing so is handicapping their own authority. Like the cat that drags in the catch of the day to brag, we seem to be doing the same and achieving the same results (or worse).

Don’t get me wrong. I’m not saying you shouldn’t be tracking anything, like DORA metrics. I’m just saying it’s not the business of the business. I don’t know how much horsepower my car has, how long it takes to go from 0 to 60, etc. These are immaterial implementation details. I care about things such as getting where I need to on time and comfortably, safety for my children, etc. These are the business results. If I do care, it’s usually because something’s wrong.

Note: Workshop Palooza! I’ve just announced two workshops, the Engineer Excellence Accelerator and the Executive Evolution workshop. Triple impact-per-engineer and become the leader your team deserves. Early bird pricing is available till August 31st.

Don’t Be a Cost Center

In my first book, I cover the issue of tech leaders turning their organizations into cost centers themselves. They simply don’t know any better. They can’t come up with any other “R&D-focused” metrics and feel the need to discuss something, so they talk about this. However, this is like a call center measuring butt-in-seat time. That is not exactly how I’d like my (mind-bogglingly expensive) R&D team to be looked at.

More often than not, talking about our organization at this level leads to attempts to “optimize” it. If you’re going through layoffs, you might feel like this is useful to decide who won’t make it. Otherwise, it’s the wrong focus. Are you providing regular impact, or are you in charge of trying to squeeze every last drop from a pricey lemon?

What Is It Good For?

So why do we even care about these metrics anyway? Obviously, these are highly effective for tracking your team’s health. It is also useful when working on improving an organization to create transparency, highlight problematic areas, and connect the team. When you need to see whether your efforts are taking things in the right direction, these metrics can act as good leading indicators of progress.

We’d never want to be measured by the number of lines of code we add daily, right? Cycle time and deployment frequency are only one step removed from that. Use them for what they do best—help you internally.

No One Wants Your Code

You’re smart and all, but you aren’t kept around because the board really likes looking at well-crafted code. If it were possible to replace you with GPT4, it would’ve been done in a heartbeat. I think it was Alan Weiss who said that no one buys a hammer because they want to stick a nail in the wall—they want to improve the looks or function of their home. Similarly, your code only matters as a tool for achieving business results.

A VP of Sales would be gone in a second if all they had to show at the end of the quarter was hitting “X calls/day” and zero revenue. Similarly, many engineering metrics are not objectively comparable to other organizations and can be gamed—even subconsciously. I’ve seen teams that put their deployment frequency on a pedestal, resulting in people being very anal about splitting pull-requests to minuscule sizes. Each comment typo that wasn’t directly related to the touched code—even within the same file—would get its own pull-request, review, and merge cycle.

Your CEO shouldn’t care!

The Right Measures

Unfortunately for you, the right metrics are much harder to use—probably why you’re not already using them. This takes effort, but always keep in mind the alternative: You’re only good if replacing your team with two freelancers from Upwork doesn’t make sense (too often, it does! Which is why many CEOs approach me in the first place).

So, think of business-related measures and focus on those. Which you use and how specifically you craft them will change from one company to the next. Here are some examples I’ve used with clients in the past:

Business Objectives: Many tech executives feel like hitting OKRs is not “their” metric to be proud of. For example, if the CPO shares it, you might feel like you have nothing left to talk about. But, Product and R&D are a two-headed beast. Can’t have one without the other. This should be the thing you focus the most on.

Innovation: I keep saying that teams should bring their creativity to work much more than we’re used to seeing. A sizable chunk of that is how innovation takes place. How many initiatives have originated with R&D? How many experiments did you perform? Be mindful that this is not about tech debt. It’s about enabling new capabilities! I’ve written about this at length in Capitalizing Your Technology and The Tech Executive Operating System (clicking that last link will allow you to get a free chapter that details precisely this).

Quality: Customer satisfaction and similar metrics that your users care about and, therefore, the business cares about. Are you reducing the load on the customer success team? Can you show that your efforts result in quicker penetration into large organizations? That sort of stuff is crucial.

Strategic Gap: One of my favorites. Instead of talking about your headcount or how many people have progressed up the career ladder, show how well the team is placed to handle business needs. For example, was there a big business change that required organizational adaptations that you should have seen coming and prepared for in advance? If so, were you ready on time or two months later? Now, when you’re considering likely changes in the upcoming year, which would the team be able to cope with relatively fast, and which are currently glaring holes in your capabilities? This is the strategic gap between what’s needed and what you have made available.

If you want to discuss these among peers, consider joining my free community for startup executives. And if you want to triple impact-per-engineer and create a team that’s cranking out business results and not “change requests,” talk to me.