<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Leadership on Rough Edges</title><link>https://roughedges.dev/tags/leadership/</link><description>Recent content in Leadership 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/leadership/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><item><title>Rough Edges</title><link>https://roughedges.dev/posts/hello-world/</link><pubDate>Sat, 04 Apr 2026 09:20:00 -0400</pubDate><guid>https://roughedges.dev/posts/hello-world/</guid><description>&lt;p&gt;I'm an engineering manager. I've spent years building teams, shipping software, and keeping infrastructure from catching fire – sometimes successfully.&lt;/p&gt;

&lt;p&gt;The name is deliberate. Rough edges aren't a failure of craft. They're what you get when you make real decisions under real constraints. Every system has them. Every team has them. Anyone who tells you otherwise is either lying or hasn't shipped anything lately.&lt;/p&gt;

&lt;h2&gt;The philosophy&lt;/h2&gt;

&lt;p&gt;I'm pragmatic by nature. I believe, genuinely and without irony, that perfect is the enemy of the good.&lt;/p&gt;</description></item></channel></rss>