Slide 01

You Have AI Usage Data for Every Engineer. You Just Have Not Looked at It.

VP Eng + CTO + Board

Core claim

A VP of Engineering asked his CEO "who are your top people?" He had velocity metrics. PR counts. IDE hours. He had all of it. And he still couldn't answer. Then someone asked: have you looked at AI usage by engineer? Silence. "We have that data?"

You have that data. Every major AI platform you are paying for generates usage telemetry: request volume, active days, session depth, completion acceptance rates. Pull it up. Sort by usage descending. The people with the deepest usage — having real conversations with the model about architecture, iterating on prompts, using the tools as actual tools — those are probably your best people. This is not a surprise once you see it.

The real signal The interesting number is not at the top of the list. It is at the bottom. Scroll down. Find the senior engineers — principals, staff, architects — showing almost no usage. That is the conversation that matters.

Slide 02

High Usage Confirms What You Already Suspected. Low Usage from Senior Engineers Is the Signal.

Data interpretation

Top of the list

Deep usage usually means real work. Real conversations about architecture. Prompt iteration. Tools used as tools — not as novelties or productivity theater.
You probably already know who these people are. The data confirms what you suspected. These are the engineers who sit down and do the work. The AI is just where that work happens now.
The exception: High usage with nothing shipped is still nothing shipped. Some people run up usage translating memos, regenerating functions without committing, exploring without producing. That has always been true. Check output alongside usage.

Bottom of the list

Senior engineers with near-zero usage are the signal that matters. Principals. Staff engineers. Architects. Tenured mid-levels. Find their names. They are the conversation you need to have.
Two explanations only: They are blocked. Or they are not engaging. You need to know which one before you do anything else.
The order matters: Check access first. Then have the conversation. Getting the order wrong is a management failure — you question someone's performance when the real problem is an unresolved IT ticket from October.

Slide 03

Before Any Conversation: Pull the Ticket. Three Months Waiting for an IAM Role Is Not Low Performance.

Access friction

The embarrassing default state

In 2026, access friction around AI tooling is not a theory. It is the default state at a remarkable number of organizations that believe they have deployed these tools.

Security reviews that take six weeks. Procurement cycles that approve one vendor and stall the rest for a quarter. IT tickets for API key provisioning that sit unacknowledged for two weeks. Data classification policies written vaguely enough that cautious engineers apply them to everything just to stay out of trouble.

Real example A director — seven years at a recognizable company, excellent track record — spent three months waiting for an IAM role. The request needed a manager approval, which needed a VP co-sign because the budget code touched production infrastructure. Usage: zero. Would have looked damning in a report.

What to do first

Before you have any performance conversation with a low-usage senior engineer, pull the ticket. Trace the access request. Find where it stopped.

You may find that the person you were about to question has been waiting longer than you have been watching the dashboard. If that is what happened — fix it immediately. Treat it like a production incident. Because it is one.

Then have the awkward conversation about the unblocked senior engineer who is still not using the tools. Not before. The order is not optional.

The fix If access is the issue, resolve it the same day. Document what created the delay. Fix the process so it does not recur. Then check back in 30 days.

Slide 04

The Senior Engineer With Access, Time, and Training Who Is Still Not Engaging

The harder conversation

Why they are not engaging

Some are scared. Some have been told so many times that their expertise is their identity that picking up a new tool feels like admitting the old identity is not enough.

Some watched a junior engineer produce something fast and mediocre with AI and decided they would rather be slow and correct. Nobody has shown them yet that this trade-off is no longer available at the price they think it is. Those are rational responses to real pressures. Treat them that way.

How to approach it Do not come in with a performance frame. Come in with curiosity. What are you working on? How are you getting it done? Have you tried using an agent for this kind of problem? Let me show you what it looks like when someone does.

When empathy runs out

If someone has had access, has had the time, has been shown how it works, has watched peers shipping at two to three times their previous pace — and is still not engaging — that is a judgment problem.

The question is not whether to punish them. The question is whether to invest in them — and what timeline you are willing to hold. The engineers who have internalized this way of working are the core of what your engineering organization looks like from here forward. The ones who have not are falling behind in a measurable, compounding way.

The hard truth You are not doing them any favors by letting a year go by before you have this conversation. The compounding is not pausing while you wait to feel ready.

Slide 05

The Engineers Who Have Adapted Are Compounding. The Ones Who Have Not Are Falling Behind in a Measurable Way.

The stakes

The adapter 2–3×

Engineers who have genuinely internalized agent-driven workflows are shipping at 2–3x their previous pace. That is not a ceiling — the tooling and their skill with it are both still improving. The compounding is in their favor.

The non-adapter Flat

Engineers who are not using the tools are not standing still relative to a static bar. They are falling behind relative to a rising one. Their peers are faster. Their output looks smaller by comparison every quarter.

Your org Bifurcated

If you have not looked at the usage data, you may not know that your org is already split into two groups operating at very different velocities. That split is visible to your engineers before it is visible to you.

It is not showing up in the usage data in a theoretical way. It is showing up in the output data. And eventually in the business. You are not doing them any favors by letting a year go by before you have this conversation.

The compounding gap between adapters and non-adapters is measurable now and growing

Slide 06

Pull the Usage Data. Today. Not Next Quarter. The Conversation You Are Avoiding Is Getting More Expensive Every Week.

Decision close

What you do this week

The VP of Engineering who could not answer his CEO's question had the data. He had not looked at it. You have the data too. The question is whether you are willing to act on what it shows you.

Pull the usage data. Sort two ways. Find the surprises. For each low-usage senior engineer: pull the access ticket first. If they are blocked, treat it like a production incident. Fix it the same day. If they have access and are not engaging, have the conversation this month. Do not wait for the next performance cycle.

The pairing approach works: two engineers on a real problem, one who reaches for the agent naturally. No training theater. No adoption dashboards. Just one engineer showing another what the work looks like now.