How to Run a Technology Strategy Review With Your Board

The board technology review typically gets scheduled once a year, sometimes once a quarter, and it almost always occupies the slot right after lunch when everyone’s energy is lowest. This scheduling says something about how the organization thinks about technical strategy — as important enough to warrant a dedicated slot, but not important enough to get the prime real estate.

The deeper problem is framing. Most technology strategy reviews are built around the question “what is our technical direction?” which is a question that most board members can’t productively engage with because they don’t have the context to evaluate the answer. The result is a presentation that flows in one direction — CPTO explaining, board listening — followed by generic questions and polite agreement. Nothing gets sharpened. No useful inputs come back. The CPTO leaves having spent preparation time for no discernible benefit.

The question that makes a board technology review actually work is different: “What are the technology decisions that will most significantly affect our strategic options over the next two to three years, and what does the board need to understand to give useful input on those decisions?” That’s a board-appropriate question. It connects to business strategy. It asks for input rather than just approval. And it surfaces the decisions where external perspective — including non-technical perspective — is genuinely valuable.

What to put in the room

The content that generates productive board engagement in technology strategy reviews falls into three categories.

First, major make-vs-buy decisions at the platform level. Not vendor selection for a specific tool — that’s management’s job — but decisions about whether to own a core capability or to depend on an external provider for something strategically important. The board can add real value here because these decisions often turn on assumptions about market structure, competitive dynamics, and organizational capability that board members with diverse backgrounds can challenge productively.

Second, the technical investment thesis. What are you spending your engineering capacity on that doesn’t show up in the product roadmap, and why? This is the place where the argument for infrastructure investment, technical debt reduction, and foundational capability building gets made to the people who control capital allocation. Making it well requires translating from technical terms to business terms: not “we’re migrating to a microservices architecture” but “we’re making an architectural investment that reduces our time-to-ship for new product capabilities from twelve weeks to four weeks, which we believe is a durable competitive advantage in our market.”

Third, technical risk. The items that are on the engineering team’s risk register that could materially affect the company’s ability to execute on its strategy. A critical dependency on a single vendor. An architecture decision from three years ago that’s becoming a scaling constraint. A key-person risk in the technical organization. Board members should know these exist. They often have inputs on mitigation. And surfacing them proactively, rather than waiting until they become incidents, builds board confidence in the technical leadership team.

What not to put in the room

The architecture overview. The technology radar. The sprint velocity charts. The platform diagram with all the microservices labeled. These formats generate the one-direction presentation problem — the CPTO explains, the board absorbs — and they don’t leave room for the kind of give-and-take that makes a board discussion valuable. If board members need technical background to follow the discussion, provide it in the pre-read, not in the meeting.

The meeting itself should be structured to use what boards are actually good at: challenging assumptions, asking uncomfortable questions, drawing connections to external context the CPTO might not have, and stress-testing whether the strategy is coherent against the business model and competitive environment. You can’t use boards well for those things if you’re spending the time explaining the technology.

The one thing worth getting explicit agreement on in every technology strategy review: what are the decisions that require board input before they’re made? Not after, not for information purposes — genuinely requiring input. That list should be short, and every item on it should be on the agenda before the end of the meeting.