Proposal · For Director Review

Weekly KPI Reporting Process

A proposed weekly rhythm for the Techies engineering team: developers submit a changelog and self-set targets, Claude Code audits GitHub to quantify performance, and achievement is tracked against target — all aligned to our AI-oriented SDLC.

Prepared by: Paul Audience: Directors (approval) Status: Plan — not yet implemented Tools: Claude Code + GitHub

1Executive Summary

What we are proposing and why.

Each developer submits a short weekly report combining a narrative changelog and self-set targets with a % achievement. In parallel, Claude Code automatically audits GitHub to produce objective metrics across all four KPI categories (productivity, quality, AI adoption, delivery). The developer's self-report and the machine audit sit side by side, giving us a fast, fair, weekly read on performance that is hard to game and cheap to run.

Self-reported

Changelog + targets + claimed % achievement. Owned by the developer.

Machine-audited

Claude Code reads GitHub and quantifies the same period objectively.

Reviewed

Manager compares the two, coaches on the gap, rolls up a team view.

⚠️ This document is a plan for approval. Nothing is wired up yet — no scheduled jobs, no GitHub access changes. Implementation begins only after sign-off.

2The Weekly Cadence

A repeatable five-step loop, every week.

1
Mon (start): Developer sets/confirms the week's targets in the tracker.
2
Through the week: Developer records changes in the changelog as work ships.
3
Fri (EOD): Developer submits changelog + self-rated % achievement.
4
Fri/Mon: Claude Code runs the GitHub audit (self-run by dev, and a consolidated run by manager).
5
Mon review: Manager compares self-report vs audit, notes coaching points, updates the team rollup.
Two audits, by design: each developer self-audits and submits the result with their report; the manager runs one consolidated team audit. Same command, different scope — see Component B.

3Component A · Weekly Changelog Submission

A lightweight Markdown template, committed to the repo so it is versioned and visible.

3.1 What it captures

3.2 Proposed template — WEEKLY-REPORT.md

# Weekly Report — [Name] — Week of [YYYY-MM-DD]

## 1. Targets set this week
- [ ] Target 1: ...
- [ ] Target 2: ...
- [ ] Target 3: ...

## 2. Changelog (what shipped)
- Feature/fix: ...        (PR #__)
- Feature/fix: ...        (PR #__)
- Refactor / AI-assisted: ...  (PR #__)

## 3. Blockers & risks
- ...

## 4. AI usage notes
- Where Claude Code helped / where it didn't ...

## 5. Self-rated achievement
- Overall: __ %   (rationale: ...)

Format proposed: Markdown for the narrative + an Excel tracker (Component C) for the numbers. Both can be generated as starter files once approved.

4Component B · Claude Code GitHub Audit

An automated weekly read of GitHub that quantifies each developer across all KPI aspects — proposed design, not yet built.

4.1 How it works

4.2 What it quantifies — mapped to the four KPI categories

CategoryAuto-pulled from GitHub
Productivity & velocityMerged PRs, cycle time, median PR size, time-to-first-review
Code qualityChange failure rate, review pass rate, reverts/hotfixes, rework within 21 days
AI adoption% of PRs flagged AI-assisted, CLAUDE.md / shared prompt contributions
Delivery & reliabilityDeploy frequency, lead time, CI pass rate, MTTR on linked incidents

4.3 Proposed command spec

# Saved as a Claude Code slash command: /weekly-audit
Audit GitHub activity for AUTHOR=[username] over the last 7 days
(REPO=[org/repo...]). For that window, compute and report:

  Productivity : merged PRs, median cycle time, median PR size, time-to-first-review
  Quality      : change-failure rate, review pass rate, reverts, 21-day rework
  AI adoption  : % AI-assisted PRs (by label), CLAUDE.md / prompt contributions
  Delivery     : deploy frequency, lead time, CI pass rate, MTTR (linked incidents)

Output a one-page scorecard table: metric | this week | target | % to target | trend.
Flag any metric >20% off target. Do not infer effort from commit count or LOC.
Approval needed: this requires read access to GitHub for the audit (PRs, Actions, issues). Scope and who holds the connection are decisions for sign-off (see §8).

4.4 Automation options (to decide)

Option 1 — On-demand command

Devs and manager run /weekly-audit manually each Friday. Simplest; no infra. Recommended to start.

Option 2 — Scheduled job

A recurring weekly task runs the audit automatically and posts the scorecard. More automated; set up after the command is proven.

5Component C · Targets & % Achievement

An Excel tracker where each developer sets weekly targets and achievement is calculated against the audited result.

5.1 Proposed tracker columns

ColumnSourceExample
KPI / targetDev sets MondayCycle time < 2 days
Target valueDev2.0
Actual (audited)Claude Code audit2.4
% achievementAuto-formula83%
Self-rated %Dev90%
Gap / noteManagerReviews slow mid-week

% achievement auto-calculates from target vs audited actual, so the number is objective. The self-rated column captures the developer's own view; the gap between the two is the coaching signal.

Why both numbers: a healthy, calibrated developer's self-rating tracks close to the audited %. A persistent gap (in either direction) is what the Monday review focuses on.

6Sample Weekly Scorecard

Illustrative output of the audit + tracker for one developer. Numbers are placeholders.

MetricThis weekTarget% to targetTrend
Merged PRs65120%
Cycle time (days)2.42.083%
Change failure rate10%<15%on target
Review pass rate78%85%92%
AI-assisted PRs67%growth▲ vs last wk
CI pass rate88%90%98%
Self-rated achievement: 90%  ·  Audited composite: ~88%  ·  Gap: small, well-calibrated

7Roles & Responsibilities

Developer weekly

Sets targets Mon · records changelog · submits Fri · runs self-audit · self-rates % achievement.

Manager weekly

Runs consolidated team audit · compares self-report vs audit · coaches on gaps · maintains team rollup.

Directors monthly / quarterly

Receive the rolled-up trend · approve targets and weightings · use the data for review cycles, not weekly policing.

8Rollout & Decisions Needed

What we need directors to approve before building anything.

DecisionOptionsRecommendation
GitHub audit accessRead scope, who holds the connectionRead-only, manager-held to start
Automation levelOn-demand command vs scheduled jobStart on-demand, schedule later
Targets & weightsPer the KPI policy weightsBaseline 4 weeks before grading
Use of the dataCoaching vs formal reviewCoaching first; formal at quarter

8.1 Proposed next steps after approval