Direct answer: Attribute AI usage to workflows and outcomes, which patterns succeed, spread, and save time, and show each engineer their own numbers before anything rolls up to a manager. The direction of the data flow decides whether a team trusts the tool. When individuals see themselves first and managers see only aggregates and workflow adoption, engineers keep their real work inside the system. When managers get a person-level view engineers never saw, the good ones move their work somewhere the dashboard cannot reach, and your data goes dark within a month.
The fastest way to kill AI adoption on an engineering team is to turn a visibility tool into a monitoring tool. I have watched it happen. A leader gets a dashboard that can attribute AI usage down to the individual, points it at their engineers like a stopwatch, and within a month the strongest people have quietly moved their real work somewhere the dashboard cannot see. The data the leader was proud of collecting becomes a record of the least interesting usage on the team.
This one is solvable, but only with precision about what you measure and, more importantly, about who sees it first. The usual advice, measure the work and not the person, is true and nearly useless, because the same telemetry serves both and the failure hides in the direction you point it.
Consider the two objects a measurement can attach to. One is the workflow: a repeated way of getting a task done, like a migration agent or a code-review loop, carrying a cost, a success rate, and a set of people who use it. The other is the person: an individual with hours, activity levels, and a rank against peers. On a dashboard they look almost the same. In their effect on a team's trust they diverge completely.
Attach the measurement to the workflow and the thing under evaluation is the work. The migration workflow costs a certain amount, succeeds most of the time, and has been adopted by six teams. An engineer reading that feels credited, because the object of the number is the thing they built, and wide adoption is a point in their favor. Attach the same measurement to the person and the object becomes the human, so the identical telemetry now reads as a stopwatch, and the engineer who felt credited a moment ago feels watched.
The technical reality is where good intentions usually break, so it is worth stating plainly. The telemetry is identical in both cases. Every AI request carries a session, a model, a token count, a cost, a duration, a status, and a consumer. Touching individual-level data is unavoidable, because an individual is who made each request. The lever that decides everything sits downstream of collection, in what you compute from that data and the order in which people see it.
The honest implementation computes person-level data and surfaces it to that person before anyone else. An engineer sees their own workflows, their own savings, their own first-try rate, ahead of any rollup. What reaches a manager is workflow adoption and team-level pattern, with no leaderboard of humans ranked by activity. The individual holds the full detail on themselves. The manager holds the shape of the team's work. That asymmetry is the design, and it is the whole thing that keeps a tool on the trusted side of the line.
One view must never get built, precisely because the data makes it trivial: the surveillance view. Hours logged, keystrokes, an activity percentile implying one engineer works harder than another for making more model calls. Request volume is a terrible proxy for output. Four thoughtful requests that ship a migration beat forty that ship nothing, and any metric treating call count as productivity will punish exactly the people you most want to keep. The same limit applies to a completed status, which proves a task finished and says nothing about whether the answer was good. Telemetry records what happened, not whether it mattered, and a tool that pretends otherwise loses the room the first time an engineer catches it doing so.
So the rule I hold to is short to state and demanding to keep. Attribute everything to workflows and outcomes. Show individuals their own data first. Give managers aggregates and adoption, never a ranked list of people. And refuse the hour-counting view however easy it is to build, because the first engineer who sees it will reread every number you have ever shown them in the worst possible light, and they will be justified.
We designed Oberhahn around that asymmetry: individual-first for the person, workflow-and-adoption for the manager, and no individual-hour surveillance anywhere in the product. You can see how the two views differ in a live demo with sample data.
Frequently Asked Questions
How do I measure AI impact without surveilling my engineers?
Attribute usage to workflows and outcomes rather than to individuals' hours or activity. Show each engineer their own data first, and roll up to managers only as team-level patterns and workflow adoption, never a ranked list of people.
Can I track individual AI usage without hurting trust?
Yes, if the individual sees their own data first and it is framed around the work they built, not their activity level. Trust breaks when the same data is turned into a manager-facing leaderboard of people.
Why is measuring request volume a bad idea?
Request volume is a weak proxy for output. An engineer who made four requests and shipped a feature did more than one who made forty and shipped nothing, so volume-based metrics end up punishing thoughtful usage and rewarding noise.
What should roll up to a manager versus stay with the engineer?
The engineer sees full individual detail: their workflows, savings, and success rates. The manager sees team-level aggregates and which workflows are being adopted, not individual activity rankings.