Help! My manager is asking me for KPIs ! by Geoffrey Graveaud
(link)Summary
Geoffrey Graveaud explains how to respond when management asks for KPIs in agile, DevOps, and craft transformation contexts. Using concrete examples, he shows why top-down targets like code coverage or deployment frequency often fail when they ignore team reality, dependencies, and system constraints. The talk presents a practical approach: identify the performance concept, map it to observable actions, and connect those actions to meaningful metrics. Graveaud also covers how to collect qualitative feedback with well-designed anonymous forms, how to use DORA metrics for throughput, and how to build evidence that helps managers challenge unrealistic targets and support organizational change.
Key Takeaways
- A KPI request should be translated into clear intent, observable actions, and measurable signals, not accepted as a raw target.
- Top-down metrics such as arbitrary code coverage or velocity goals can create disengagement or misleading behavior.
- DORA metrics are useful for measuring throughput, but only when linked to the team’s actual delivery system and constraints.
- To understand team performance, combine quantitative data with qualitative feedback collected through anonymous, well-designed forms.
- Useful KPIs should be clear, relevant, and meaningful, and should keep people interested rather than just enforce compliance.
Sections
Why KPI requests create problems
The talk opens with common situations where managers ask for KPIs after agile or DevOps changes. Graveaud argues that these requests often come from a top-down approach: strategy is defined above the team, then translated into targets like 80% code coverage or a specific velocity number. In practice, this can create pressure without addressing the real system constraints.
Examples of bad KPI targets
Several examples show how targets become detached from reality. A large department may turn "quality" into code coverage quotas for dozens of backend teams. A small team may be told to increase velocity by decree. A technical leader may be asked to raise deployment frequency without fixing architectural coupling, team dependencies, or release constraints. The talk frames these as impossible or misleading KPI demands.
Using DORA metrics correctly
Graveaud uses DORA metrics as an example of useful throughput measurement, especially lead time for change and deployment frequency. He emphasizes that these metrics are only meaningful when they are connected to real delivery events, such as commits, tags, and production releases. DORA metrics can reveal how delivery works, but they do not solve underlying organizational problems by themselves.
From concepts to observable actions
A central method in the talk is to start with the concept you want to measure, identify observable actions related to that concept, and then select metrics for those actions. For example, if the concept is test automation, observable actions may include test report generation, pipeline integration, or quality gates. Metrics might include test report counts, test duration, or defect trends.
Collecting evidence with anonymous feedback
To challenge unrealistic targets like fixed code coverage goals, Graveaud recommends collecting team feedback through a well-designed anonymous form. He describes basic survey rules: measure what you intend to measure, avoid biased wording, use an appropriate scale, and preserve anonymity. This makes it possible to gather qualitative evidence about real blockers such as obsolete code, modularity issues, or expensive test integration.
Bottom-up evidence for management decisions
The talk argues that quantitative metrics alone are not enough. Managers need both reliable numbers and mass qualitative feedback to justify changes to the strategy. This bottom-up evidence helps leaders explain why a target is unrealistic and what organizational changes are needed. The manager’s role becomes one of scaling up solutions rather than simply enforcing thresholds.
Final guidance for teams and managers
Graveaud ends with three criteria for KPIs: they should be clear, relevant, and meaningful. He also reframes KPI as "keep people interested," stressing that metrics should support engagement, not just control. The overall message is that KPI discussions should improve understanding of the system, keep teams involved, and help leaders make better decisions.
Keywords: kpi in agile teams, software delivery performance, dora metrics, lead time for change, deployment frequency, code coverage metric, observability in devops, top-down vs bottom-up metrics, agile coaching, team performance measurement, anonymous feedback survey, qualitative and quantitative data, management kpis, software engineering metrics, accelerate metrics