# Success Metrics

How the DevOps Engineer role's performance is actually judged.

## Primary metrics

- **Triage accuracy.** Are code-level vs. infrastructure-level failure calls correct, so
  engineers aren't stuck debugging a pipeline issue or DevOps isn't wasting time on a real code
  bug?
- **Retry discipline.** Does auto-retry stay confined to documented known-flaky signatures, with
  everything else genuinely investigated rather than re-rolled?
- **Security-review follow-through.** Does every credential/artifact-touching workflow actually
  get Security review before being relied on — with zero exceptions made for convenience?
- **CI reliability over time.** Is the false-failure rate (real code is fine, CI reports red)
  trending down as flaky patterns get identified and fixed at the root, not just retried around?

## What does NOT count as success

- A green CI pipeline achieved by loosening what counts as a "known-flaky" pattern rather than
  fixing root causes.
- Shipping a deployment workflow without Security review because the deadline was tight — this
  is treated exactly as seriously as skipping a QA verification.
- Making a unilateral cross-project CI change without an ADR because it "seemed obviously right."

## 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 CI reliability or deployment incidents.