Goals and Metrics for a DevEx Team: Measure What Developers Actually Value

Ask a struggling DevEx team what they measure and you’ll usually hear a number like “percentage of services catalogued.” It’s a comfortable metric — easy to collect, easy to grow, easy to put on a slide. It’s also a good example of measuring the wrong thing. A catalog can be complete and still improve no one’s day. Getting metrics right in Developer Experience is less about picking better numbers and more about picking them for the right reasons, with the right people.

Set Goals With Developers, Not For Them

The first question isn’t “what should we measure?” It’s “who decides?” Metrics handed down from management — reduce deployment time by 50% — describe what leadership wishes were true. They rarely match what developers experience as friction day to day.

A DevEx team’s job is to figure out what matters together with developers. Let the people doing the work name the goals that would genuinely improve their days, then represent those goals honestly to the rest of the organization. This isn’t a soft nicety; it’s what makes the numbers real. Goals developers helped set are goals they’ll actually move. Goals imposed on them become targets to game.

Measure Processes, Not People

The fastest way to poison a metrics program is to make developers feel measured as people. The moment a dashboard looks like surveillance, honesty evaporates and the data becomes worthless.

I learned this on an IoT project on a factory floor, long before I was thinking about portals. The instinct was to track workers; the better design was to track the carts and processes instead, and to show the resulting dashboards to the people doing the work immediately. Nobody felt watched, because the measurement visibly served them — they could see their own flow and improve it. (I unpack that story further in Empowerment Beats Imposition.)

The same rule holds for a DevEx team: measure the health of processes, and put every number in front of developers first. When the people being measured are the first to benefit from the measurement, tracking stops feeling like monitoring and starts feeling like a tool.

Beware the Vanity Metric

Some numbers grow reliably while telling you nothing about whether anything got better. Catalog coverage is the classic one: it goes up as long as someone keeps adding entries, regardless of whether a single developer’s life improved. It measures activity, not value.

Treat coverage and entity counts as table stakes — necessary hygiene, never the headline. Weight your scorecard toward signals that reflect actual experience:

• Cognitive load — how much a developer has to hold in their head to get something done.
• Time to answer — how quickly someone can find the doc, the owner, or the decision they need.
• Time to onboard — how fast a new hire reaches meaningful contribution.
• Satisfaction — gathered continuously, in many small places, not once a year.

If a metric can hit 100% while developers still complain, it was never a goal. It was a vanity metric in disguise.

Measure Broadly, Densely, and in the Open

One annual satisfaction survey is the metrics equivalent of a single low-resolution photo — technically data, but too coarse to act on. Better to gather many small, dense signals continuously: a quick pulse after onboarding, a one-click reaction on a doc, lightweight feedback where the friction actually happens.

Two principles keep this healthy. Breadth — measure across the whole developer journey, not just the parts that are easy to instrument. Transparency — show the results back to developers in near real-time, so the measurement is visibly for them. Density plus openness beats a single precise-looking headline number every time.

The Two Sales, and the Feedback Loop Most Teams Miss

There are really two audiences a DevEx team has to win over, and they need different things.

The first sale is to management — convincing leadership to fund the work. Most teams manage this one; it’s the reason the team exists. The second sale is to developers — making them actually want to use what you build. This is where teams quietly fail, because they have no feedback loop with developers at all. They ship, they report adoption numbers upward, and they never ask the people on the other end whether any of it helped.

Metrics are how you close that gap. A real feedback loop with developers is both your best product signal and the most honest thing you can bring back to leadership. Which points at something worth saying plainly: a DevEx team earns its value by faithfully representing what’s really happening with developers — their friction, their wins, their mood. When the team is genuinely on the developers’ side, the signal it sends upward is trustworthy precisely because it wasn’t filtered to look good. That trust, in both directions, is the actual product.

Design for the Developer’s “Laziness”

One last lens that quietly shapes good goals: developers are “lazy” in the best possible sense. They gravitate toward the simplest path and the work that excites them — which is exactly what makes them efficient. Don’t fight that instinct; design for it. Make the right thing the easy thing, and your metrics start moving on their own, because good behavior becomes the path of least resistance rather than a compliance target.

Measure processes, not people. Set goals with developers, not above them. Prefer many honest signals over one flattering number. Do that, and your DevEx metrics stop being a reporting exercise and become what they should be — a shared instrument developers would ask for. At DevStage, that’s the kind of measurement we help teams build: transparent, developer-first, and pointed at value rather than activity.

Related reading: Understanding the Purpose of Developer Experience and Who to Hire for Your DevEx Team.