KPIs for Compensation: The Dangerous Game
One of the most common questions from non-technical founders is: "How do I measure my engineers so I know who to give a bonus to?"
It seems logical. Sales has Quotas. Support has Ticket Volume. Why can't Engineering have "Features Shipped"?
The problem is that engineering is not an assembly line; it is design work. When you tie money directly to individual output metrics, you don't get better engineering—you get Goodhart's Law: "When a measure becomes a target, it ceases to be a good measure."
In this guide, we look at the few metrics that actually matter, and how to evaluate performance without destroying collaboration.
Here is what we'll cover:
- The Anti-Patterns: Why "Velocity" and "Lines of Code" are toxic.
- The Input vs. Output Trap: Measuring busywork vs. impact.
- The DORA Metrics: The industry standard for team health.
- The Evaluation Model: A framework for assessing individual contribution.
1. The Metrics You Must Avoid
If you tie compensation to these, your culture will collapse immediately.
| Metric | The Result |
|---|---|
| Lines of Code (LOC) | Engineers write verbose, bloated code. Refactoring stops because deleting code "hurts" their score. |
| Velocity / Story Points | The team simply inflates the estimates. A "3 point" ticket becomes an "8 point" ticket. |
| Number of Commits | Engineers break one logical change into 10 tiny commits to look busy. |
| Individual Bug Fixes | Engineers might write buggy code just to fix it later, or hoard bugs from peers. |
2. Team Metrics vs. Individual Metrics
The Golden Rule of Engineering Leadership is: Measure the Team, Evaluate the Person.
You use metrics to see if the System is healthy (Deployment Frequency, Lead Time). You use observation and peer feedback to see if the Person is contributing.
Why? Because a Senior Engineer might spend zero hours coding this week because they spent 40 hours unblocking three Juniors. If you look at the metrics, the Senior looks "unproductive." If you look at the team, the team moved faster because of the Senior.
Mentor Tip: Never bring a dashboard of Jira tickets into a 1:1 performance review. It insults the complexity of the work. Discuss behaviors and outcomes, not charts.
3. The DORA Metrics (Team Level)
Google's DORA research identifies the only four metrics that scientifically correlate with high software performance. These should be your team's north star, but never individual targets.
- Deployment Frequency: How often do we ship? (Target: On-demand / Daily).
- Lead Time for Changes: Code commit to Production. (Target: < 1 day).
- Change Failure Rate: How often do we break production? (Target: < 5%).
- Time to Restore: When we break it, how fast do we fix it? (Target: < 1 hour).
If these are healthy, your engineering team is healthy.
4. How to Evaluate Individuals (The Ladder)
If we can't count tickets, how do we decide who gets a raise?
We use an Expectations Ladder. You evaluate the engineer against the expectations of their role, not a number.
Junior Engineer (L1)
- Expectation: Can complete defined tasks with guidance. Learns from mistakes.
- Failure: Repeatedly makes the same error; hides when stuck.
Senior Engineer (L3)
- Expectation: Solves undefined problems. Elevates the team (mentoring, code review).
- Failure: High individual output but ignores the team; creates complex "hero code" no one else can read.
Staff Engineer (L5)
- Expectation: Solves cross-team problems. Sets technical strategy.
- Failure: Disconnected from the codebase; focuses on "architecture astronomy" rather than shipping value.
Summary
Compensation should be based on Impact, not Activity.
- Stop counting: Ignore LOC, Commit counts, and Ticket volume.
- Measure the System: Use DORA metrics to health-check the team.
- Pay for Behaviors: Reward the Senior who unblocks others, not just the one who codes the fastest.
If you incentivize the "Hero", you kill the Team. If you incentivize the Team, you build a company that lasts.
