Engineering KPIs That Actually Matter
I once sat in a board meeting where a VP of Engineering showed a dashboard with twelve metrics. Lines of code per developer. PR count per sprint. Story points completed. Everything was green. The board nodded.
Two months later, the product still couldn't onboard a customer without a manual workaround, deploys broke every other week, and two senior engineers had started interviewing elsewhere.
The dashboard measured activity. Nobody measured whether the engineering organization was healthy, productive, or improving. That's the trap -- teams pick metrics that are easy to collect rather than metrics that tell them something useful.
The Metrics That Actually Tell You Something
DORA Metrics: Your Delivery Baseline
I've written about DORA metrics in depth before, so I won't rehash the full case here. But the four DORA metrics -- Deployment Frequency, Lead Time for Changes, Mean Time to Restore, and Change Failure Rate -- are the closest thing we have to a scientifically validated measure of software delivery performance.
They remain the foundation. If you're not tracking them, start there before adding anything else. They tell you whether your team can ship reliably and recover quickly, which is the baseline for everything downstream.
Cycle Time: Idea to Production
Cycle time goes broader than DORA's lead time. It measures the full journey from "we decided to build this" to "it's in production and users are touching it." This captures product decisions, design handoffs, spec clarification -- all the non-code bottlenecks that engineering teams inherit.
When cycle time is high but DORA lead time is low, the problem isn't engineering execution. It's everything upstream: unclear specs, slow approvals, design bottlenecks, or too many things in progress at once. Cycle time reveals organizational drag, not just pipeline drag.
Track it by timestamping when a ticket moves from "ready for development" to "deployed." Most project management tools can surface this with minimal configuration.
Customer-Impacting Incidents
Not all incidents are created equal. A failing background job that retries successfully is not the same as checkout being down for 40 minutes on a Friday afternoon. What matters is the frequency and severity of incidents that users actually feel.
Track two things:
- Incident frequency -- how many customer-impacting incidents per month?
- Severity distribution -- are they SEV-1 (business-critical) or SEV-3 (minor degradation)?
A team that has two SEV-3s per month is in a fundamentally different position than a team that has two SEV-1s per month, even though the count is identical. Aggregating without severity is meaningless.
The trend matters more than the absolute number. Are incidents decreasing over time? Is severity shifting downward? That tells you whether your reliability investments are working.
Time-to-First-Value for New Hires
This one is underrated and almost nobody tracks it: how long does it take a new engineer to ship something meaningful to production?
Not "how long until they merge a typo fix." How long until they deliver a real piece of work -- a feature, a bug fix with business impact, a meaningful infrastructure improvement.
If it's taking new engineers six weeks to ship their first real contribution, you have an onboarding problem, a codebase complexity problem, or both. Elite teams get new hires shipping in the first week. Not because they cut corners, but because they've invested in documentation, developer experience, and clear ownership.
This metric also tells you something about hiring quality. If an engineer takes three months to become productive regardless of seniority, the problem is likely your environment, not the person.
Engineering Satisfaction and Engagement
I know -- it sounds soft. But engineering retention is one of the most expensive line items you don't track, and by the time someone hands in their notice, the damage is done. Replacing a senior engineer costs six months of salary and twelve months of context.
Run a quarterly pulse survey. Five to seven questions: Do you believe in what we're building? Do you have the tools to do your best work? Do you feel like you're growing? Would you recommend this team to a friend? Track the trends. A downward trend over two quarters is a fire alarm.
The Dangerous Metrics
Some metrics are not just unhelpful -- they actively damage teams when leadership pays attention to them.
Lines of code. A developer who deletes 500 lines of dead code and simplifies a module has done more valuable work than one who wrote 500 lines of new code to solve a problem that could have been avoided. Measuring lines of code incentivizes bloat.
Commit counts. Easy to game, trivially inflated, and tells you nothing about the quality or impact of work. A developer working on a hard architectural problem might have three commits in a week. A developer cranking out boilerplate might have thirty. The three commits are probably worth more.
Individual output metrics. Ranking developers by PR count or tickets closed creates competition that destroys collaboration. The best cultures are team-oriented. Individual ranking pushes people toward hero behavior and away from code reviews, mentoring, and helping teammates unblock.
Hours logged. Measures presence, not productivity. Senior engineers often do their most impactful work in the fewest hours. If you're measuring hours, you're managing a factory floor.
Presenting Metrics to Leadership Without Getting Gamed
The board wants to know three things: Is the team effective? Is the team improving? Where are the risks?
Here's the structure I use:
Delivery performance -- DORA metrics, trended quarterly. Show the direction, not just the number. "Our deployment frequency increased from weekly to daily this quarter, and change failure rate dropped from 22% to 11%." That's a story the board can follow.
Quality and reliability -- customer-impacting incidents trended monthly, with severity breakdown. If incidents are up, explain why (new feature area, scaling challenges) and what you're doing about it.
Team health -- time-to-first-value for recent hires, plus engagement trends. These are leading indicators. A healthy team with strong onboarding and high engagement will deliver. A burned-out team with a broken onboarding pipeline is a risk, even if current output looks fine.
One thing to be careful about: present team-level metrics, never individual metrics. The moment a board member sees a ranked list of developer performance, they'll ask you to manage by that list. And then the metric becomes the target, the target gets gamed, and you've lost the signal entirely.
Keep the dashboard to five or six metrics. If you need twelve metrics to explain how engineering is doing, you don't understand how engineering is doing.
The Metric Behind the Metric
Every metric is a proxy. DORA metrics are a proxy for delivery capability. Incident counts are a proxy for reliability. Engagement scores are a proxy for retention risk. None of them capture the full picture on their own.
The real skill in engineering leadership is knowing which proxies to trust, when to investigate further, and when a number is telling you what you want to hear rather than what's actually happening.
At Conectia, when we embed senior engineers into a team, they often become the catalyst for better measurement -- not because they install dashboards, but because they bring the habit of asking "how do we know this is working?" They've seen enough teams to know which signals matter and which ones are noise. That's a mindset you can't get from a metric.
Want engineers who bring the judgment to know what to measure and what to ignore? Talk to a CTO -- our senior LATAM engineers have worked across enough teams to know which KPIs actually move the needle.
