Oh boy... the #1 issue IMO isn’t the metrics or the technical implementation—it’s the human side. I always make sure to include this in the Risk section of my engineering metrics reports: 'Misinterpretation of the information conveyed by these metrics by stakeholders outside the team.'
Keeping metrics from being weaponized is a challenge. And I’d be cautious about introducing them in cultures where engineering is treated as a cost center—it can do more harm than good.
I agree Ezequiel! I am curious: do you do periodic engineering metrics reports for stakeholders? What goes in there in terms of KPIs, sections, etc? How is it working for you?
I did! I used to do it in previous engagements, but I’m not doing it in my current ones.
I started introducing engineering metrics years ago after reading Accelerate, with a heavy focus on delivery—mainly DORA—as a way to measure both myself and the team against the benchmarks mentioned there. I was already presenting reports with control charts, cumulative flow diagrams, and throughput, so it felt like a natural extension. I even wrote an article about it on my LinkedIn back then.
When better frameworks and tools like LinearB and Swarmia came along, I started experimenting with them because they provided a more holistic view of flow. I introduced flow efficiency to identify multitasking and bottlenecks, along with other tools to track scope creep and improve collaboration through work logs.
I also collaborated with the People & Culture team to introduce engineering-focused questions into eNPS surveys, aligning more closely with the SPACE framework and the shift toward qualitative metrics.
I really like having that information available—it genuinely helps improve flow and cadence when used correctly.
But as I mentioned in my first comment, misusing them can also do harm, even with the best intentions. There will always be a need to measure engineering’s contribution to the bottom line, and with that comes the risk of tracking it at the individual level.
Engineers are usually reluctant to adopt metrics like these, and I totally get it. There’s always the risk of damaging trust. And since I do believe psychological safety is the foundation of high-performing teams, misinterpreting them can even hurt productivity. Not to mention the Goodhart’s “When a measure becomes a target, it ceases to be a good measure.”
Oh boy... the #1 issue IMO isn’t the metrics or the technical implementation—it’s the human side. I always make sure to include this in the Risk section of my engineering metrics reports: 'Misinterpretation of the information conveyed by these metrics by stakeholders outside the team.'
Keeping metrics from being weaponized is a challenge. And I’d be cautious about introducing them in cultures where engineering is treated as a cost center—it can do more harm than good.
I agree Ezequiel! I am curious: do you do periodic engineering metrics reports for stakeholders? What goes in there in terms of KPIs, sections, etc? How is it working for you?
Also happy to jump in a call if you prefer!
I did! I used to do it in previous engagements, but I’m not doing it in my current ones.
I started introducing engineering metrics years ago after reading Accelerate, with a heavy focus on delivery—mainly DORA—as a way to measure both myself and the team against the benchmarks mentioned there. I was already presenting reports with control charts, cumulative flow diagrams, and throughput, so it felt like a natural extension. I even wrote an article about it on my LinkedIn back then.
When better frameworks and tools like LinearB and Swarmia came along, I started experimenting with them because they provided a more holistic view of flow. I introduced flow efficiency to identify multitasking and bottlenecks, along with other tools to track scope creep and improve collaboration through work logs.
I also collaborated with the People & Culture team to introduce engineering-focused questions into eNPS surveys, aligning more closely with the SPACE framework and the shift toward qualitative metrics.
I really like having that information available—it genuinely helps improve flow and cadence when used correctly.
But as I mentioned in my first comment, misusing them can also do harm, even with the best intentions. There will always be a need to measure engineering’s contribution to the bottom line, and with that comes the risk of tracking it at the individual level.
Engineers are usually reluctant to adopt metrics like these, and I totally get it. There’s always the risk of damaging trust. And since I do believe psychological safety is the foundation of high-performing teams, misinterpreting them can even hurt productivity. Not to mention the Goodhart’s “When a measure becomes a target, it ceases to be a good measure.”
There is some interesting research in this space from my colleagues at Google -
Developer Productivity for Humans, 7 part series:
Part 1: https://ieeexplore.ieee.org/document/9994260
Part 2: https://ieeexplore.ieee.org/document/10043615
Part 3: https://ieeexplore.ieee.org/document/10109339
Part 4: https://ieeexplore.ieee.org/document/10176199
Part 5: https://ieeexplore.ieee.org/document/10273824
Part 6: https://ieeexplore.ieee.org/document/10339107
Part 7: https://ieeexplore.ieee.org/document/10372494