Dan Lorenc, Co-Founder and CEO of Chainguard, is creating new norms for AI adoption at his company. We are all seeing early results of AI adoption, but those results are uneven. We thought this was a useful framework that others could benefit from, so asked Dan if we could share it publicly. 

In short, they now expect their engineering managers to be at the 50th percentile of token usage among their direct reports. If they are too low, they lack the context needed to manage and move results forward. If they are too high, they need to focus on mentorship and diffusion of AI tools.

Thank you Dan for sharing your insights, as all companies find their way in this new world.

———- Forwarded message ———
From: Dan Lorenc
Date: Mon, Apr 20, 2026
Subject: A New Token Rule For Engineering Leadership
To: Chainguard Team & Board

Hey All,

We’re seeing real results from AI tooling. But it’s uneven. Some teams and individuals are getting massive leverage; others are barely touching the tools. Closing that gap is one of the highest-leverage things we can do as a leadership team right now. It would probably resolve itself over time, but we can’t afford to wait.

This is a problem every company in the world is trying to solve right now. We’re going to try to solve it by setting a new expectation for engineering leadership: every engineering leader should be right around the 50th percentile of Claude Code token usage among their direct reports. This is a rough guideline, not an exact target. 45th percentile is better than 70th. 55th is better than 30th. All things equal, I’d rather leaders be over than under. The one place you absolutely cannot be is zero.

This starts with me, Dustin, and Matt. We were at the top of usage last month. We don’t want to solve that by slowing down — we want to solve it by helping everyone else catch up. This memo is one step.

Why the 50th percentile?

We know this is a big shift in expectations. But we need to make it now.

Leaders who are well below the 50th percentile don’t have enough firsthand experience with what’s possible. They can’t scope work accurately, can’t set realistic expectations, and can’t coach their teams on these tools. They’re leading a transformation they haven’t experienced themselves.

Leaders who are well above it have a different problem. They’ve found the edge of what’s possible but their team hasn’t. The job isn’t to be the power user — it’s to be the multiplier. Leaders who are way out ahead should spend that energy enabling their teams instead of doing it themselves.

Right around the middle means you understand what the tools can do and your team does too.

This applies everywhere. Engineering is just where we start.

This expectation is true across the entire company. Every leader at every level should have real hands-on experience with the tools their teams use. Engineering is where it’s most urgent and where we can measure it today. Andrea Klemm is working on a plan to help other functions get started quickly — reach out if you’re interested in helping!

Accountability

One of our core values is “We trust each other and assume good intentions.” Any metric can be gamed, and this one is no exception. We believe you and your teams won’t let that happen. Each manager owns the integrity of their team’s usage.

How we measure it

We’re not going to publish a global leaderboard, but every month managers will get a report showing where they fall among their direct reports’ Claude Code token usage. Managers of managers will see the same view for their reports. It’s a blunt instrument and we know that. We’ll improve the measurement over time, but we’re not going to wait for a perfect metric to set the expectation.

Cost

We’re watching this closely. Our Claude bill last month was just a fraction of our cloud spend, and we’re actively working to optimize our agreements with providers. We are not capping usage in engineering in any way. Most tokens right now won’t ship directly into products, and that’s fine — everyone has to pay the tuition to learn these tools. The cost of falling behind is a lot higher than the cost of tokens.

What this isn’t

This isn’t perfect, and we’re not going to micromanage over individual percentage points. We hope this data is the start of a conversation, not the end of one. If you’re consistently way off in either direction, let’s talk about why.

What should I do now?

If you were dramatically below last month, don’t worry — this is a new expectation and we’re not holding you accountable for last month. Reach out and we’ll help you get started.

If you’re not sure where to begin, don’t overthink it. Build a random idea you’ve been sitting on. Grab something from the end of your team’s backlog and just try it. Run a design doc or PRD your team has this quarter through Claude and see what it thinks. The point is to start somewhere.

If you were way ahead, great — work with your peers or your team to show them how you’re working and get them up to speed. This is a shared target and we’ll all benefit.

This isn’t the only change.

This Token Rule is one step. We’re also introducing two new requirements into our product and engineering planning processes. Patrick and Dustin will share more on these, but the short version:

Every product doc now has a section: “What did an LLM say about this document?” Paste it in, see what comes back, include that in the doc.

Every engineering design doc has a section: “What did Claude Code say when you opened it in the repo for this code and pasted this in?” Same idea — let the tool look at your plan in context of the actual codebase and tell you what it thinks.

If you’re not running your plans past these tools before asking humans to review them, you’re leaving easy leverage on the table.