WELLBEING-01] Establish sustainable pace norms and friction/burnout check-ins

[paruff]

[WELLBEING-01] Establish sustainable pace norms and friction/burnout check-ins

Labels: process, ai-ops, p2-important, effort-small
Assignee: 👤 Human
Phase: Phase 6 — Code Quality
DORA 2025 Source: “AI shows no measurable impact on workplace friction or burnout” finding; “Developer well-being” chapter
Effort: Small (half-day to document; ongoing practice)

---

Why the 2025 DORA Report Makes This an Engineering Issue, Not an HR Issue

One of the 2025 report’s most sobering findings: “Despite significant productivity gains at the individual level, AI shows no measurable relationship with friction or burnout. Both remain unchanged.”

The reason: friction and burnout are properties of organisational systems and culture, not individual tools. AI helps you generate code faster. It does not address unclear requirements, poor feedback loops, or the pressure created by perceived capacity gains inviting higher output expectations.

The report warns: “Evidence suggests perceived capacity gains invite higher expectations of work output… Most organisations default to work intensification without explicit discussion.”

For a solo or small-team vibe-coding project, this manifests as: Copilot makes features feel “cheap”, so the scope expands constantly, the backlog never shrinks, and the developer is always behind. The fix is not working harder — it is making conscious choices about how productivity gains are used.

---

Acceptance Criteria

Pace Norms Document

• docs/SUSTAINABLE_PACE.md created with explicit, written agreements about:
  • Scope gates: No new feature work starts until the current phase’s issues are at least 80% Done in the GitHub Project
  • WIP limits: Maximum 3 issues In Progress at any time (including issues assigned to Copilot that are awaiting review)
  • Weekly time budget: AI-assisted development sessions should not exceed X hours per day (team decides; recommended: 4 productive hours)
  • Rework as a signal: If the same type of issue is appearing twice in rework, stop and tune copilot-instructions.md before continuing
  • Definition of “done”: Issue is not Done until merged AND Sentry shows no new errors from the change

Friction Tracking (lightweight)

• A “Friction” column added to docs/METRICS.md with a simple weekly self-rating (1–5):
  • 1: Flow state — work is easy, outputs are good
  • 3: Normal friction — some rework, some confusion, manageable
  • 5: Blocked — rework is dominating, can’t make progress, outputs are wrong
• If friction rating is 4 or 5 for two consecutive weeks: mandatory PROCESS-02 tuning + VSM-01 review before continuing
• Friction rating tracked monthly alongside the other METRICS-01 metrics

WIP Limit Enforcement

• GitHub Project configured with a WIP limit of 3 for the “In Progress” column
• docs/SUSTAINABLE_PACE.md explains how to handle WIP limit violations: pull from In Progress to Ready, not by adding a 4th item

The Explicit Choice About Productivity Gains

• docs/SUSTAINABLE_PACE.md documents the team’s conscious answer to: “Now that Copilot can generate features faster, how do we use that capacity?”
  • Option A: Same output, less time (work-life balance priority)
  • Option B: More output, same time (product velocity priority)
  • Option C: Same output, same time but higher quality (technical excellence priority)
  • The 2025 DORA data shows that teams who default to Option B without discussing it tend toward burnout and instability

---

Files to Create

• docs/SUSTAINABLE_PACE.md
• Update docs/METRICS.md — add Friction self-rating column
• Update docs/RUNBOOKS.md — add “High Friction Response” runbook
• GitHub Project — configure WIP limit on “In Progress” column