When Private Equity boards want to optimize engineering costs, they often fall into a dangerous trap: using software to measure "developer productivity" using lines of code, velocity points, or pull request wait times. In Episode 15 Paul and Dave navigate the "viper pit" of software measurement.

They break down why comparing velocity across teams is statistically meaningless, why vanity metrics invite gaming, and why automated productivity tools completely ignore essential "glue work"—the cross-team coordination and architectural alignment that keeps complex software systems standing.

Drawing on Dr. Nicole Forsgren and Abbi Noda’s research in Frictionless as well as W. Edwards Deming’s classic management principles, Paul and Dave reveal why Operating Partners should stop chasing developer productivity and start optimizing Developer Experience (DevEx).

By eliminating Lean waste — such as paying $180k engineers to sit around waiting 3 days for manual testing — operating teams can unlock massive financial leverage and drive sustainable EBITDA expansion.

Key Takeaways:

• Goldratt’s Law in Tech: "Tell me how you'll measure me, and I'll tell you how I will behave." Measuring developers by lines of code or story points only incentivizes teams to build bloated, unnecessary features faster.

• The "Glue Work" Blindspot: As highlighted in Tanya Reilly’s seminal essay and talk Being Glue (https://www.noidea.dog/glue), the most valuable engineers on a team are often doing "glue work"—coordinating API contracts, establishing architecture standards, and aligning cross-functional teams. Vanity productivity tools rate these engineers poorly because they write fewer lines of code, creating toxic promotion incentives.

• The Cost of Waiting (Lean Waste): Paying a $150k–$180k software engineer to wait 3 days for manual QA or deployment approvals is pure operational waste. Eliminating 3 days of waiting per developer across a portfolio company directly impacts the bottom line.

• Deming’s Point #5 for PE: "If we improve the system, we reduce costs." Developer productivity shouldn't be measured in isolation; it must exist in service of building better products that customers eagerly pay for, with business metrics anchored right alongside engineering KPIs on the boardroom dashboard.