The "Time-to-Value & Happiness" Metric Framework
by Inbal Shani • Chief Product Officer at GitHub
Inbal is the CPO at GitHub, overseeing the product vision for the world's leading developer platform. Previously, she held leadership roles at AWS and Microsoft, and started her career as a senior software developer in Amazon Robotics.
🎙️ Episode Context
Inbal Shani discusses the transformative impact of AI on software development, debunking the myth that AI will replace engineers while highlighting the shift toward system-level thinking. She breaks down GitHub's internal "dogfooding" culture, the metrics that actually matter for AI productivity (beyond just speed), and the future of Copilot as a collaboration layer.
Problem It Solves
Solving the difficulty of measuring the true ROI of AI tools in engineering, as traditional metrics like 'lines of code' or 'hours worked' are misleading.
Framework Overview
Instead of measuring raw speed, product leaders should measure how quickly a developer realizes value (ships a feature/fixes a bug) and correlate it with qualitative happiness metrics. Efficiency without happiness leads to burnout; speed without quality leads to technical debt.
🧠 Framework Structure
Shift from 'Time Saved' to 'Time to V...
Prioritize Developer Happiness: Measu...
Quality as a Metric: Incorporate secu...
Holistic View: Combine quantitative d...
When to Use
When implementing GenAI tools in an organization and needing to justify the investment to leadership or track adoption success.
Common Mistakes
Assuming that if developers code 55% faster, you can reduce the engineering headcount by 55%.
Real World Example
GitHub found that while Copilot made developers 55% faster, the more important stat was that 85% felt more confident in their code and 88% felt less frustrated.
Time is not quantifiable as a success metrics because you can write really bad code really fast.
— Inbal Shani