Measurement Ethics — Attribution, Not a Scoreboard
DevClocked team metrics are built for attribution, capacity planning, and spend justification — never for performance reviews, stack ranking, or presence policing.
Any measurement tool can be pointed at people. DevClocked is built so it can't be weaponised as one. Team metrics exist to explain work and plan capacity, not to rank, review, or police the humans doing it.
What team metrics are for — and what they are not
Built for:
- Attribution & evidence — tie shipped output to the humans and agents that produced it
- Capacity planning — see where effort and leverage actually land
- Spend justification — connect agent tokens and cost to real work
- Understanding delivery — how a feature came together, not who to blame
Never built for:
- Performance reviews or compensation decisions
- Stack ranking developers against each other
- Building a case for a PIP or termination
- Presence policing or return-to-office arguments
Why single-number targets fail
When a measure becomes a target, it stops being a good measure. That's Goodhart's law, and it is exactly why DevClocked never reduces a person to a single score. Turn leverage, hours, or commit counts into a target on someone's head and you don't get more good work — you get metric theatre: padded commits, gamed sessions, and effort redirected toward the number instead of the outcome. Our metrics are built to explain work, not to rank the people doing it. Every figure decomposes into its causes so it can be understood, questioned, and put back in context — never taken as a verdict.
Structural guardrails
This isn't a policy paragraph you have to trust. The structural choices below make stack-ranking hard to do in the first place.
- Sharing is member-controlled — each person chooses their sharing level, and can lower it at any time — retroactively. Managers can't unlock a member's raw detail. Private stays private.
- No people-leaderboards in team views — team surfaces benchmark projects, not people. There is no ranked list of developers by output. The only leaderboard is opt-in and lives on a public profile you choose to publish.
- Every metric decomposes — leverage, hours, and cost always drill into their causes — attention hours, agent runtime, output signals. A bare multiplier is never shown alone, so no number can pose as a verdict.
- Metadata only, sanitized rollups — team figures come from consented, sanitized rollups — never raw tables. No screenshots, keystrokes, file contents, prompts, or diff contents ever enter the system to be measured against anyone.
For works councils & DPOs
DevClocked captures operational metadata only — session timestamps, repo and language stats, agent runtime and tokens. It never records screens, keystrokes, webcams, app windows, or personal browsing. Team visibility is opt-in per member through sharing levels, applied retroactively when lowered, and every team figure is a sanitized aggregate rather than raw activity. There is no individual ranking surface and no presence-monitoring mode. In short: the minimum data needed to attribute and plan work, consented by the person it describes, and structurally unusable as a surveillance feed.
Governance summary, for the record:
- Metadata only — no screens, keystrokes, or contents
- Member opt-in sharing, retroactive when lowered
- Sanitized aggregates, never raw tables
- No individual ranking or presence mode
- Delete sessions, ranges, or your whole account
Read the full privacy stance at /privacy.
Measure the work, not the person
If a metric can't survive being explained to the person it describes, it doesn't belong on a dashboard. That's the bar DevClocked builds to. For how each number is actually derived, see How DevClocked Measures.
Was this page helpful?