A search consultant once asked me, ahead of a board conversation, what I would actually do in the room. Not what I knew: what I would do with it. It is the better question, and most technology candidates for board roles are not ready for it.

The instinct, coming out of a technical career, is to think the value is in the diagnosis. Put a former CIO or IT leader on a risk or audit committee and they will spot the gaps: the unpatched estate, the vendor concentration risk, the AI initiative with no governance wrapper around it. That instinct is not wrong. But it is not the job either. Every capable technology director in the country can identify a risk. What a board actually needs from that seat is someone who changes the quality of the conversation once the risk is on the table.

Where the contribution actually sits

I spent thirty years moving from writing code to teaching it, to running IT portfolios worth $15M+ across 60-plus projects, to negotiating vendor contracts with P&L accountability. None of that experience earns a board seat by itself. What it earns is a specific instinct: the ability to ask whether a risk is actually understood by the people accountable for it, or merely acknowledged in a slide. Those are different states, and the gap between them is where most governance failure actually lives, not in the absence of a risk register, but in a risk register nobody in the room can interrogate.

A technology independent director on an audit or risk committee is not there to review architecture diagrams or second-guess the CTO's roadmap. They are there to ask: does this board have enough visibility into this decision to actually govern it, or are we approving a recommendation we can't independently assess? That question is uncomfortable precisely because it is usually answerable: someone in the building knows. The director's job is to make sure that knowledge reaches the boardroom in a form the board can act on, not just receive.

What that means in practice

Take an AI initiative coming to a board for budget approval, increasingly the norm, not the exception, in 2026. The easy contribution is flagging that AI spend needs governance. Everyone on the committee already knows that. The harder and more useful contribution is a specific frame: separate the budget conversation from the governance conversation entirely. Approve the spend on its business case. Govern the deployment on a different cadence: data provenance, model risk, human-in-the-loop points, vendor lock-in, because those risks mature on a different timeline than the P&L does. That reframing is not a technical insight. It is a structural one, and it is the kind of thing a board remembers a director for.

What the role should not become

The failure mode on the other side is just as real. A technology director who treats every board discussion as an opportunity to demonstrate technical depth is not adding governance value: they are performing expertise for an audience that did not ask for a briefing. The operational background is the source of the judgement, not the content of the contribution. If I am explaining how a firewall works to a board, I have already failed at the job. If I am helping the board decide how much assurance it needs before it approves a decision it cannot fully audit itself, I am doing it.

The crux, as I see it

Boards do not need more people who can name the risk. They need people who have carried operational accountability for that risk long enough to know what a genuine mitigation looks like versus a plausible-sounding one, and who can translate that judgement into a question the whole board can use, not just the technologists in the room. That is a different skill from technical fluency, and it is the one search committees should actually be screening for.

Where I would stress-test this further: how much operational recency actually matters for that judgement to stay sharp, versus how much of it is durable once earned. I don't think that question has a clean answer yet, and I'd be glad to be told I'm wrong about it.