Boards Ignore Technology Strategy When It Arrives as an Engineering Plan
The board may delegate engineering judgement; it cannot delegate the business choices that technology makes irreversible.
The Twelve-Minute Strategy
The technology director carries an eighty-six-page strategy into the boardroom. It contains five architecture diagrams, a three-year systems plan, thirty-seven projects and a request for £96 million. The paper explains network standards, enterprise applications, data centres, supplier consolidation and the new internet channel. It is careful, coherent and technically literate.
Twelve minutes into the discussion, the chairman asks a simple question: Which business choices are we making here?
The document has no clear answer. It shows what the technology estate should look like, but not which customers will be served differently, which processes will be common, which capabilities justify the capital, or which risks the organisation is choosing to carry. The board notes the paper, asks for annual cost reductions and returns to subjects it regards as strategic.
This scene is repeated because technology strategies are written by technologists and ignored by boards. The common diagnosis is that boards do not understand technology. That is only half true. The deeper failure is that neither side has defined technology strategy as board work.
Technologists produce the document because someone must. They fill the vacuum with the questions they are equipped to answer: which platforms should be standard, which systems should be retired, how infrastructure should be made resilient, and how suppliers should be managed. Boards then receive an engineering plan dressed as strategy and treat it as a specialist matter.
The board may delegate engineering judgement; it cannot delegate the business choices that technology makes irreversible.
The Wrong Unit of Strategy
A list of systems is not a technology strategy, however well ordered. It is an estate plan. Estate planning matters, particularly after the extraordinary effort required to prepare systems for the millennium date change. Many organisations have discovered more about their applications, interfaces and dependencies in the past two years than they learned in the preceding decade. That knowledge should not be discarded.
But the strategic unit is not the system. It is the business choice the system enables or constrains.
An enterprise application can require common product definitions across divisions. A customer database can change who owns the relationship. An internet channel can alter pricing, fulfilment and service expectations. A standard desktop can reduce support cost while limiting local freedom. Outsourcing data-centre operations can release management attention while increasing dependence on contract design and supplier performance.
Each is a business decision with technical content. When the paper presents them as technical decisions with financial consequences, the board encounters the costs but misses the choices.
| Technology language | Board question |
|---|---|
| Common enterprise system | Which processes and definitions must become common? |
| Customer information architecture | Who owns the customer and who may use the information? |
| Internet channel | Which transactions move online, and how will fulfilment change? |
| Infrastructure resilience | Which interruptions are unacceptable, and what will avoidance cost? |
| Supplier consolidation | Which capabilities may sit outside the organisation? |
| Application retirement | Which local practices are we prepared to stop? |
The translation is not a communications exercise performed after the technical work. It is the strategy.
How the Vacuum Forms
Technologists are often blamed for speaking in jargon. Boards deserve equal scrutiny for the conditions that produce it.
Three habits create the governance gap.
- Technology appears only when money is requested. The board sees individual cases, never the cumulative direction created by them.
- Accountability sits with the technology function. Business executives sponsor projects but do not own the process, information or operating changes on which value depends.
- Success is defined as delivery. Systems are judged by date, cost and stability; the board rarely returns to whether the promised business result occurred.
The result is a peculiar asymmetry. Technology leaders are asked to devise a three-year direction, but they lack authority to standardise processes, resolve divisional priorities or decide how customers should be served. Business leaders possess that authority, but regard the resulting plan as technical.
In a composite multi-division organisation, the technology strategy proposes one customer record and a common order system across six businesses. The case forecasts £14 million of savings from removing duplicate systems and support. No board decision is made about common customer definitions, credit rules or product codes.
Eighteen months into delivery, 240 interfaces have been commissioned to preserve local arrangements. Implementation cost rises by £11 million, the retirement timetable slips, and the common system becomes a new layer over old variation. The failure appears technical because the invoices sit in the technology budget. The cause was a series of business decisions the board never made.
Complexity in the systems estate is often the accumulated cost of unresolved executive disagreement.
The Serious Case for Delegation
Technology is specialised. Boards cannot and should not debate network design, database structure or software configuration. Executive time is scarce, and interference by enthusiastic amateurs can be worse than neglect. A capable technology director, supported by sound architects and suppliers, must have room to exercise professional judgement.
There is also danger in making every technology choice strategic. Some standards are housekeeping. Elevating routine matters to the board slows decisions and weakens accountability. The organisation needs a clear boundary between governance and engineering.
That argument is correct. The mistake lies in placing the boundary between “business” and “technology”. The better boundary lies between enterprise choices and implementation choices.
The board should decide the enterprise choices:
- where commonality creates value and where difference remains justified;
- which information is an enterprise asset rather than divisional property;
- which channels and processes will receive priority;
- which risks require resilience, control or retained capability;
- how much capital the whole portfolio can absorb;
- who owns the benefits and operating changes.
The technology function should decide or recommend implementation choices within those boundaries: architecture, sequence, standards, capacity, technical risk and supplier design. Professional delegation becomes stronger once the strategic constraints are explicit.
Replace the Annual Document with a Decision System
Technology strategy usually arrives as a large annual paper because governance has been postponed. By the time the board sees it, dozens of assumptions are embedded and the only apparent choice is approval or rejection.
A more credible approach begins with a short set of enterprise decisions and maintains them through the investment cycle.
- State the business tensions. For example: local autonomy versus common customer service; rapid internet experimentation versus integration with fulfilment; lower infrastructure cost versus operational resilience.
- Make the choices explicit. Record where the enterprise will standardise, what it will protect, and which uncertainties justify staged investment.
- Translate choices into principles. A principle such as “one customer identifier across all divisions” has meaning only after the ownership and commercial implications are agreed.
- Build the portfolio. Every project must show which choice it serves, which operating executive owns the outcome and which legacy cost it removes.
- Revisit value and direction. The board should review the portfolio as business conditions, suppliers and technology economics change, not merely when spending exceeds tolerance.
The practical artefact can be concise: a decision map, a portfolio with benefits and dependencies, an architecture response, and a record of exceptions. The bulk of technical detail belongs beneath board level. What must remain visible is the line from enterprise choice to capital, change and result.
What the Board Must Learn to Ask
The recent millennium effort has shown that boards can engage deeply with technology when the business consequence is unmistakable. They asked about continuity, testing, suppliers and contingency because operations were visibly at stake. The challenge is to preserve that seriousness without requiring another fixed date or evident threat.
The questions are not technical:
- What business model and operating assumptions are we embedding?
- Which decisions will become expensive to reverse?
- Where are we paying to preserve unresolved variation?
- Which executive owns the change outside the technology function?
- What will stop when this investment begins?
- How will we know that value has appeared?
A board that can answer those questions does not need to design systems. It needs to govern the organisation those systems will make possible.
Technology strategies will continue to be ignored while they remain documents technologists write for boards. They become consequential when boards recognise them as choices they make with technologists. The difference is ownership, not vocabulary.