Convincing a skeptical VP of Engineering

A VP of Engineering who has been in the job more than three years has personally signed off on a developer productivity tool that did not work. Possibly two. They remember the rollout, the enthusiasm, the six months of adoption effort, and the quiet death when the champion moved teams. They also remember explaining the spend to their own boss afterwards.

So when you arrive with a proposal about the gap between what the team has done and what the board believes, the response you get is not hostility. It is a specific, weary kind of pattern matching: I have seen this shape before, and the shape ended badly.

You are not going to defeat that with enthusiasm. You defeat it by arguing a smaller case than you want to argue, using numbers from their own organisation, and by being the first person in the meeting to name what could go wrong.

What they are actually thinking

Worth being precise about the objections, because the stated one is rarely the real one.

“This is a solution looking for a problem.” They are not sure the drift is bad enough to justify anything. Reasonable, because nobody has measured it.

“We tried this.” They are pattern-matching to a previous tool. Often something adjacent, sometimes something completely different that shared a category label. Until you separate yourself from that memory, everything you say is being heard as a variation on it.

“The team will hate it.” They have burned goodwill on a tooling rollout before and they are not eager to spend more.

“This will become a metrics stick.” Senior engineering leaders are frequently more worried about this than the engineers are, because they have watched what happens when a number reaches a board deck and stops being theirs to contextualise.

“Who owns this in a year?” The most legitimate objection on the list and the one people prepare for least. Every tool they have adopted has an owner who left.

Notice that only the first is about whether the thing works. The other four are about organisational risk. If your pitch is entirely about capability, you have answered one objection in five.

"A solution looking for a problem"They are not sure the drift is bad enough to act on. Reasonable, because nobody measured it.

"We tried this"Pattern matching to a previous tool, sometimes one that only shared a category label.

"The team will hate it"Goodwill already spent on a rollout that went badly. They are not eager to spend more.

"This becomes a metrics stick"Senior leaders worry about this more than engineers do, because they have watched it happen.

"Who owns this in a year?"The most legitimate objection and the least prepared for. Every tool they adopted has an owner who left.

Lead with their numbers, not the category

The single highest-leverage move is to walk in with four numbers from their own organisation, measured before you propose anything.

• Median ticket lag. The gap between the merge of the last pull request referencing a ticket and the transition of that ticket to done.
• Ninetieth percentile ticket lag. The tail, which is where the misleading status reports come from.
• Orphan rate. The share of merged pull requests referencing no ticket at all.
• Criteria quality. The share of active tickets whose acceptance criteria a stranger could evaluate.

These are all derivable from systems they already run, and none of them require a purchase to obtain. That is the point: you are not opening with a product, you are opening with a measurement of their organisation that they did not have.

Median ticket lagLast merge referencing a ticket, to the ticket moving to done.

Ninetieth percentile lagThe tail, which is where the fictions live.

Orphan rateShare of merges attached to nothing in the tracker.

Stale in-progressOldest first. Takes about a minute to produce.

The conversation this produces is qualitatively different. Instead of “here is a category of tool,” it is “a fifth of what your teams merged last month is not attached to anything in your tracker, and your ninetieth percentile ticket lag is six days, which means your monthly report is systematically wrong about your slowest work.” That is a statement about their world. They will either dispute the measurement, which is a productive conversation, or accept it, which means you now share a problem.

If the numbers come back healthy, take that seriously rather than looking for a different framing. Some organisations do not have this problem badly enough to act on, and the article at the end of this series is entirely about that case.

Argue the smaller case

The instinct is to pitch the transformation: the ADLC, the new life cycle, the org-wide change. Do not. The bigger the case you argue, the more objections you invite, and you do not need the big case to get started.

The small case is: one team, ten weeks, no writes for the first fortnight, four numbers measured before and after, and a written decision at the end. The ask is not a commitment to a direction. It is permission to run an experiment with a defined cost and a defined exit.

Three properties make this ask easy to say yes to.

It is cheap in the currency they actually manage. Not licence cost. Attention. Fifteen minutes a week from one tech lead, two weeks of refinement effort that mostly improves things anyway, and one page at the end.

It has a real exit. The decision point is explicit and one of the three options is stop. A VP who has been burned before is mostly afraid of the thing that cannot be stopped, the initiative that acquires momentum and outlives its justification. An experiment with a scheduled decision date removes that fear.

It produces knowledge either way. Even a failed pilot leaves them with a measured baseline of status drift across their org, which is genuinely useful and which they did not have.

The case you want to argue

• The ADLC, the new life cycle
• Org-wide change
• A commitment to a direction
• Invites every objection at once
• No clean exit

The case that gets a yes

• One team, ten weeks
• No writes for the first fortnight
• Four numbers before and after
• A written decision at the end
• Stop is one of the three options

Bring the failure modes yourself

This is the move that changes the temperature of the meeting more than anything else.

