What to include in your CTO board update

At some point, a board member is going to ask you something you don’t have a clear answer to. What’s the company getting from all this AI investment? Why did a competitor ship that feature first?

Deep breath. The answers are usually in your head — you just need a reliable way to translate what you already know into something the board can engage with inside a 20-minute slot.

This article walks through the seven things most software CTOs should cover in a board update, in the order they work best, and what to focus on for each. If you’d rather skip ahead to a deck, download the CTO board deck template here.

What do boards want from engineering?

Boards think in two currencies: risk and investment. Where is capital going, what could go wrong, and what do we plan to do if it does. Luckily, most engineering concepts translate into those two terms naturally with the right framing.

You see, “our test coverage is at 23%” means nothing to a board member unless they’ve got a software engineering background. For anyone without that context, it’s not clear if 23% is good, bad, or something in between. Clearing up that ambiguity with the aim of getting buy-in is your job.

Compare it to this: “We have a high risk of production incidents. It’s already cost us roughly one customer a month this year, and we want to invest 12 developer-months over the next two quarters to fix it.” Everyone in the room can engage with that. It’s the same underlying problem, but two very different conversations (and, potentially, results).

Seven things to include in a CTO board update

Engineering investment: where capacity and cost went
Software capitalization: what was capitalized and what was expensed
AI adoption: use of tools and contribution of AI to the codebase/product
AI impact and ROI: what AI cost and what it bought
Operational excellence: delivery and reliability metrics, each with a rating
Largest deliverables: what shipped and what it took
What’s next: target dates and a conservative forecast

Start with framing, not a slide

Before your first slide, spend a minute on strategy. If your company runs OKRs or high-level goals, report engineering highlights against those, and show the movement if you’ve been tracking the same objectives across quarters.

For your biggest strategic engineering initiatives, connect the work back to those goals: what’s been completed, what’s in progress, what it’s costing, and what you expect it to deliver for the business.

1. Engineering investment

Early in the deck, answer one of the most important questions for the board: where did the engineering budget go?

Break the quarter’s effort into new development, improvements, keeping the lights on (KTLO), productivity work, and everything else — the balance framework is a reasonable starting point. Then present each category three ways: as a percentage of the quarter, as the change since last quarter, and in dollars.

The dollar figures are what make this a board slide. Each category gets a benchmark as well as a value. A traffic light system is usually enough for the slide, but be ready to go deeper: if something moved from green to amber, you should know why, and have a plan.

Low investment in productivity work is good to highlight even when it looks harmless. It usually does look harmless in the quarter it happens, and then it can turn up as KTLO two quarters later. Give the board that context early (notice this advice become a trend in this article) and you’ll be far better off.

Headcount can live somewhere around here too, since it’s the same conversation. Team size and the delta since you last met, plus any structural changes — a reorg, a new platform team, a team split or merged. Boards usually ask about attrition. Report the rate, and separate out the regretted departures — those are the ones that will cost you delivery capacity before anyone notices.

One more thing if you’re scaling: you might hear why are we moving slower when we have more headcount? Adding engineers doesn’t linearly increase output, and the larger a codebase gets, the more capacity gets absorbed by maintenance, incidents, and coordination. As you can imagine, having the investment balance data to back you up can help a lot here.

2. Software capitalization

If your company capitalizes software development costs, the board needs to see how engineering work was classified.

Show the CapEx and non-CapEx split both as a share of the quarter and as FTEs (Full-Time Equivalents).

Align with your finance counterparts on the presentation before the meeting. The board will view this as a finance slide, and it needs to match what they’re seeing elsewhere in the pack.

3. AI adoption

AI adoption lives in your codebase, not in your seat licenses.

Tool usage and weekly active users tell you people are logged in. The board is probably going to ask something more specific: is the AI output good enough to ship? So report the share of merged pull requests authored by cloud agents, the share written by developers with AI assistance, and the share with no AI involvement at all — each with the change since last quarter.

Watch the share with no AI. Once it’s heading toward zero, “are we adopting AI” isn’t an interesting addition to the deck, and the conversation will move to quality of output. And if the cloud agent share has moved, explain what changed: a new agent, a new integration, a new class of task handed over.

4. AI impact and ROI

Before you get into the ROI math, answer the bigger question: is AI actually helping engineering deliver more value?

Adoption by itself isn’t impact. Neither is generating more code. What the board ultimately cares about is whether the investment is translating into faster or better delivery — and, if it isn’t yet, whether you understand why.

