Culture & metrics

Measuring engineers without surveillance

By the CodPal team · Updated 17 August 2026

The fastest way to destroy trust on an engineering team is to point a metrics dashboard at individuals and start ranking them. Developers can smell it instantly, and they respond exactly as you would expect: they optimise the metric, stop taking risks, and quietly disengage. But the alternative is not flying blind. You can measure delivery — you just have to be deliberate about what you are measuring and why.

What actually makes it surveillance

"Surveillance" gets used loosely, which makes it hard to avoid. It is worth being precise, because the distinction is not about which metrics you collect — it is about three properties of how you use them.

1. Covert collection. The data is gathered without anyone explaining what is being recorded or why. Note that engineers usually work out that a tool exists long before anyone tells them, and discovering it themselves is far worse than being told.
2. Individual evaluation. The output is used to judge people rather than to understand the system. This is the one that does the real damage, and it is entirely a choice about use, not about data.
3. One-way visibility. Managers can see the numbers and the people in them cannot. Asymmetry is what makes it feel like being watched rather than being measured.

A tool that reads commit history is not surveillance. A tool that reads commit history, was never mentioned to the team, feeds a ranking in performance reviews, and is only visible to directors — that is surveillance, and no amount of careful metric design fixes it.

Measure the system, spotlight the help

Metrics should answer "where is our delivery system slow?" not "who is the slowest person?" Those questions look similar and lead to opposite places.

Consider a team whose cycle time has doubled. The system question asks where the time is going, and the answer is usually structural: pull requests are too large, first review is taking two days, or work is being started faster than it is finished. Each of those has a fix that a manager can actually apply. The person question asks who is slowest, and the answer — whoever drew the hardest tickets — has no useful action attached to it at all.

This is why review pickup time, PR size distribution and work in progress are more useful than any per-person throughput number. They point at the queue, not the queue's occupants.

When per-person signals are legitimate

There is a real use for individual data, and pretending otherwise is dishonest. It is spotting the engineer who is overloaded — work in progress piling up, nothing closing — or who has gone quiet, which usually means blocked or stuck rather than idle. Both are cases where a manager who notices in week one is useful and a manager who notices in week six is not.

The same data, with the same charts, serves either purpose. What separates them is what happens next: a conversation that starts "what's in your way?" or one that starts "your numbers are down." One of those makes the metric more accurate over time, because people stop hiding. The other makes it useless within a quarter.

A rule that has held up for us: if a number could appear in a performance review, it should not be collected per person. Not because the number is wrong, but because its presence in that room changes the behaviour it measures.

Individual numbers are noisy — don't pretend otherwise

Even setting ethics aside, per-person metrics are statistically weak. A single developer's commit count or PR velocity ignores mentoring, review, design work, incident response, and the hard tickets nobody else will touch. It is also dominated by assignment: whoever picked up the gnarly migration will look slow, and whoever picked up six small bug fixes will look fast.

The commits per developer page in our own docs says this explicitly, and deliberately carries no benchmark tier — there is no honest "good" number for a commit count. Aggregate to the team and most of that noise cancels out, because assignment variance averages away across a group in a way it never does for one person over one sprint.

This is also why tying DORA metrics to individual reviews backfires so reliably. DORA was designed to measure teams and delivery systems. Attach it to a person's rating and you have created an incentive to split deploys, slice pull requests past the point of usefulness, and stop logging incidents.

Transparency, not one-way glass

Surveillance is one-way: they watch, you do not know. Healthy measurement is symmetric — everyone can see the same dashboards, the definitions are open, and there are no secret scores.

Concretely, that means three commitments worth making out loud:

• Everyone sees the same numbers. If a chart exists, the people in it can open it. A metric a team cannot see is a metric they cannot act on, which makes it useless even on purely practical grounds.
• The definitions are inspectable. Because Deckgauge is source-available, an engineer who disputes a number can read the query that produced it. That sounds like a small thing until the first time someone disputes a number — a metric nobody can audit loses every argument it is ever in.
• Say what a proxy is. Where deployment or incident data is not connected, Deckgauge labels the affected DORA metrics as proxies rather than presenting an estimate as a measurement. Overstating precision is its own kind of dishonesty.