Before they raise a risk, raise it. All of them. “Here is what I think could go wrong: the criteria work is the hard part and it is unglamorous, so it tends to get skipped. Teams sometimes decay back to vague criteria a month after the push. There is a real chance the numbers move only slightly and we conclude it was not worth it. And if leadership ever puts individual activity data into a performance conversation, we lose the team and probably the initiative.”

Two things happen. You stop being a salesperson in the room, which changes how everything else you say is weighted. And you preempt the objections rather than defending against them, which means the conversation moves to how to mitigate rather than whether to believe you.

The corollary is that you must not oversell the upside. A VP has heard “forty percent productivity improvement” before and it is now a negative signal. What you can say is narrower and more defensible: the board becomes accurate to within hours instead of days, the ticket admin labour goes down, and status reporting stops requiring a human to reconcile it. Those are mechanical consequences rather than productivity claims, and they are checkable.

The five questions they will ask, and the answers

“What happens when it is wrong?” Every automated write captures the prior value and is revertible, and anything below the configured confidence threshold routes to a human rather than acting. The threshold is a dial you set, and in the pilot the team sets it. Then, crucially: here is the measured disagreement rate from two weeks of shadow mode on our own repositories.

“Will this end up in performance reviews?” The correct answer is a commitment from them, not from you. Turn it around: this only works if the team believes it is not an activity monitor, so I need you to say publicly that this data is never used in individual performance conversations. If they will not say that, you have learned something important and you should probably not proceed.

“How is this different from the last tool?” Two structural differences worth naming. It derives from source control rather than from self-reported data, which means it cannot be gamed by updating a status honestly or dishonestly. And it is reversible by design, so the cost of being wrong is bounded in a way that most tooling is not.

“Who owns this in a year?” Have an answer. Name a person and a team. If you cannot, say so, and propose that finding an owner is a gate on expanding past the pilot. An honest “we do not have that yet and here is how we would resolve it” is far stronger than a vague assurance.

“What does success look like?” Numbers, thresholds and a date, stated before the pilot rather than after. Median ticket lag below some value, orphan rate below some value, and the pilot team choosing to keep it when offered the option to stop. Committing to the success criteria up front is what separates an experiment from an exercise in retroactive justification, and experienced leaders know the difference.

The argument that lands hardest

If you get one sentence, use this one, because it reframes the spend from a productivity bet to a risk position.

Agents have increased the rate at which changes are produced. They have not increased the rate at which anyone updates the record. So the distance between what the organisation has done and what the organisation believes it has done is now growing faster than it used to, and decisions are being made against the belief rather than the reality.

That framing works on senior leaders because their actual job is making decisions on incomplete information, and you are telling them the information is degrading at a rate they have not accounted for. It is not a claim about productivity. It is a claim about the quality of their inputs, which is closer to what they worry about at two in the morning.

Then follow it immediately with the four numbers, so it is not a theory.

Where this breaks down

Some honest limits.

The four numbers can be hard to get cleanly, and a shaky baseline undermines the whole approach. If the organisation recently changed trackers, went through a reorg, or has inconsistent project structures, the measurement will take real effort and may still be contestable. Presenting a number that gets successfully disputed in the meeting is worse than presenting no number, because you have now spent your credibility on a data quality argument. If you cannot get a clean baseline, say so explicitly and propose measuring forward for a month as the first step, which is a smaller and more defensible ask.

Arguing the small case can get you a small yes that goes nowhere. There is a real failure mode where the pilot is approved, runs, succeeds modestly, and then sits there because nobody has the appetite to expand and the sponsor’s attention has moved. The small ask lowers the barrier to starting and it also lowers the stakes, and low stakes attract low follow-through. The mitigation is to agree the expansion criteria before the pilot starts, so that expanding is the default outcome of hitting the numbers rather than a fresh decision requiring fresh energy.

Bringing your own failure modes can go badly with the wrong audience. I have described candour as a strength, and it usually is, but some organisations read acknowledged risk as weakness and reward the confident pitch. If that is genuinely your environment, this advice will cost you. I would still give it, because a rollout won on overclaiming has to keep overclaiming, and that ends worse. But it is a real trade and you should know you are making it.

And a VP may be skeptical because they are right. This is the one worth holding onto. If the organisation’s agent usage is low, if the work does not live in source control, if the teams are small enough that everyone knows what everyone is doing, then the drift problem is a nuisance rather than a threat and the correct decision is not to act. A skeptical VP with a healthy set of numbers has evaluated the proposal correctly. Do not treat that as an obstacle to route around. Treat it as the answer.

The takeaway

Skepticism at this level is earned and mostly organisational rather than technical. Meet it by measuring their world before you propose anything, arguing a ten-week experiment rather than a transformation, naming every failure mode before they do, and asking them, not the team, to make the commitment about performance data.

Commit to success criteria and an expansion trigger before you start, so that the result is a decision rather than an interpretation.

The next piece covers the thing you should be able to describe in that meeting without hesitating: exactly how you would turn all of this off, and what it costs you if you have to.