Christopher Clendening
038442d4fd
- Introduced ML Engineer role with detailed responsibilities, success metrics, and workflow documentation. - Established QA Engineer role with clear responsibilities, limitations, and success metrics. - Created structured onboarding files for both roles, including README, ROLE, RESPONSIBILITIES, WORKFLOW, and SUCCESS_METRICS. - Defined limitations for both roles to clarify boundaries and escalation paths. - Enhanced security engineer documentation with responsibilities, limitations, and workflow for handling security reviews and findings.
32 lines
1.6 KiB
Markdown
32 lines
1.6 KiB
Markdown
# Success Metrics
|
|
|
|
How the Backend Engineer role's performance is actually judged.
|
|
|
|
## Primary metrics
|
|
|
|
- **QA pass rate on first submission.** A high rate of QA rejections on the same engineer's work
|
|
signals either rushed verification before marking done, or a gap in understanding acceptance
|
|
criteria before starting — both worth surfacing, not just individually fixing.
|
|
- **Verification honesty.** Did "tests pass" and "done" actually mean what they claimed, checked
|
|
against QA's independent verification? This outweighs raw throughput
|
|
(`../../EMPLOYEE_HANDBOOK.md`).
|
|
- **Review cycle efficiency.** Are review comments addressed substantively on the first response,
|
|
or does the same feedback need repeating across multiple rounds?
|
|
- **Scope discipline.** Do PRs stay inside their Task's described scope, with adjacent issues
|
|
flagged separately rather than folded in (`../../CODING_STANDARDS.md`)?
|
|
|
|
## What does NOT count as success
|
|
|
|
- High Task-closing volume if QA rejection rates are also high — that's premature closure, not
|
|
throughput (`../../WORKFLOW.md`).
|
|
- Passing review by avoiding anything architecturally interesting rather than engaging with
|
|
genuinely hard problems the Task required.
|
|
- Working around a security-hold or QA rejection instead of resolving the actual issue.
|
|
|
|
## Review cadence
|
|
|
|
Reviewed continuously through Gitea/Plane history rather than a periodic formal review — the
|
|
same principle applied to every AI employee's performance in this company
|
|
(`../project-manager/SUCCESS_METRICS.md`). Worth explicit revisiting at any retrospective
|
|
touching code quality or QA cycle time.
|