The board and the executive team
As CTO you answer to a board and you work inside an executive team. Both judge technology by what it does for the business, and both see you for a few hours a quarter. This lesson shows you how to write board papers that get decisions, choose a handful of technology metrics a board can act on, treat the executive team as your first team, and answer hard questions and crises in a way that builds trust.
By the end you can
- Explain what a board needs from its CTO and how it differs from what the executive team needs
- Write a board paper with the ask first, options on the same criteria and the risks stated plainly
- Choose six to eight board-level technology metrics, each with a target, a trend and an owner
- Work with peers you don't manage, such as the finance director, and pre-wire a decision before the meeting
- Answer hard board questions in one sentence with one fact, and keep the board informed during a crisis
The everyday picture
A family hires a builder to put up a new house. Every Saturday the owners walk the site for half an hour. They don't want to hear about every brick. They want three things: is it on time and on budget, is anything unsafe, and is there a choice only they can make, such as which windows to buy before the price goes up. A good builder arrives with a one-page sheet, walks them to the two places that matter, and leaves with a decision.
A poor builder talks for the whole half hour about the new cement mixer. The owners leave confused, start ringing the plumber directly, and stop trusting the weekly walk. A board is the owners on that walk. Your executive colleagues are the other trades on the site: the plumber and the electrician, whose work has to fit with yours.
What a board wants from its CTO
A board of directors does not run the company. It appoints and oversees the chief executive (at Mangrove, the managing director), approves the strategy and big spending, watches performance, and makes sure the main risks are understood and managed. Governance writers often sum this up as "noses in, fingers out": the board asks hard questions but leaves the management to the managers. Most boards also have committees. At Mangrove the audit and risk committee meets before every quarterly board meeting.
When a board looks at technology, it asks four questions, whatever words it uses:
- Is technology helping the strategy? Will the systems be ready for two new cities and twice as many partner shops, and when?
- Are we safe? Could an outage stop stores selling, could a breach expose customer or card data, and what would it cost?
- Is the money well spent? About $16 million a year goes to technology. Is that the right amount, and is it going to the right things?
- Do we have the people? Can we hire about 30 more engineers, and are we keeping the ones we have?
Everything you bring to the board should answer one of these four. That rules out a lot of what engineers find interesting: the new framework, the migration to a different queue, a record number of deploys. Those may be good decisions, but they belong to you and your leadership team. The board needs the effect, such as "new stores can open with working systems in three weeks instead of nine".
Boards also have a calendar. A director reads your paper perhaps a week before the meeting, alongside papers from finance, operations and HR, and spends maybe 20 minutes on it. In the meeting you may have 30 minutes, often less. Your job is to make that time produce a decision or a clear steer.
Quick check
You have 20 minutes at the board. Which item belongs there?
The invoicing decision links to the strategy (twice as many partner shops), to money and to vendor risk, and it has a deadline the board can act on. The queue migration is finished and is a management matter. Sprint velocity is a team-level number that boards cannot interpret. A design demo can be pleasant, but it asks the board for nothing.