You now have several teams, each with a lead, and you want the system to run predictably — without diving into every team every day. The first reflex is to "hand out KPIs." And that is exactly the place where it's easy to ruin everything.
It all breaks against one regularity the economist Charles Goodhart formulated half a century ago: once a metric becomes a target, it stops being a good metric. Not because people are dishonest, but because you can almost always work on the number directly — bypassing the thing it was introduced for. Give every lead a share of uptime and you'll get cautious releases and arguments about whose incident it was, not a more reliable product.
What follows is how I built KPIs for team leads on a gamedev project with six teams while working around that trap. The main question there turned out to be not "which metrics do we take" but "what is a lead responsible for in the first place."
This is a spin-off of the "How to bring order to a project" series — this time about management.
How it started
Six teams: the mobile client, the launcher, the game server and the rest. At the C-level we wanted transparency — to see how things were going without climbing into every team daily.
But there was also a concrete trigger, not just manageability in general. In several teams, churn was eating the focus on the things that never look urgent: ANRs and crashes. Nobody worked on them deliberately — not because they couldn't, but because it was nobody's zone. A feature has a deadline and an owner; a stability number has neither. So beyond transparency, the KPIs had to place responsibility: not "who's to blame for the crash," but "whose zone of attention is this at all."
The starting point was the CTO's own KPI. It already existed — put together quickly, but it existed, and that turned out to matter more than the precision of the wording: there was a single outcome everyone worked toward. The mistake would have been to slice it into shares and hand them down — more on that trap below. What was valuable was something else: it set a direction, and from there you had to answer your own question — what is this particular lead responsible for within that direction.
Why the C-level wants this — honestly
The motivation from the top usually sounds like "transparency and manageability," but it's worth unpacking all the way:
- Seeing the state of the teams without micromanagement. Not "what is everyone busy with" but "is the system healthy" — and noticing degradation before an incident.
- Predictability. Promises to the business rest on something measurable, not on a feeling that "it seems fine."
- Scaling yourself. A CTO with six teams physically cannot be the entry point to every decision — lead KPIs are a way to delegate responsibility, not tasks.
And right here is the honest trap you have to see in advance: the easiest way to "decompose the CTO's KPI" is to cut it into pieces and hand them down. The CTO's goal is "uptime and product quality" — so give each lead a share of uptime. It looks logical and works badly: the lead gets a metric they only partly influence, starts optimizing the number instead of the system, and defends themselves with reports instead of doing the work.
What the leads think about it
Leads have their own set of motivations — and fears, and ignoring them is the most expensive option of all:
What a lead gets from honest KPIs:
- clarity: "what is expected of me" stops being telepathy — these are literally the expectations spoken out loud from the people track, only at the level of roles;
- protection: written criteria are insurance against arbitrary evaluation "by mood" and against rules changed after the fact;
- arguments: "we need one more person" sounds weak; "we won't hold the stated recovery time without a second on-call" sounds strong.
What a lead is afraid of:
- that the metrics will become a stick: any red number is grounds for an inquest;
- that they'll have to work "for the number": producing reporting instead of value;
- that the goals will be set above their head — from a world where their teams don't exist.
Everything below is, in essence, an answer to those fears.
The key turn: a lead owns the system, not the outcome
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.
CTO KPI → processes → team → outcome
The outcome is a consequence of a working system, not the subject of a monthly evaluation. The QA lead doesn't own "zero bugs in production" — they own the regression suite being current, a verdict existing before a release, and defects that escaped to production being reviewed so they close the hole in the system. The infra lead doesn't own "zero incidents" — they own alerts being meaningful, runbooks existing, and MTTR going down.
And this is the answer to the question "how do I make everyone work on product quality rather than on the CTO's KPI": don't translate the outcome downward — ask about the health of the system that produces that outcome. You can "work on" an outcome number in a report; you can't do that to a working system — it either exists or it doesn't.
The evaluation is then phrased through the system as well, in three levels:
- Good — the system works and is developing; the outcome is a stable consequence of it.
- Satisfactory — the system exists but has gaps: coverage is incomplete, it runs irregularly.
- Unsatisfactory — there is no system; the work is reactive, held together by manual labor and heroics.
Notice: "unsatisfactory" is not "bad numbers," it's "no system." The difference is fundamental — and it takes the fear of the stick away.
The construction: standing KPIs plus KPIs of the month
The second finding that made life much easier was to split KPIs into two kinds:
- Standing (S) — the hygiene of the role: the same bar every month. Monitoring covers the services, the regression suite is current, RCAs get written for incidents, releases go through a verdict. They don't change, they aren't renegotiated — they simply have to be met.
- KPIs of the month (M) — three or four goals set for the month: close a specific piece of tech debt, raise feature coverage, lower MTTR, run a Game Day. They live for one cycle and are set anew at the monthly review.
The standing ones give stability ("what normal means"), the monthly ones give movement ("what we're improving right now"). Without S, monthly goals turn into firefighting; without M, standing ones turn into stagnation.
Metrics: ground them in facts, not in wishes
The selection rules I arrived at:
- A metric has to be readable from a live system — from monitoring, the tracker, the app store. A metric the lead counts by hand at the end of the month will be dead within a quarter.
- Thresholds are set from facts, not from dreams. Before writing down a response-time threshold, I pulled the real percentiles out of monitoring. It turned out that almost all the services were already inside the corridor and one stood out — and the threshold became honest: "pull up the outlier," not "everyone improve everything." A threshold taken from thin air demotivates worse than no threshold at all.
- Few metrics. Three or four standing plus three or four monthly per team is the ceiling. Past that, the evaluation system costs more than it's worth.
- Examples of "system → its metrics" pairs by domain: QA — the currency of the regression suite and the trend of defects escaping to production; infrastructure — recovery time and the share of alerts that actually get a response (an alert everyone ignores does more harm than no alert at all); backend — SLOs and error-budget burn; the mobile client — crash-free and ANR, whose thresholds the app store sets for you.
The stabilization pattern: when the goal is far away
The most common reason KPIs "don't land": the goal is objectively unreachable this month. Between the current availability level and the target one there isn't a step but several quarters of work. Making the target level the monthly bar means condemning the lead to an "unsatisfactory" — and to cynicism.
The pattern that works is burn-down plus a ladder toward the horizon:
- the absolute goal is a reference point, not a monthly bar: it's honestly written down as the horizon;
- the monthly bar is a step: noticeably reduce the number of errors, close their main source, climb one rung of the ladder you laid out from the current level to the horizon;
- what gets evaluated is the step: taken — "good," even if the horizon is still far away.
This is also the answer to "how do we agree": the conversation with the lead stops being a haggle about the unreachable and becomes planning for the next rung.
How to present it and how to agree
The procedural part is short, but everything depends on it:
- Warn in advance. The leads knew from ordinary conversations, long before the first card, that KPIs were being prepared and that we'd sit down to discuss them soon. It's a cheap step that removes half the tension: the system doesn't fall on them as a surprise, it arrives at an expected moment.
- Don't hand down a finished thing. The frame (S/M, the levels, the pattern) is brought by the CTO; filling the card in is the subject of a conversation with the lead. Thresholds are discussed from the actual numbers, out loud, one on one. This is exactly the spoken expectations, in both directions — the lead also says what they need in order for the system to work.
- The CTO sets the goals of the month — the final word is theirs, this isn't a democracy; but goals set without a conversation don't work.
- A monthly review — by the card, half an hour: how the standing ones are doing, what happened to the goals of the month, what we set for the next one. A red metric is grounds for the question "what's in the way," not for a reprimand. One or two cycles in that mode and the fear of the stick goes away.
- Be careful with money. Tying this to a bonus from the first month breaks the whole construction: a metric that has become money stops being a measurement instantly — that's the same Goodhart from the opening, only in his fastest form. First a quarter or two of simply keeping the rhythm and building trust in the numbers.
What came out of it
Not once did I hear a flat "no." That doesn't mean the cards were accepted in silence: every item was worked through one on one — and not once at launch, but continuously, at every review. That is the central point of the process itself: not to hand it down and forget it, but to talk and to agree until the person has their own understanding of why the metric is there. The absence of loud resistance is the result of those conversations, not a sign that nobody cared.
There were corrections along the way, and always of one kind. Either a wording that could be read two ways, or a number that couldn't be reached this month. The first ones we rewrote. The second we replaced with tracking a trend: not "hold the threshold" but "move toward it" — with a check at the next review. Not once did we have to throw a metric out entirely: the argument was always about the threshold, never about the meaning.
What changed noticeably:
- ANRs and crashes became the leads' concern, not the CTO's. Exactly what the whole thing was started for: the tracking settled on the teams' side — the lead looks at the numbers and arrives with a plan, instead of waiting for a question from above;
- QA stopped needing to be pulled in by hand. Before, the lead had to be prodded both about the release process and about taking part in postmortems. Once the cards existed, the lead and the team started joining in on their own;
- responsibility stopped being a matter of guesswork. It became visible who owns what — and that understanding became shared, rather than living "in the CTO's head".
I don't have a case where the scheme wouldn't fit. There is a condition without which it doesn't work: agreeing in a way that leaves everyone understanding the goal. Without that, the cards turn into work for the sake of work — and it won't be the scheme's fault.
Alternatives — and when they're better
An honest section: lead KPIs are not the only instrument.
- OKRs — if the task is not "keep the system healthy" but "move toward ambitious goals": inspiring objectives, measurable key results, 70% attainment is normal. Weaker for hygiene, stronger for pushes. Nothing stops you from combining them: the S part as KPIs, the M part in the spirit of OKRs.
- Team health checks (a regular self-assessment against a checklist: code, deployment, tests, mood) — softer, without thresholds, good as a quarterly reflection. Not enough if the C-level needs manageability.
- Just agreeing on expectations without numbers — works in a small team with strong trust; stops working roughly when there are more than three leads and "keeping it in your head" no longer works.
The choice is simple: the more teams you have and the more expensive failures are, the closer you move to a formal system. But it's always worth starting with the conversation about expectations; KPIs are its written form, not a replacement for it.
Checklist
⬜ The lead owns the system, not the outcome; the outcome is a consequence
⬜ The frame: standing KPIs (hygiene) plus three or four goals of the month; a monthly review
⬜ Three levels of evaluation, through the maturity of the system, not through "red numbers"
⬜ Metrics are read from live systems, thresholds are grounded in facts
⬜ A distant goal is the horizon; the monthly bar is a step (burn-down / one rung)
⬜ The frame is brought by the CTO, the content is a conversation with the lead from actual numbers
⬜ A red metric is the question "what's in the way," not a reprimand
⬜ A number that's unreachable this month is replaced by a trend, not by an "unsatisfactory"
⬜ Don't tie money to the metrics until the system has lived through a couple of quarters