Then present the ROI math before someone in the room does it on the fly. Show AI spend next to FTE cost month by month, AI spend as a share of total engineering cost, and cost per engineer per month. You can also consider adding more granular metrics like cost per story, cost per pull request, cost per line, and throughput per engineer, each against last quarter.

Always show the growth rate and the share together. If you’re trying to pull usage and spend across multiple tools into one view, AI adoption and cost is designed for exactly this problem. Early AI spend grows from a tiny base, so a huge percentage jump might look alarming on its own.

No single unit metric tells you much on its own. Read side by side, however, they can tell you what changed. For example, if cost per line falls sharply while cost per story stays flat and throughput per engineer holds steady, that suggests the same amount of work is happening, just in much larger diffs. It’s also why cost per line shouldn’t lead your discussion. Of the four unit metrics, it’s the most variable and the least indicative of value.

5. Operational excellence

Pick a small, consistent set of metrics and show the same ones every quarter.

DORA metrics cover most of it — change lead time, deployment frequency, change failure rate, time to recovery — plus PR cycle time and story cycle time for the parts of delivery DORA doesn’t cover.

Boards ask “is this good?”, not just “what is the number?” A median cycle time with no benchmark will get you exactly one follow-up: compared to what? Which is what the benchmarks are for.

Where you can, translate one metric into business terms. “Change lead time roughly halved, which means a fix for a bug reported on Monday is in production the same week.”

The slide shouldn’t stop at diagnosis, though. If a metric is yellow or red, show what engineering is doing about it, whether that’s reducing change size, removing review bottlenecks, investing in reliability, or shifting capacity toward productivity work for X amount of time.

If you’re deciding which signals belong on the slide in the first place, our guide to engineering metrics for leaders goes deeper into the ones that are useful at the leadership level.

6. Largest deliverables

For each of the quarter’s biggest deliverables, show the share of total engineering effort, the FTE numbers behind them, and the flow efficiency. The first two answer what it cost in terms of effort, and flow efficiency answers whether the team made consistent progress towards the goal.

Flow efficiency deserves a sentence of explanation the first time it appears in front of a board. It’s the share of a work item’s lifetime spent actively being worked on, as opposed to sitting in a queue. A feature that took six weeks at 60% flow efficiency spent over two of those weeks waiting, and waiting is almost always a handoff, review, or dependency problem. So it’s a useful check on “we need more engineers”, because sometimes what you actually need is fewer dependencies.

This slide can be where you talk about what you chose not to build, too, which is arguably one of the more important judgment calls now that building is only getting cheaper.

7. What’s next

Every in-flight deliverable should get two dates: the target, and a conservative forecast. The target is what you committed to, and the forecast is what your throughput data says. When the forecast isn’t looking achievable, the item gets flagged early and you’re the one raising it, which is far better than a board member noticing a slipped deadline at the next quarterly meeting.

End with what you need. Boards exist to guide the organization and to lend their experience and network, so if there’s an ask, put it here:

Tactical things, like introductions and advice. “We’re building an AI agent — do any of your portfolio companies have experience with this?”
Budget and headcount requests. “We can build the X integration and expect to double conversion, but we’d need five additional engineers. Here’s the business case.”

Preparation is the presentation

An underrated benefit of a well-structured board update is all the work that happens before the meeting. Pulling one together forces alignment between the CTO, CPO, and CEO on product bets and engineering priorities. Disagreements that might otherwise go unvoiced tend to surface when you’re all looking at the same slides.

Use the same baseline structure every quarter. Your time with the board is limited and valuable, and they shouldn’t have to reorient themselves to a new format each time. Once they know where to look for what, they start tracking trends on their own and asking better questions — which is what makes the harder conversations easier later, when you need to explain a risky technical bet or make the case for more headcount.

Start early, too. If the first real briefing happens during a crisis, you’re asking the board to understand the problem and act on it in the same meeting.

And one last thing: board members are people, and people are great at going off on tangents. If you don’t control the flow, someone will find a word on a slide and spend your whole 20 minutes on it (taking bets on it being “AI spend” for the foreseeable future).

A clear structure and a specific ask at the end are your best tools for getting something useful to take back to the engineering org.

Here, we put it in a deck for you

Use this template to communicate how your engineering organization is doing — from investment allocation and delivery metrics to AI adoption and team performance.

Download now