Direct answer: Individual AI metrics roll up by changing the unit of measurement on the way up. The individual view keeps the person as the unit, showing an engineer their own savings, first-try rate, and reuse. The team view drops the person and keeps only workflows and adoption counts, letting a manager see how the work is going without ranking people.
The phrase "roll up" hides a decision that most measurement tools make badly, and the decision determines whether a team trusts the tool or quietly abandons it. Rolling up sounds like arithmetic, as if the team view were just the individual numbers added together. What actually happens is a change of subject. The individual view and the team view are about two different things, and the whole art of an honest rollup is knowing which parts are allowed to make the trip upward and which parts must be left behind.
What turns a rollup into a surveillance scoreboard?
I want to be precise about the failure, because it is subtle and extremely common. The instinct, when building a team view, is to take the individual metrics and aggregate them per person: here is each engineer's savings, first-try rate, and reuse, sorted. That produces a ranked list of humans, and a ranked list of humans is a surveillance scoreboard no matter how gently it is labeled. The failure is not that the numbers are wrong. The numbers are accurate. The failure is that the person survived the trip up, and once the person is the unit at the team level, every engineer who sees it rereads their own individual view as the raw material for a ranking they never agreed to.
So the rule that keeps a rollup honest is a rule about what the unit is at each altitude. Call it unit substitution. At the individual altitude, the unit is the person, and the person is the audience, so the two match and it is safe. At the team altitude, the unit must become the workflow, and the audience becomes the manager, and those two also match. The moment you carry the person up to the team altitude, the unit and the audience come apart, and that gap is exactly where trust dies. Getting the rollup right is getting the unit substitution right, and almost nothing else.
What does the engineer see at the individual altitude?
Start at the individual altitude, because everything upward depends on it being solid. An engineer sees their own data first and in full: their workflows, their savings against genuinely billed events, their first-try rate, their reuse counts. This view is rich and person-shaped on purpose, because the person is looking at themselves, and there is nothing invasive about seeing your own work. The telemetry underneath is per-request and per-person by necessity, because an individual is who made each request. Collecting person-level data was never the problem. The problem only ever appears in what gets computed from it and who sees the result.
What changes when the metrics move up to the team view?
Now perform the substitution on the way up, and watch what has to change. The individual's workflows become the team's workflows, no longer tagged to who ran them but to how many distinct people ran them. The individual's savings become the workflow's savings, summed across everyone who adopted the pattern, with the names dropped. The individual's reuse count becomes the pattern's adoption count. Every metric that was person-shaped downstairs arrives upstairs shaped like a workflow, and the person, as a unit, does not make the trip. The manager ends up with a true picture of how the team's work is going and no ability to rank one engineer against another, because the raw material for that ranking was left on the floor by design.
There is a specific thing the team view must never reconstruct, precisely because the data would allow it. Do not aggregate a completed-status count per person, do not aggregate request volume per person, do not build an activity percentile that implies one engineer works harder for making more model calls. A completed status means a session finished, not that the answer was good, so a per-person completion tally measures busyness and calls it output. Request volume is a weak proxy for anything. These are the metrics that are trivial to compute and destroy the tool the first time an engineer catches them ranking people, so the discipline is to refuse to build them even though the data makes them easy.
Why is the workflow view what a manager actually needs?
The reason this asymmetry is the right answer, and not merely a reluctant concession to privacy, is worth stating plainly. A manager does not need to know which engineer is the best AI user. That is not a real management need, and pretending it is produces a metric that is both invasive and useless, because the answer would be built on completion counts and call volume that measure the wrong thing anyway. What a manager genuinely needs is which workflows are working, which are spreading, and where the team's AI effort is actually paying off. Every one of those questions is answered at the workflow altitude, with no person as the unit, which is why the honest rollup and the useful rollup turn out to be the same rollup.
So the bridge from individual to team, concretely, is the same underlying telemetry read at a different altitude, with the person as unit downstairs and the workflow as unit upstairs, and the individual always seeing their own full detail before anything aggregates. A wider version of the individual view is exactly what it must avoid being. Keep the substitution clean and the manager gets a real picture while every engineer keeps their trust. Break it, carry the person upward, and you have built a scoreboard that will empty your data within a month as the strongest people move their real work somewhere it cannot reach.
Oberhahn is built on that substitution: individual-first and person-shaped for the engineer, workflow-and-adoption-shaped for the manager, and no per-person ranking anywhere in the product. A live demo with sample data shows how the two altitudes differ.
Frequently Asked Questions
How do individual AI metrics roll up to a team view?
By changing the unit of measurement on the way up. Individual metrics are person-shaped for the engineer looking at their own work. The team view keeps only workflows and adoption counts, with the person dropped as a unit, so a manager sees how the work is going without a ranking of people.
Does rolling up individual metrics create a surveillance scoreboard?
Only if the person survives the trip up. Aggregating metrics per person produces a ranked list of humans regardless of how it is labeled. Aggregating them per workflow, with names dropped, gives a manager a true picture without any ability to rank engineers against each other.
What does the manager see versus what the engineer sees?
The engineer sees their own full detail first: their workflows, savings, first-try rate, and reuse. The manager sees team-level workflows and adoption counts, never a per-person leaderboard, completed-status tally, or activity percentile.
Why not just show managers each engineer's AI numbers?
Because a manager does not actually need to know which engineer is the best AI user, and building that view relies on completion counts and request volume that measure busyness rather than output. The genuinely useful questions, which workflows work and spread, are all answered at the workflow level.