How to report engineering ROI to the board

Owning the delivery system is one of the four key areas of engineering management. Reporting engineering ROI to the board means translating cost and delivery data into a single number the board already thinks in, tied plainly to what it bought. Skip the dashboard. Lead with the number, then the plain-language reason behind it, then the trend.

You need three things in place before this conversation goes well: a cost figure that blends people and AI spend (not just token spend), a delivery number that reflects merged work rather than raw activity, and a plain-language translation layer between the two, because handing a board a metrics dashboard and expecting them to parse it is where this usually fails.

Yishai Beeri, CTO at LinearB, has watched this shift happen inside his own company's board conversations over the past year.

"Finance is not just in the room, they came in late, they kicked the door in, frantically trying to get on top of what's happening."

— Yishai Beeri, CTO at LinearB, on Dev Interrupted, The playbook to close your team's AI productivity gap

That's the posture to prepare for. The question the board is asking has shifted from whether to allow AI spend to whether it's returning more than it costs.

Adoption percentage is the number every team defaults to first, and it's the number a board is least equipped to act on. It says the tool is installed. It says nothing about return.

Beeri's own approach is to open with a single blended figure instead: cost per pull request, human and AI spend combined, divided by merged output.

"If I'm looking at my overall, what's the team doing? And you're saying, 'Okay, I have different groups in my organization, and the cost per PR is dramatically different in those, the trend is not going in the right way,' I know where to focus."

— Yishai Beeri, CTO at LinearB, on Dev Interrupted, The playbook to close your team's AI productivity gap

This is the number a board can hold a trend line against quarter over quarter, the same way they already track cost per acquisition or cost per deal. It answers "is this working" in the vocabulary the room already speaks.

Boards default to thinking about spend as a single line that either grows or shrinks. Beeri's framing treats it instead as a portfolio allocated by proven return, which is a more defensible story and closer to how the board already thinks about other budget lines.

"If I'm getting great leverage, by all means, let's spend more. Every dollar I put into the tokens, my developers are blocked, let me unblock them, give them more budget, because they are showing me that this translates into many dollars in value... If my leverage is poor... it's positive, but I have other investments that are better."

— Yishai Beeri, CTO at LinearB, on Dev Interrupted, The playbook to close your team's AI productivity gap

Presenting the number this way turns a defensive "here's what we spent" conversation into an active "here's where we're reallocating and why" conversation, which is a materially easier position to hold in the room.

This is the step most engineering leaders skip, and it's the one that determines whether the board trusts the number at all. Nik Sudan, engineering operations lead at Kraken, has run this translation exercise repeatedly with non-technical stakeholders and is direct about why it's non-negotiable.

"You can't just throw metrics at people and expect them to understand them. If they don't understand it, they don't trust it, and that's completely worthless."

— Nik Sudan, engineering operations lead at Kraken, on Dev Interrupted, How Kraken finds hidden bottlenecks across thousands of engineers

His method is concrete: define the term in one plain sentence before showing the number attached to it. Describe cycle time as how long it takes to ship something in front of a client, where a lower number means faster project execution, before ever showing the labeled bar on a chart. Do that translation once, in advance, rather than fielding clarifying questions live in the meeting.

A red metric with no explanation reads as a problem. A red metric with a stated cause reads as a team that understands its own operation, which is a very different impression to leave a board with.

"Don't just stop with a diagnosis. Call out specific areas that may need improvement, so you can give actions and insights rather than it being red light."

— Nik Sudan, engineering operations lead at Kraken, on Dev Interrupted, How Kraken finds hidden bottlenecks across thousands of engineers

Pair every metric you present with the one-sentence reason behind its current state and the specific investment that would move it. That combination is what secures budget for the things a board would otherwise wave off as routine engineering upkeep.

You'll know this approach is landing when the board's questions shift from asking what a number means to asking what it would take to improve it. That shift, from clarification to investment, is the signal that the translation layer did its job and the room trusts the data enough to act on it.

Two failure patterns show up repeatedly. The first is leading with adoption or token-spend totals, which invites the exact "prove it's working" pushback this whole approach is built to avoid. The second is comparing teams or individuals against each other on a shared leaderboard rather than against their own baseline, which Sudan warns against directly, because it reads as judgment rather than diagnosis and erodes the trust the rest of the method depends on.

What's the single most important number for a board conversation?

Cost per PR, blending human and AI spend against merged output. It's the number that maps most directly onto how boards already evaluate other spend, and it's defensible on a trend line.

How much preparation does the translation step actually take?

Less than it sounds like. Write a one-sentence plain-language definition for each metric you're presenting, in advance, and rehearse pairing it with the number. The investment is in doing it before the meeting, not during it.

Should engineering metrics ever be compared across teams for a board audience?

No. Benchmark each team or group against its own baseline. A cross-team leaderboard invites the board to draw conclusions about people rather than about the investment, which is a worse outcome for everyone in the room.