Communicating With Executives: Translating Engineering Work Into Board-Level Language

Last updated: October 1, 2026

By Kris Drouet, Engineering Executive, in partnership with KORE1

Engineering had eleven minutes on the agenda. I used four.

It was one of my first board meetings as the person accountable for engineering, and I’d built what I thought was a strong slide. Fourteen services moved onto the new platform. P95 latency down 38 percent. Deploys up from weekly to daily. Every number was true, and every one of them had cost my team real evenings. The chair said “thank you, great progress,” and we moved on to the sales pipeline, which got twenty-five minutes and, by my count, nine questions, two of them from a director who hadn’t looked up once while my slide was on the screen.

Nobody asked me anything.

I walked out thinking it had gone well. Our CEO caught me at the elevator and fixed that in one line. “They didn’t ask because they didn’t know what to ask.”

That stung. He was right. Silence after a board slide isn’t approval. Seven smart people couldn’t find a handle on what I’d just said and decided, politely, not to spend the room’s time hunting for one. The pipeline slide drew nine questions because every director at that table could do something with a pipeline number. Compare it to plan. Ask about the two deals that slipped. Mine gave them nothing to do.

I’ve written before about building an engineering budget your CFO will approve and about why “tech debt” is the wrong frame for a funding request. Both of those are about one ask. This is about the standing update, the four or five times a year engineering goes in front of the people who can replace the CEO, and whether they walk out understanding what you told them.

What Communicating With Executives Actually Requires

Communicating with executives is the practice of restating specialized work in the terms your audience uses to make decisions. For an engineering leader in front of a board, those terms are revenue, cost, risk, and time. The work stays the same. The unit it’s reported in changes, and so does the order, with the conclusion first.

Simple to say. I got it wrong for years, and I wasn’t short on brains. Neither were the directors.

In 1990 a Stanford graduate student named Elizabeth Newton ran an experiment I think about before every board meeting. She split people into tappers and listeners. Each tapper picked a song everybody knows, “Happy Birthday” and the like, and tapped the rhythm on a table while the listener tried to name it, which sounds easy right up until you’re the one doing the listening. Chip and Dan Heath retold the results in a 2006 Harvard Business Review article on the curse of knowledge. Out of 120 songs, listeners got three. That’s 2.5 percent. Before the guessing started, Newton had asked the tappers how often they expected to be understood, and they said half the time.

One in forty. They expected one in two.

The tapper can’t help hearing the tune while she taps. The listener gets knuckles on wood. When I say “P95 latency is down 38 percent,” I hear the whole song, the partner whose requests kept timing out, the on-call weekend that started it, the three sprints it took to fix. A director hears tapping. And like Newton’s tappers, I left that meeting sure I’d been understood.

Nobody Is Going to Make the Board Learn Your Language

You could wish for a more technical board. Plenty of engineering leaders do. I did. The people who write the rules considered that idea and backed away from it.

In 2022 the SEC proposed that public companies disclose whether any director had cybersecurity expertise, by name. When the final rule came out in July 2023, that piece was gone. The explanation in the adopting release is worth reading slowly. The Commission said it was persuaded that effective cybersecurity processes are “designed and administered largely at the management level.” Directors with “broad-based skills in risk management and strategy,” it went on, “often effectively oversee management’s efforts without specific subject matter expertise, as they do with other sophisticated technical matters.”

Other sophisticated technical matters. That’s you. Your platform, your architecture, your AI roadmap.

What the rule kept is just as telling. Item 106 of Regulation S-K asks a public company to describe its board’s oversight of cybersecurity risk, including “the processes by which the board or such committee is informed about such risks.” Informed by whom? Management. In practice, whoever runs engineering and security. Nobody at the SEC expects a director to read a network diagram. The rule asks whether somebody is telling them what they need to know, in a form they can use.

If your company is private, none of that binds you. Your directors probably sit on other boards where it does, though, and they carry the habit from room to room.

The numbers back up the instinct. Researchers writing in MIT Sloan Management Review in 2019 went through director bios at U.S.-listed companies and reported that among those with more than $1 billion in revenue, 24 percent had a digitally savvy board. Those companies did better on revenue growth, return on assets, and market cap growth, which is a fine argument for changing who sits on boards. It isn’t a plan for your next meeting. The figure has surely moved in seven years. I wouldn’t bet it has moved enough to change how you prepare. Assume intelligence. Don’t assume fluency.

Four Units a Board Can Act On

Revenue. Cost. Risk. Time. A board can act on a statement made in one of those, because every decision it actually makes, approving a budget, a hire, a financing, an acquisition, gets priced in them. Anything else is color.

Before I write a word of a board update now, I pick the unit. If I can’t pick one, the item doesn’t belong in front of the board. It belongs in my staff meeting, where it’s probably important.

Here’s what the conversion looks like on the kind of lines that turn up in engineering updates all the time. The numbers are made up. Yours shouldn’t be, and somebody on that board will eventually say their own version of show me the data.

Look at what the right-hand column never does. It never explains how. Kubernetes doesn’t appear in it. Neither does the word refactor. If a director wants the how, they’ll ask, and that’s a good meeting.

