Making Quality Metrics Reflect Team Performance

Huawei used operational quality metrics to evaluate delivery performance at both project and department levels. Indicators such as defect turnaround time and workflow compliance were regularly reviewed by leadership and influenced how team effectiveness was perceived.

As I became more involved in release coordination and delivery operations, I noticed that the team's actual efforts and the story told by the metrics did not always align.

The development and QA teams were consistently working hard to resolve issues quickly and maintain delivery quality. However, small process inconsistencies sometimes caused the reported metrics to underrepresent the team's performance.

For example, defect resolution time was expected to average within a 20-hour target. Because this metric was measured as an average, a small number of avoidable outliers could disproportionately impact the overall quality indicators.

I observed situations where:

• Defects were logged long before implementation and validation activities actually started.
• Low-priority defects were opened near the end of the working day, increasing the likelihood of becoming metric outliers.
• Completed defects remained open due to simple oversight.
• Merge requests were not consistently linked to their corresponding work items during periods of parallel development, affecting workflow traceability.

None of these reflected poor engineering execution, yet they negatively influenced how the team's quality was perceived.

• Existing quality KPIs and reporting mechanisms could not be changed.
• Improvements needed to work across multiple teams without introducing additional bureaucracy.
• Process changes had to be adopted through influence and communication rather than formal authority.

I reviewed defect queues daily and identified tickets that had already been implemented and validated but remained open, reminding owners to close them before they unnecessarily impacted quality metrics.

I explained to developers and QA engineers how the 20-hour metric was calculated and how opening defects before implementation work had begun could unintentionally distort team performance indicators.

I encouraged teams to complete investigation, implementation, and validation activities before formally logging non-urgent defects, reducing avoidable outliers in the reported averages.

I updated code review expectations to require merge requests to reference their associated work items and reinforced the practice during reviews when parallel development efforts caused gaps in sprint traceability.

The approach introduced a small amount of additional process discipline and awareness. However, the added effort protected the team from being unfairly evaluated based on administrative inconsistencies rather than actual delivery performance.

• Improved confidence that quality indicators reflected real team performance.
• Reduced average defect resolution time to approximately 10 hours through cross-functional team collaboration.
• Strengthened defect ownership and workflow consistency.
• Improved sprint traceability by reinforcing links between work items and code changes.
• Helped protect and accurately represent the team's delivery efforts in leadership reporting.

Metrics shape perception. Leadership decisions are only as good as the data behind them. Sometimes supporting a team means not only helping them deliver quality work, but also ensuring that the systems used to evaluate that work tell an accurate story.