iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Make team leads accountable for the systems and processes that produce results, not for slices of a company metric they only partly control. Track those systems with a small, fixed set of measures, set thresholds from observed data, and use a monthly review to ask what is blocking progress. That is the core of an approach Mansur Fattakhov describes in a first-person practitioner article published September 27, 2026. He developed it for team leads on a game-development project with six teams, and it is aimed at a familiar problem: how to create visibility and clear ownership across teams without turning a KPI into a punitive target that people game.
Why a shared KPI becomes a stick
A company-level metric, such as a product quality or revenue target, usually depends on dozens of decisions made by people who do not own the metric. When a lead is judged on that number, two things tend to happen. The lead has no lever that moves it reliably, so the number feels arbitrary. And the team learns to optimize the number itself, which can mean hiding defects, reclassifying incidents, or chasing a figure that does not reflect the work. Fattakhov frames the question as one of making everyone work on product quality rather than on a leadership KPI, and of agreeing on what each lead is answerable for in the first place.
Make the lead responsible for the system
The central design choice is to shift accountability from the outcome to the machinery that produces it. Fattakhov puts it directly:
Free tools Windows power users keep installed
One-click scans. No signup required.
“The central decision everything rests on: a lead is responsible not for the final business metric, but for the system and the processes that make the outcome inevitable.”
#1 Best Overall
- The Five Dysfunctions of a Team
- English
- hardcover
- First Edition
- gelatine plate paper
The outcome still matters. What changes is the management conversation, which asks whether the supporting system exists and is improving. His examples make this concrete. For QA, the lead owns a current regression suite, release verdicts, and a review of escaped defects. For infrastructure, the lead owns meaningful alerts, runbooks, and a declining recovery time. The lead is judged on how well the system works, not on a result that depends on many other people.
To describe the state of a system, he uses three levels:
- Good: the system works and is still developing.
- Satisfactory: the system exists but has gaps, or it is used irregularly.
- Unsatisfactory: there is no system, and work depends on reactive manual effort.
These levels are the author’s method rather than a standardized rating scale, so a team that adopts them will need to define what counts as a gap in its own context.
Recommended Free Tools
Rank #2
Two kinds of measures: standing and monthly
Fattakhov separates measures into two groups with different jobs. Standing KPIs cover recurring role hygiene that should stay true every month. Monthly KPIs are a few cycle-specific improvements that change from one period to the next.
| Measure type | Purpose | Examples given in the article |
|---|---|---|
| Standing KPI | Keep the role’s core system healthy | Monitoring coverage, current regression tests, incident reviews, release decisions |
| Monthly KPI | Drive one or two specific improvements per cycle | Closing a piece of technical debt, improving coverage, reducing recovery time, running a Game Day |
He suggests a ceiling of three or four standing measures and three or four monthly measures per team. These are practical recommendations from his own project, not a benchmark drawn from a study. He also sets three conditions on the list itself: measures should come from live systems, thresholds should come from observed baselines, and the whole list should stay small enough that maintaining it does not cost more than it returns.
The article gives examples of system-to-measure pairings:
Rank #3
- Author: Bungay Stanier, Michael.
- Publisher: Page Two
- Pages: 244
- Publication Date: 2016-02-29
- Edition: 1
| Function | System the lead owns | Example measure |
|---|---|---|
| QA | Regression suite and release gate | Regression-suite currency and escaped-defect trend |
| Infrastructure | Alerting, runbooks, incident response | Recovery time and response to alerts |
| Backend | Service reliability practice | SLOs and error-budget burn |
| Mobile | Client stability | Crash-free behavior and ANRs |
Setting thresholds and handling long targets
Thresholds should be drawn from current data, not from aspirational numbers chosen in a meeting. Fattakhov’s advice is to look at the baseline first, agree on what a reasonable threshold would be given that baseline, and only then write it down.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchSome targets take several quarters. For those, he recommends treating the final goal as a horizon and judging progress by a feasible next step. If an existing threshold cannot reasonably be reached within a month, the review should track movement toward it instead of recording a failure against a bar that was never reachable in that period.
Rolling it out and running the monthly review
The author’s rollout advice follows a sequence:
- Prepare the leads for the process before asking them to be measured by it.
- Bring a framework, not a finished scorecard, so the leads can shape the measures.
- Discuss each threshold using actual data from the live systems.
- Hold the review monthly, and treat it as a conversation rather than a verdict.
- When a measure is red, ask “what’s in the way?” instead of issuing an automatic reprimand.
The red-metric question does most of the work here. A red result is information about the system, and the useful next step is to find the constraint: a missing alert, a tooling gap, a dependency on another team, or a deadline that crowded out maintenance.
Bonuses: wait a quarter or two
Fattakhov cautions against tying these measures to bonuses right away. His recommendation is to let the process run for a quarter or two first, so participants build a rhythm and come to trust the numbers before money depends on them. This is his advice from one project, not a general compensation rule, and the article does not show what happens when bonuses are linked sooner.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How this compares with OKRs, health checks and written expectations
The article places three alternatives beside this approach. It positions them by purpose, formality, team size, and the cost of getting it wrong, and it notes that the monthly-improvement part of the method can resemble OKRs.
| Approach | Purpose stated in the article | Where the author suggests it fits |
|---|---|---|
| Standing and monthly KPIs (this approach) | Ongoing system health plus a few time-limited improvements | Multi-team organizations that need visibility and clear ownership, with thresholds set from data |
| OKRs | Ambitious, directional goals | Setting direction; the monthly-improvement portion can be OKR-like |
| Team health checks | Periodic, softer self-assessment across areas such as code, deployment, tests, and team mood | Regular team-level reflection rather than accountability for a number |
| Informal written expectations | Clarifying what is expected of each person | Small teams with strong trust, where a formal KPI system may not yet be needed |
The article does not provide a controlled comparison, and it does not claim that any one of these frameworks is superior in general. Team size and the cost of failure are the author’s suggested distinctions, and they are the most useful way to choose between them.
Best Value
- Author: Gordon, Jon.
- Publisher: Wiley
- Pages: 192
- Publication Date: 2007
- Edition: 1
What the evidence does and does not show
The account is one practitioner’s experience with one game-development project of six teams. The original problem, as Fattakhov describes it, included crashes and ANRs receiving insufficient attention because nobody owned them clearly. After the lead role took that ownership, QA took part more consistently in release decisions and postmortems, and responsibility became easier to see. These are reported observations. The article offers no baseline figures, no comparison group, and no independent verification, so it cannot establish a causal effect of the approach.
The useful takeaway is the structure: narrow each lead’s accountability to a system they can influence, keep the measure list short, ground thresholds in live data, and make the monthly review a diagnosis of obstacles. Whether the same results appear in another organization is a question that a team would have to answer by running the process and measuring its own outcomes.
Fattakhov’s article, KPIs That Don’t Turn Into a Stick, is the primary source for the approach and its examples.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