Works councils, and why they are usually right

If you operate in Germany, Austria, the Netherlands or much of Scandinavia, a works council may have genuine co-determination rights over the introduction of systems capable of monitoring employee performance. In practice that means an engineering-metrics tool can be blocked outright, and teams routinely discover this after they have already signed a contract.

The productive move is to involve them before choosing a tool rather than seeking approval afterwards. Two properties make that conversation dramatically easier:

• Self-hosting. The data never leaves company infrastructure, so there is no third-party processor to assess and no cross-border transfer to argue about. For many councils this is the single biggest objection removed.
• Aggregate-only mode — designed, built to order. A mode that switches per-individual breakdowns off entirely, leaving team and org totals, so that an agreement of "no individual statistics" is honoured in the software rather than in a promise. It is scoped but not in the product today; we build it for the customer whose rollout depends on it. If that is you, raise it before you commit to anything.

This is not legal advice. Co-determination rights, the lawful basis for processing, and retention obligations all vary by jurisdiction and by your existing agreements. Talk to your own counsel. What we can tell you is what the software does and does not do, which is usually the input your counsel actually needs.

The GDPR angle, briefly

Commit authorship, review activity and ticket assignment are all tied to identifiable people, so engineering metrics involve personal data and the ordinary obligations follow: a lawful basis, purpose limitation, transparency about what is processed, and sensible retention. Self-hosting does not remove any of that. What it does remove is a processor from your records, a transfer mechanism to document, and most of the difficulty in answering an access request — the data is in your own database, so you can actually see what you hold.

A policy you can put in writing

The most useful thing we have seen a leader do is write down the rules before turning anything on, and share them with the team. It takes an afternoon and it prevents the whole failure mode. A version worth stealing:

1. Metrics exist to improve the delivery system, never to rank individuals.
2. No metric from this tool appears in a performance review or a compensation decision.
3. Every dashboard is visible to everyone it describes.
4. Per-person views are used for one purpose: noticing when someone is overloaded or stuck.
5. Anyone can ask how a number is calculated and get a real answer, or read the code.
6. If the team thinks a metric is being misused, that is a legitimate thing to escalate.

The last one matters more than it looks. A stated policy with no enforcement route is just a nicer-sounding version of the same asymmetry.

Frequently asked

Can you measure developer productivity without surveillance?

Yes, by changing the unit of analysis. Metrics aggregated to the team answer where the delivery system is slow, which is the useful question, without producing a per-person score. Where individual signals are shown at all, the purpose has to be finding who needs help — someone overloaded or blocked — rather than ranking people against each other.

What makes engineering metrics count as surveillance?

Three things, in practice: the data is collected covertly or without explanation, it is used to evaluate individuals rather than the system, and the people measured cannot see what is recorded about them. Remove those three and you have measurement. Keep any one of them and engineers will correctly read it as monitoring, and will optimise against it.

How do you handle a works council when introducing engineering metrics?

Bring them in before you buy, not after. In several European jurisdictions a works council has genuine co-determination rights over systems capable of monitoring employee performance, which means a tool can be blocked outright. Self-hosting helps because no data leaves the company. An aggregate-only mode, which would remove per-individual reporting entirely, is designed and built to order — it is not in the product today, so if a works-council agreement requires it, raise that before you commit. Get your own legal advice for your jurisdiction.

Does GDPR apply to engineering metrics?

Commit authorship, review activity and ticket assignment are all linked to identifiable people, so metrics built on them involve personal data and the usual obligations follow — a lawful basis, purpose limitation, transparency and retention limits. Self-hosting does not remove those obligations, but it does keep you from adding a processor and makes data-subject requests far simpler to answer. This is not legal advice.

What is aggregate-only mode?

A planned configuration in which Deckgauge would show team-level and org-level totals and hide every per-individual breakdown, so that organisations which cannot show individual statistics — because of a works council agreement, a collective agreement, or their own policy — could still read delivery health. It is designed and scoped but not built: we build it for the customer who needs it, as part of an enterprise engagement. It is not available in the product today.

Read your own delivery, on your own terms. Deploy Deckgauge free, or book a Health Check to get a read without turning it into a witch hunt.