A useful productivity measure?

Reactions to “value‑add capacity” as a metric

• Many like reframing productivity as “time spent on value‑adding work vs. maintenance/overhead,” and tying it to explicit product bets and ROI.
• Others argue this is really a time‑allocation metric, not productivity: 100% “value‑add time” can still produce useless or harmful features.
• Some suggest balancing it with explicit outcome measures (ROI actually realized, user satisfaction, system performance, SLAs).

Goodhart’s law and metric gaming

• Repeated concern that any visible metric will be gamed, especially under pressure from leadership.
• Examples: skipping bug fixes, deferring documentation, security, and upgrades to make “value‑add” numbers look good.
• Several see this as a lagging indicator: high maintenance later reveals past “false productivity.”

Tech debt, maintenance, and “muda”

• Strong debate on whether tech debt and maintenance can be meaningfully quantified.
• Some propose probabilistic/risk‑based approaches (inspired by “How to Measure Anything”), assigning dollar ranges and probabilities to classes of debt.
• Others argue bad or fake‑precise metrics are worse than none; qualitative gut checks and explicit tickets are preferred.
• Disagreement over whether skipping maintenance is always a flaw vs. sometimes rational if systems are frequently rewritten.

Alternative metrics and practices

• Suggestions include: DORA metrics, bug caps, stability/uptime measures, migration effectiveness, build/test times, active usage/adoption, and simple feature throughput.
• Lines of code and story points are widely criticized but a few see value in commit/LOC trends for spotting clear under‑performance.
• Some point to Bayesian, Monte Carlo, and other quantitative techniques, but note difficulty validating ROI and counterfactuals.

Management, C‑suite expectations, and culture

• Many see the root problem as leadership demanding simple productivity numbers for an inherently uncertain, creative, and collaborative activity.
• There’s concern about low‑trust environments, C‑suite ignorance of IT, and social dynamics that treat developers as factory workers.
• Others argue engineering leaders must still offer some honest, system‑level metrics and narratives, while constantly educating executives about their limits.