Techies — Developer KPI Policy (AI-Oriented SDLC)

1Purpose & Principles

Why this policy exists and the values it must protect.

1.1 Purpose

Define clear, fair, and measurable expectations for developers in an AI-assisted workflow.
Align individual output with team and business outcomes.
Make the transition from traditional to AI-oriented SDLC explicit and accountable.

1.2 Guiding principles

Outcomes over activity — measure shipped value, not raw volume (lines, commits).
AI is a multiplier, not a metric — adoption is encouraged, but quality and reliability remain the bar.
Balanced scorecard — no single metric decides performance; velocity is weighed against quality.
Transparency — every developer can see how their numbers are calculated.
Coaching first — KPIs drive improvement conversations before they drive ratings.

2The SDLC Shift

What changes when we move to an AI-oriented lifecycle — and what it means for how we measure people.

Traditional SDLC

Manual coding, line-by-line authorship, effort ≈ output, reviews catch most defects late.

AI-Oriented SDLC

Claude Code drafts, refactors, and tests; developer becomes director/reviewer; speed rises, so quality gates and judgement matter more.

2.1 Implications for KPIs

Volume metrics lose meaning — emphasis moves to review quality, integration success, and reliability.
New competency: effective AI direction (prompting, context, verifying AI output).
Higher throughput must not translate into higher defect or rework rates.

3KPI Framework Overview

Four categories, balanced weights. Tune weights before rollout.

Category	What it measures	Suggested weight
Productivity & Velocity	Throughput and flow of shipped work	25% (tune)
Code Quality	Defects, review health, test coverage	30% (tune)
AI Adoption	Effective use of Claude Code	20% (tune)
Delivery & Reliability	DORA-style deploy & stability metrics	25% (tune)

Legend: Individual tracked per developer Team tracked at team level. Most metrics inform both.

4Productivity & Velocity

Flow of value through the system — not raw output.

KPI	Definition	Target	Source
Cycle time Ind	First commit → merged to main	set baseline	GitHub
PR throughput Team	Merged PRs per dev per week	set baseline	GitHub
PR size Ind	Median lines/files per PR (smaller = better)	< 400 LOC	GitHub
Time to first review Team	PR opened → first review	< 4 working hrs	GitHub
Work-in-progress Ind	Concurrent open PRs/issues	set limit	GitHub

⚠️ Do not use commit count, lines of code, or hours as performance metrics. They reward the wrong behavior in an AI workflow.

5Code Quality

Speed is only valuable if what ships is correct and maintainable.

KPI	Definition	Target	Source
Change failure rate Ind	% of merged PRs causing a bug/revert/hotfix	< 15%	GitHub
PR review pass rate Ind	% PRs approved without major rework	set baseline	GitHub
Test coverage Team	% lines/branches covered on changed code	≥ 80%	CI / GitHub
Escaped defects Team	Bugs found in production per release	trend down	Issues
Rework ratio Ind	Code rewritten within 21 days of merge	set baseline	GitHub

5.1 Rule — AI output is owned by the author

Code generated by Claude Code is the developer's responsibility once submitted in a PR.
"The AI wrote it" is never an excuse for a defect, security issue, or untested path.
Every AI-assisted PR must be read, understood, and tested by the author before review.

6AI Adoption (Claude Code)

Measure effective use — adoption is a leading indicator, not the end goal.

KPI	Definition	Target	Source
Active usage Ind	Active days using Claude Code / week	set baseline	Claude Code
AI-assisted PRs Team	% of PRs where Claude Code was used	growth trend	Tag / convention
Proficiency tier Ind	Self + lead rating: Novice → Fluent → Advanced	Fluent by Q3	Review
Workflow contribution Team	Reusable prompts, CLAUDE.md, agents/skills shared	qualitative	Repo

6.1 Adoption expectations

All developers complete Claude Code onboarding within [X weeks] of this policy.
Each repo maintains a CLAUDE.md with project context and conventions.
Adoption is measured as a capability, not a quota — forcing AI use on unsuitable tasks is discouraged.

7Delivery & Reliability

DORA-aligned team metrics — the real test of whether AI velocity is healthy.

KPI (DORA)	Definition	Target	Source
Deployment frequency Team	How often we ship to production	≥ weekly	GitHub Actions
Lead time for changes Team	Commit → running in production	set baseline	GitHub
Change failure rate Team	% deploys causing a failure	< 15%	GitHub / incidents
Mean time to restore Team	Incident start → resolved	< 24 hrs	Incidents
CI pass rate Ind	% pipeline runs green on first push	trend up	GitHub Actions

8Data Sources & Measurement

Where each number comes from and how it's collected.

GitHub — PRs, reviews, merges, commits, Actions/CI, issues, reverts. Primary source of truth.
Claude Code — usage activity and AI-assisted work signals.
Convention — PR labels/template field to flag AI-assisted work and link incidents.
Manual / qualitative — proficiency tiers, workflow contributions, peer review notes.

Automation note: aim to auto-collect GitHub + CI metrics into a dashboard; reserve manual input for the qualitative items only. [Define dashboard owner & tooling.]

9Review Cadence & Scoring

How and how often KPIs are reviewed.

Cadence	Focus	Use
Weekly	Team flow metrics (velocity, CI, reviews)	Process tuning
Monthly	Quality & reliability trends	Coaching
Quarterly	Full scorecard, individual + team	Performance review

9.1 Scoring approach

Each category scored against target/baseline → weighted composite score.
Trend matters more than a single snapshot — improvement is rewarded.
Individual ratings always read alongside team context (small team = high variance).

10Guardrails & Anti-Gaming

Protect the metrics from distortion.

No single metric determines an outcome — balanced scorecard only.
Pairing metrics: velocity is always read with change-failure rate; coverage with escaped defects.
Banned-as-targets: commit count, lines of code, hours logged, raw AI usage volume.
Splitting PRs or padding tests to inflate numbers is treated as a quality issue, not a win.
KPIs inform conversations; they don't auto-trigger penalties.

11Rollout Plan

Phased introduction so the policy lands as support, not surveillance.

Phase	Activity	Timing
1 · Baseline	Collect current metrics, no targets yet	[Weeks 1–4]
2 · Calibrate	Set targets/weights from real data, share openly	[Weeks 5–8]
3 · Coach	Run cadence; metrics drive 1:1s only	[Quarter 1]
4 · Formalize	Scorecard enters review cycle	[Quarter 2+]

12Appendix & Glossary

DORA metrics — four research-backed delivery metrics: deployment frequency, lead time, change failure rate, MTTR.
Cycle time — elapsed time from starting work to merging it.
Change failure rate — share of changes that cause a failure requiring remediation.
CLAUDE.md — per-repo context file that guides Claude Code's behavior.
AI-assisted PR — a pull request where Claude Code materially contributed.
[Add company-specific definitions, SLAs, and links here.]