Now a real one. When we replaced our point-to-point loan integrations with Kafka and cut downstream latency 45 percent, the engineering sentence was exactly that, and I was proud of it. The version for a board is different. A spike in pricing volume no longer backs up reconciliation behind it. Same project, same result, and the second version is the one a director could repeat to another director in the parking lot. That’s my test. Can they repeat it?

Getting there is mostly a matter of asking “which means?” until you land on one of the four. We upgraded the message broker. Which means? Peak-hour requests stopped queuing. Which means? Reconciliation finishes before the morning cutoff. Which means? Finance closes the day on time during a rate rally. Stop. That last one is a time statement with a cost attached. It usually takes three rounds, and if you’re still talking about software after five, the item probably isn’t board material.

For a single funding ask there’s a tighter form, one sentence with a named system, a consequence, a date, and an owner. I laid that out in the tech debt piece and won’t repeat it here.

Which Board Are You Talking To?

Boards don’t all weight the four units the same way. Three kinds come up most.

A venture-backed board listens for revenue and time, in that order, and it hears cost as runway. A request for six more engineers reads to those directors as two fewer months of cash. What they’re really pricing is whether the product will be ready for the customers the next round depends on, so a slipped date is the biggest thing you can report and a pulled-in one is the best.

Private equity is different. There’s a plan, it has an EBITDA number and a hold period, and you’re measured against both. Engineering spend gets read as a percentage of revenue and compared with the last three companies the firm owned. Everything you say also gets filed away for the day a buyer’s team shows up to check it, and I’ve written about what acquirers actually test in technical due diligence. Short version. Consistency matters more than polish.

Public boards run on committees. Your update may never reach the full board. It goes to the audit committee or a risk committee, and the unit that matters most is risk, stated plainly enough that it could sit next to a disclosure without contradicting it.

And in mortgage and fintech there’s a listener who isn’t in the room at all. The examiner. Directors at a regulated company get asked what they knew and when, so they want your risk statements dated and specific. That’s one of the ways engineering leadership in regulated industries differs from generic SaaS, and I’ve come to like it. It forces precision.

Send the Pre-Read and Save the Room for Questions

The meeting is the least important part of a board update. The board book goes out days ahead, and the directors who matter read it. On a plane, usually. By the time you stand up, they’ve either understood your page or skipped it.

Nancy Duarte’s 2012 advice in Harvard Business Review on presenting to senior executives has held up for more than a decade. If you’re given thirty minutes, build the opening as though your slot had been cut to five. Put a short summary at the front and treat everything else as appendix, at a ratio she calls the 10 percent rule. Fifty slides of backup, five of summary. Will Larson gives engineering leaders the same instruction in his notes on presenting to executives, and he puts it more bluntly. Start from the conclusion.

My engineering section in the board book is one page. Two don’t get read.

• The top line says what I need from the board, or says plainly that I need nothing this quarter. Directors relax when they know which kind of update it is.
• Three items. Never five.
• Each item sits in one unit, with a number, a date, and a comparison to what I told them last time. That last part is the piece people skip.
• One thing that’s worse than last quarter. Every quarter has one, and if my page doesn’t name it, they’ll assume I either don’t know or won’t say.
• Everything else goes in the appendix. Architecture diagrams, delivery metrics, the roadmap. It’s there if someone asks.

Then one phone call. Every board has a director who will ask the hardest question, often the audit chair or the one who used to run operations somewhere, and that’s the person to call three or four days before the meeting. Walk them through the page. Ask what’s unclear. You’ll find out which sentence doesn’t translate while there’s still time to fix it, and you’ll have one person at the table who has already had their question answered and can say so.

In the room I restate the page in about two minutes and stop talking. Eleven minutes on the agenda should mean nine of questions. If nobody asks anything, I’ve been tapping.

The Question Behind the Question

Directors rarely ask what they mean. They ask the polite version, and an engineering leader who answers the polite version loses the room a little each time. A few I hear constantly.

• “Are we on track?” This is about a date in a plan they approved. Give the date, say whether it still holds, and if it doesn’t, give the new one before you explain why.
• “How does our technology compare to theirs?” Somebody forwarded them an article. Or a banker said something over dinner. Find out which competitor and which claim before you answer, because the honest response to a specific claim is usually short and the response to a vague one never ends.
• “Should we be doing more with AI?” Their other boards are talking about it. They want to know you have a view and what it would cost to be wrong in either direction.
• “Why do we need more engineers?” They’re looking at revenue per head. Sometimes they’re right to push, too, and the coordination tax on a growing engineering team is real enough that I’d rather raise it before they do.
• “Are we secure?” Nobody can answer yes. What they’re asking is whether they’ll be surprised. Tell them what was tested, when, by whom, and what’s still open.

Answer the real question first and the literal one second. It feels presumptuous the first time. It reads as competence.

The Boring Work Is the Hardest to Translate

The hardest translation I’ve had to make for senior executives is that operational discipline is not bureaucracy. Written priorities, a steady planning rhythm, estimates people stand behind. None of it produces a feature. All of it shows up as a calendar full of meetings, and a calendar full of meetings is the first thing a cost-minded director wants to cut.

