<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Performance on Rough Edges</title><link>https://roughedges.dev/tags/performance/</link><description>Recent content in Performance on Rough Edges</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Mon, 06 Apr 2026 00:00:00 -0400</lastBuildDate><atom:link href="https://roughedges.dev/tags/performance/index.xml" rel="self" type="application/rss+xml"/><item><title>Measuring Engineering Performance: Activity Is Not Output</title><link>https://roughedges.dev/posts/measuring-engineering-performance/</link><pubDate>Mon, 06 Apr 2026 00:00:00 -0400</pubDate><guid>https://roughedges.dev/posts/measuring-engineering-performance/</guid><description>&lt;p&gt;The case for making engineering performance visible is legitimate. Hidden underperformance is a real organizational problem, and managers who avoid measuring their teams are often just avoiding difficult conversations. That much is fair.&lt;/p&gt;
&lt;p&gt;The problem is the tool, not the intent.&lt;/p&gt;
&lt;p&gt;GitHub activity metrics – PR counts, commit frequency, lines of code – are proxies. They measure inputs, not outcomes. And once any metric becomes a target, it stops being a reliable signal. This is Goodhart&amp;rsquo;s Law, first articulated in economics but applicable almost anywhere humans are being measured. Engineers are rational people. Tell them their PR count matters and you&amp;rsquo;ll get more PRs – smaller, more frequent, shallower in scope. Tell them reviews are tracked and you&amp;rsquo;ll get more reviews that say &amp;ldquo;LGTM.&amp;rdquo; You haven&amp;rsquo;t improved performance. You&amp;rsquo;ve changed what people optimize for.&lt;/p&gt;</description></item></channel></rss>