Daily AI Usage Is Not a Business Result
One team's AI mandate got tied to ARR growth — a number the team doesn't control and that has a dozen other causes. The scoping mistake is common, and easy to catch before the scorecard ships.
Leadership set a target: 80% of developers using AI daily, tracked per team. The consequence for missing it: the product's ARR growth, evaluated per team, tied to the same scorecard.
One developer described this arriving, unprompted, on Reddit: the usage number would be tracked per team, and the reward or punishment for the team would run through ARR growth on the product it owns. If ARR doesn't move — for any of the other reasons ARR doesn't move — that reads as a negative for everyone on the team, regardless of how much of their work is now AI-assisted.
This is one account, from one thread, describing one organisation. It is not a benchmark, and it is not a claim about how most AI mandates work. It is useful anyway, because it names a scoping mistake that is easy to make and expensive to unwind once a team has built its year around the number.
What's wrong with tying AI usage to a business outcome the team doesn't control?
Every mandate logged before this one tied AI usage to a usage metric — logins, acceptance rate, prompts sent. This one ties it to ARR, and ARR has a dozen causes a development team doesn't own: pricing, sales capacity, a competitor who shipped first, a renewal that fell through in a different department, the quarter the market had.
Pin one newly adopted input to an outcome with a dozen other inputs, and the metric stops measuring AI usage. It starts measuring how much of the unrelated noise around ARR happened to move in the team's favour that quarter.
What does a usage mandate need before it ships?
A named, testable link between the behaviour you're asking for and the result you're scoring it against — checked before the scorecard goes out, not after the first quarter comes in short.
Three questions catch this at the design stage, not the postmortem:
- What does the team actually control? If the answer isn't the metric itself, the metric is measuring something else.
- How many other inputs move the same number? ARR, revenue, retention and most business outcomes have several independent causes. Usage of one tool is one input among many.
- What happens if usage goes up and the outcome doesn't move? If the honest answer is "the team gets penalised anyway," the mandate is measuring compliance with a habit, not the result the business actually needs.
What should get measured instead?
The workflow the AI usage was meant to change — named, timed and compared before and after.
If the goal behind "80% daily usage" is that code review takes less time, measure code review time. If it's that incident response gets faster, measure incident response time. If it's that the team ships more without burning out, measure both throughput and the hours going into review and rework. Daily usage can be one input into that picture. It should never stand in for the picture.
The one-sentence version
A usage number tells you a tool got opened. A business result tells you a workflow changed. Confusing the two turns a mandate into a scoreboard nobody on the team can actually move — a scoping problem a five-minute conversation catches before it becomes a quarter's worth of frustration.