I used to defend that work by describing it. Bad idea. A description of a process sounds exactly like overhead. I made the full case for operational discipline elsewhere, and what finally worked in a boardroom was much smaller than that argument. Translate it into time. Count the dates you committed to over the last four quarters. Count the ones you hit. That ratio is what the boring work buys, and a board understands forecast accuracy better than almost anything else you’ll show it, because a company that can’t predict its own delivery can’t plan revenue against it. It’s also why I treat sprint estimates as informed commitments and not wishes.

The same rule covers bad news, and this is where translation gets tested. It’s tempting to report wins in board language and misses in engineering language, to say “revenue impact” when the release lands and “unexpected complexity in the data migration layer” when it doesn’t. Directors notice. Maybe not the first time. A miss gets the same unit as a win. We said March. It’s May. The cost is one quarter of the partner revenue we planned. Here’s what changed so May holds. I’m making that sound easier to say out loud than it is, and I have the memory of one very quiet boardroom to prove it, but it’s still the fastest way I know to be believed the next time the news is good.

When the Missing Piece Is the Translator

A word on who’s publishing this. KORE1 runs these pieces with me, and KORE1 gets paid when a company hires through it, so read the next three paragraphs with that in view.

Sometimes the gap isn’t a slide. I’ve seen engineering orgs with a strong technical lead who simply can’t do this part, and I’ve watched what follows. The board stops asking engineering questions and starts asking the CEO about engineering. Then it starts asking whether engineering is the problem. The team hasn’t gotten any worse. Its translator is missing, and from the board’s side of the table those two things look identical.

Start by coaching the leader you have. That works more often than people expect once someone shows them the units. Bring in a fractional or interim VP of engineering to run the board relationship for a few quarters while the technical lead keeps the team. Or run a full VP of engineering search on a direct hire basis and look specifically for someone who has presented to a board before and can show you the page they used.

KORE1 has been placing engineering talent since 2005, works in over 30 U.S. metro areas, and puts its twelve-month retention at 92 percent. Its 17-day average time to fill is for IT roles broadly. A VP search takes longer, and anybody who tells you otherwise is selling. The retention figure is the one I’d look at for a leadership hire, since the whole value of a translator is that the board gets to know them over several quarters. KORE1’s engineering staffing practice handles those searches.

Asked the Night Before a Board Meeting

How Much Board Time Should Engineering Actually Get?

Ten to fifteen minutes in a normal quarter is plenty for the engineering update, with no more than a third of it spent presenting and the rest left open for directors’ questions.

Ask for more when there’s a decision on the table, like a platform bet or a large hiring plan. Don’t ask for more because the work was hard. It was. They believe you.

Do Directors Want to See Engineering Metrics at All?

One or two metrics, yes, as long as each is stated in customer or dollar terms with a trend and a plain sentence about what moved it.

If I get a single number, it’s change lead time in days. I explained why in the four delivery metrics that predict engineering velocity. A dashboard with twelve tiles is a way of not choosing, and directors read it that way.

What if One Director Is More Technical Than I Am?

Brief that director before the meeting and treat them as an ally, because a technical director who trusts your numbers will vouch for them with everyone else at the table.

The failure here is performing for them. You go deep to prove you can, the other six get lost, and the one you were trying to impress notices that you lost the room. They’ve seen it before. Usually from the other chair.

Should the CTO or the CEO Present the Engineering Update?

The person who runs engineering should present it, after the CEO has read the page, since the board is also judging whether that person can explain the business.

A CEO who always presents for engineering is sending a message about the engineering leader. Sometimes it’s intended.

A Date Slipped. How Do I Say It Without Losing the Room?

Say the new date first, then the single biggest cause, then what’s different now so the new date holds, and do all three inside the first minute.

What loses the room is the windup. Three minutes of context before the bad number tells every director that you knew and were stalling. If the slip was already in the pre-read, even better. Nobody likes learning it live.

Is It Ever Right to Go Deep on the Technology?

Depth is right in two cases, when a director asks for it and when the decision in front of the board is a technology choice, like a platform migration or a seven-figure build vs buy call.

Even then, lead with the decision and the units, and keep the detail in the appendix until somebody reaches for it. My framework for those decisions runs on five numbers for that reason. A board can weigh five numbers. It can’t weigh an architecture diagram, and it shouldn’t have to.

Hum the Tune

The tappers in Newton’s experiment weren’t bad at tapping. They had a song in their heads and assumed it came through. Every engineering leader walks into the boardroom with a song like that, years of context about why the platform matters and what it took to build, and taps it out as a list of things that shipped.

Pick the unit. Put the conclusion first. Send the page early and call the director who’ll ask the hard question. Then stop talking and count the questions you get. Zero is not a compliment.

If your board has stopped asking engineering anything at all and you think the missing piece is a person, talk to KORE1’s recruiting team about the search. And if you want to trade board-slide stories or argue with the four units, connect with me on LinkedIn. I’ve got a few.