On a client assignment, a QA comes to see me. He’s annoyed.
The developer on his team refuses to let him log minor bugs.
He prefers that we leave a simple comment in the US. Why? Because if the bug is logged, it’s included in the KPIs. And some indicators measure… the number of bugs per developer.
But QA is also evaluated.
His KPI? The ratio between bugs detected during testing and those found in production.
👉 A developer who wants to avoid unfavorable figures.
👉 A QA who must log anomalies to demonstrate the quality of his validation.
A real dilemma.
My role, as a coach, is not to judge. It’s to bring the team together around a clear and shared workflow. ✅ If we choose to comment in the US, then it can’t be passed to DONE until the bug—even a minor one—is fixed.
✅ If we decide to let a minor bug go into production, then it’s a managed risk. But this bug must be traceable, without penalizing team members.
💡 The real problem isn’t the bug.
It’s how we interpret and use KPIs.
A KPI isn’t there to judge, but to enlighten.
If it breeds mistrust or conflict, it’s because we’re using it incorrectly.
Let’s remember: we’re all in the same boat. And my goal as a coach is to help the crew progress—together. With trust, clarity… and a little common sense.
👉 And you? How are KPIs perceived in your team? A support… or a weight?
Leave a Reply