Developer productivity for a VP of engineering is a distribution problem

A VP of engineering doesn't have an individual productivity problem to solve. The fastest engineers in the organization are already fast, and getting faster. The VP's problem is that their gains don't spread, and the organization's delivery number stays flat while a handful of people pull ahead. Everything a VP can actually do about developer productivity is a lever on that distribution: the context engineers work in, the guardrails that make AI output trustworthy, the learning structures that stop skills from eroding, and the platform that turns one team's discovery into everyone's default.

That reframing changes what developer productivity means at the VP level. A team lead can raise one team's throughput directly, and that playbook is well understood. A VP's version of the same problem is making the second-best team look like the best one, across twenty teams at once, and the four levers below are the ones that seat controls.

The default VP move is to accelerate engineering: buy the tools, push adoption, report usage. Karthik Ramgopal, Distinguished Engineer at LinkedIn, describes what happens next.

"You have an acceleration in one place because you have built a freeway with N lanes, right? And after that, the freeway suddenly ends, and you get onto a dirt road, and everybody slows down. The freeway doesn't help you."

— Karthik Ramgopal, Distinguished Engineer at LinkedIn, on Dev Interrupted, How to turn your 1000x engineer into a 10x everyone

The dirt road is everything around coding: specs, design docs, operations, product, legal review. Accelerating the engineers alone produces frustration rather than throughput, because the organization's speed is set by its slowest connected function. A VP who measures productivity as coding speed is measuring the freeway and ignoring where it ends.

Every tool a VP buys arrives knowing nothing about the organization: its systems, its conventions, its history of decisions. Ramgopal's team concluded that this, not tool choice, is the constraint.

"At the end of the day, this boils down into a giant context management problem. So we at LinkedIn have invested a lot in recognizing that even as the tools advance, and they will advance, we will continue to get limited by the context we provide them."

— Karthik Ramgopal, Distinguished Engineer at LinkedIn, on Dev Interrupted, How to turn your 1000x engineer into a 10x everyone

The VP-level decision is to treat internal context as infrastructure, exposed through open standards so it survives the next tool change. LinkedIn's platform teams now serve two classes of users, human and agent, and build primitives for both. That's a budget and org-design decision, not something an engineer can make from their seat.

AI output varies from excellent to slop, and the distribution across an organization depends on where the bar sits. Ramgopal states it as a rule rather than a target.

"The quality of the output should very closely resemble, apart from very minor, almost facetious differences, as to what you would have produced had you done the work manually."

— Karthik Ramgopal, Distinguished Engineer at LinkedIn, on Dev Interrupted, How to turn your 1000x engineer into a 10x everyone

Two things make that bar enforceable: evaluations rather than vibes ("vibes aren't reality," in his words), and a rule that engineers use AI only to accelerate work they already know how to do, because you can't judge or validate output you couldn't have produced. Both are organizational policies. Both land on the VP.

The fastest short-term gains come from letting engineers lean on AI for things they don't understand. The cost arrives later, as skill atrophy that no tool compensates for.

"I know there is a lot of push for productivity everywhere, but I keep telling people that learning cannot be sacrificed at the altar of productivity. Durable learning is what really keeps us in the game long term."

— Karthik Ramgopal, Distinguished Engineer at LinkedIn, on Dev Interrupted, How to turn your 1000x engineer into a 10x everyone

LinkedIn's response is structural: deliberately engineered learning moments, channels where asking basic questions is normal, and a reimagined internship model that puts three to five AI-native interns with an experienced tech lead on a hard problem so mentorship runs both ways. A VP who wants the productivity curve to hold in year two has to fund the learning in year one.

Early AI adoption produces wizards: individuals who've built their own context layers, agents and workflows. Ramgopal's advice is to let that run for a while, then consolidate.

"Initially, there is a lot of chaos, and sometimes it's good to let that chaos reign for some time, so that you don't curtail it prematurely, but you see what people come up with. But you cannot let it reign on forever because otherwise you end up creating a lot of tech debt and unmanageable chaos."

— Karthik Ramgopal, Distinguished Engineer at LinkedIn, on Dev Interrupted, How to turn your 1000x engineer into a 10x everyone

The consolidation is a platform that standardizes without curtailing ambition: uniform context access across the systems agents touch, so every wizard stops rebuilding the same integration. The timing is a VP call, and so is the boundary.

A VP needs the distribution, not the average. Three questions to track: the share of teams merging AI-assisted changes at a healthy rate (license counts don't tell you this); whether planning accuracy is holding as volume rises; and whether the gap between the top teams and the rest is narrowing. LinearB's benchmark data shows that gap widening by default; the levers above are what close it.

If the organization is small enough that one team's practice is everyone's practice, the distribution problem doesn't exist yet, and the VP's job is closer to a tech lead's. And if AI adoption hasn't started in earnest, lever four is premature; the chaos has to exist before it can be reined in.

What should a VP of engineering measure for developer productivity?

The distribution across teams, not individual output: share of teams with healthy merge rates on AI-assisted work, planning accuracy as volume rises, and the gap between top and median teams.

Should a VP mandate AI tools?

Mandates move usage, not outcomes. The levers that move outcomes are context, quality enforcement, learning structures and a shared platform.

How do you keep AI from eroding engineering skills?

Make AI an accelerant for work engineers already know how to do, hold output to the bar of what they'd have produced manually, and build explicit learning structures so skill-building stays part of the job.