At some point, a board member is going to ask you something you don’t have a clear answer to. What is the company getting from all the AI investment? Why did a competitor ship that feature first?
Deep breath. The answers are usually in your head — you just need to build a reliable way to translate what you already know into something the board can engage with in the scope of your 20 minute presentation slot.
This article is a loose framework for doing that. I’ll cover what most software CTOs should include in their engineering board update, how to frame it for a business audience, and why consistency matters as much as what’s on the slides.
Boards tend to 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. Most engineering concepts translate into those two terms naturally, but the default for most engineering leaders is to present in technical terms.
The thing is, “Our test coverage is at 23%” means nothing to a board, unless they’ve got a software engineering background. For anyone without that context: is 23% good, bad, or something in between? It’s your job to explain away that ambiguity.
On the other hand, “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 X developer-months over the next X months to fix it” is something everyone can engage with. Both have the same underlying problem, but lead to a completely different conversation.
The four sections below aren’t the only way to structure this, but they cover a lot of what software organization boards consistently want to know.
Start with highlights and progress against objectives. If your company runs OKRs or has high-level company-level goals, try to report engineering highlights against those — it connects your work to the company’s priorities rather than presenting engineering in a vacuum.
If you’ve been tracking the same objectives across multiple quarters, show the trend: the board can see whether things are improving or stalling, as well as where they stand today.
For strategic engineering initiatives, include recently completed initiatives, and how each current one is tracking, along with their estimated completion dates. When an initiative has headcount attached, include the FTE and associated cost — the board should get a sense of what initiatives are costing, as well as what they’re delivering.
This is also a good place to show that you have a handle on prioritization: what you chose to build, and what you chose not to.
Close with a brief roadmap signal. What initiatives are coming next, and what’s the expected business impact. No need for a full roadmap review (you won’t have enough time anyway), just enough for the board to see that engineering knows where it’s going.
Including team size and the delta since last time you met is the baseline: which teams grew, which contracted, any structural changes like a reorg, a new platform team, a team that’s been split or merged.
Attrition, specifically regretted attrition, is a risk signal that boards ask about from time to time, but it rarely comes up until it’s already affected delivery. A senior engineer leaving mid-initiative has a more complex impact than a -1 in the headcount delta. Including whatever data you have from exit interviews or internal surveys can help explain the ‘why’ behind the numbers.
You should also have a way to account for where engineering teams spend their time. We recommend the balance framework as a starting point. It breaks capacity into four buckets: new development, improvements, productivity work, and keeping the lights on (KTLO).
If you’re scaling, this question will come up: “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 overhead. Tracking your investment balance is how you keep visibility over where that capacity is actually going, and make sure the ratio of new development to everything else doesn’t quietly tip in the wrong direction.
Finally, if your company capitalizes software development costs, include the capex/opex split and align with your finance counterparts on how to present it.
Pick a small, consistent set of engineering metrics for your board — throughput, story cycle time, deployment frequency, and at least one reliability signal like incident frequency. Showing the same metrics every quarter helps the board see trends, which is far more useful than any one data point. Red/yellow/green is usually enough, but be ready to go deeper if someone asks. If cycle time went from green to yellow, you should know why and have a plan.
When introducing engineering metrics to your board update, it can be useful to provide some real-world examples. As in, “Story cycle time decreased from X to Y days, which means we’ve been getting product to market X% faster than before.”
Boards will also ask “is this good?”, not just “what is the number?” Knowing how your metrics compare to the previous period, or to industry benchmarks, is what turns a data point into a position. Without that, “our median cycle time is 12 days” opens the follow-up: compared to what?
This is also the place to surface what engineering is actively doing to reduce risk, move faster, or address known problems — most likely using data from the previous section about your investment balance.
Unfortunately, there’s no escaping questions about AI right now. However, often those questions are either too tactical: “do you think Claude Code is better than Cursor?” or too vague: “how is AI changing engineering?”.
To combat this, you should have data on adoption, usage, impact, and ideally, cost.
On adoption, show which tools the team is using, which parts of the org, and roughly what percentage of engineers are actively using them — enough to show it’s deliberate, not just anecdotal.
For impact, resist the temptation to lead with metrics like throughput or lines of AI-generated code. The question you’re likely to get from the board is whether feature delivery (and therefore value delivery to customers) has actually improved since adoption. Not the increase in code volume. And if adoption is up but issue/story cycle time hasn’t moved, you should be able to explain why — whether that’s review bottlenecks, deployment friction, or something else.
If you’ve moved further into agentic engineering, with task agents opening PRs automatically, separate those out: agent PR merge rates tell you whether the agent output is useful and meets your standards, not just whether it’s being generated.
On cost, it’s likely the board will do the AI ROI math on the fly, so you may as well present it yourself with proper context. If the spend looks modest relative to the value it’s adding, call it out. If it looks like it’ll raise eyebrows, you should have an answer for that. And if you’re not sure yet, that’s important too.
The hard part of pulling all of this together is that each section probably has a different source or two. Initiatives live in your issue tracker, engineering metrics in your source code hosting platform (if at all), objectives in Notion or Google Docs, headcount in your HR system. You’ll need to accept some manual assembly the first time, with or without the help of AI.
If you want a starting point, we’ve created a downloadable CTO board deck template that covers this structure. And of course, if you want a way to get most of this data from a single place, I’d recommend you take a look at Swarmia.
An underrated benefit of a well-structured CTO board presentation is the work that happens before the meeting. Pulling together a good board update forces alignment between the CTO, CPO, and CEO on product bets and engineering priorities — disagreements that might otherwise not get voiced are sure to get surfaced when you’re all looking at the same slides.
The board shouldn’t have to reorient themselves to a different format each time. Your time with them is limited, and valuable, so use the same baseline structure every quarter.
Once they know where to look for what, they start tracking trends on their own and asking better questions. That pattern recognition is what makes harder conversations easier later — for example, when you need to explain a risky technical bet or make a case for extra headcount or budget, the baseline is already there.
Boards exist to guide the organization, and to offer their experience and network where possible. If there’s an ask, end with that. Two categories that boards can help with:
Last thing. Remember that 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 (taking bets on it being ‘agentic’ until at least Q4) and spend your whole 20 minutes on it. A clear structure and a specific ask at the end are the best tools to get something useful for your engineering org from the board meeting.
The board that helps you through a hard call — a budget overrun, a risky technical bet, a retention problem impacting delivery — is one that’s been following engineering long enough to have context. If the first real briefing happens during a crisis, you’re asking them to understand the problem and act on it in the same meeting. Regular updates are how you build that context before you need it.
Your first board update (or your first after an overhaul) won’t be perfect, and that’s ok. Start with what you do have data for, keep the structure consistent, and build on it each meeting at a time. And by the time you need the board to back a difficult decision, they’ll already have the context to do it.
Subscribe to our newsletter
Get the latest product updates and #goodreads delivered to your inbox once a month.
