Executive Technology
Literacy

There is a particular kind of senior executive who has acquired the vocabulary of technology without the understanding beneath it. He can name the building blocks at a meeting, reach for the fashionable terms, and pass, for a sentence or two, as informed. The performance survives precisely as long as nobody asks him why.

This programme is built in deliberate opposition to that failure. Its purpose is not to furnish a vocabulary but to reconstruct a field, from the ground upwards, so that what is known is genuinely understood and therefore holds when it is tested.

I The Objective

The aim is a specific competence: technology literacy sufficient for peer-to-peer engagement with the Chief Technology Officer and the Chief Transformation Officer, and with their counterparts across the financial-services firms of the United Kingdom and the United States. It is worth being precise about what this is not. It is not the ability to write production software. The conversation this programme prepares one for is the architectural and strategic conversation: how large systems are composed, where they fail, what the trade-offs are, and what a given choice commits the firm to over the following decade.

The competence is deliberately generalised — expertise in the field, not in any single firm. A Chief Technology Officer at a British insurer, the head of engineering at an American asset manager, and the equivalent at a global bank face the same fundamental questions, draw on the same vendor landscape, and increasingly move between firms. Becoming credible to one of them is, in large part, becoming credible to the community.

II Four Governing Principles

First, first-principles understanding rather than pattern-matching — reconstructed understanding degrades gracefully where memorised vocabulary fails the moment the territory shifts. Second, building-blocks sequencing — a thin veneer established across all ten domains, each then deepened in turn, a schema built before it is populated, exactly as in medical training. Third, generalised expertise in the field rather than firm-specific knowledge, because that is the knowledge that transfers and compounds. Fourth, a working separation between the durable substrate and the current frontier.

III Substrate and Frontier

The knowledge decomposes into two layers with very different shelf lives. The durable substrate — distributed-systems theory, database internals, cryptography, networking, the economics of cloud computing, the principles of software engineering, and the structure of the regulatory regimes — changes slowly and can be learnt properly once; it is taught here directly and at depth. The current frontier — what the major firms are doing now, which vendors are ascendant or in difficulty, where the investment is concentrated this quarter — changes constantly and is served by sustained attention to a small number of primary sources. Every claim about a named product, a named person, or a recent event is treated as a frontier matter: verified against live sources before it is asserted.

IV The Method

The method is Socratic and consistent across the blocks. Each block is taken in a fresh conversation. A question is posed; it is answered at whatever depth is available; the answer is corrected where it is wrong, refined where it is roughly right, and extended with the layers that were missing; and the next question follows from there. Each block concludes with a typeset reference artefact in the house style — the documents linked from this page are instances of that form.

V The Order of Study

The blocks are numbered for reference, not for marching order, and study proceeds along the lines of dependency and readiness. The traverse of networks was taken first, as the most concrete point of entry to the field; systems architecture followed, as the conceptual spine to which the rest of the field attaches; databases and storage come next, because they are where that spine becomes the single piece of infrastructure a finance leader most often has to reason about in practice. The whole is designed to be worked through over many months; the reward is not fluency at next week’s meeting but understanding that still holds five years from now — which is the only kind worth the cost of acquiring.

Why no serious firm runs its business on a single machine, however powerful one it could afford; the physics that forces multiplicity once single-core speed plateaus; the parallelism ceiling described by Amdahl and lifted by Gustafson; the loss of shared truth and shared time the moment work crosses a network; the CAP trade-off; the consistency spectrum; the append-only log as the primitive beneath modern architecture; and the machinery of consensus and quorum by which machines that trust neither one another nor their own clocks nonetheless reach firm agreement.

The foundational grammar on which most of the other blocks rest.

How data is modelled, moved, stored, and served across an enterprise; the separation of the operational and analytical estates and the reasons for it; the warehouse, the lake, and the lakehouse that sought to reconcile them; batch against streaming ingestion; and the discipline of data contracts and the treatment of data as a product with named owners and guarantees.

The layer at which a firm’s information becomes either an asset or a liability.

What the cloud actually is beneath the marketing; the service models — infrastructure, platform, software, and function — and what each one delegates and retains; the economics of renting rather than owning compute; the buy-versus-build calculus; data gravity and the precise mechanics of vendor lock-in; and the financial discipline of treating cloud cost as a managed line of the profit-and-loss account rather than an uncontrolled overhead.

The block that bears most directly on a firm-wide cost base.

How software is actually built, tested, released, and maintained; version control and the mechanics of collaboration at scale; continuous integration and delivery; testing strategy and what it does and does not buy; technical debt, what it genuinely is, and the circumstances under which incurring it is rational; and the perennial, much-mismeasured question of engineering productivity.

The block that explains why software takes as long as it does, and where the cost truly sits.

The trust architecture beneath everything else; the distinction between authentication and authorisation; encryption in transit and at rest, and what each actually protects against; identity as the perimeter that has displaced the old network boundary; the threat landscape facing financial institutions specifically; and the zero-trust posture understood as a design principle rather than a product to be purchased.

The block in which architecture and risk most plainly meet.

What these systems are and, just as importantly, what they are not; the distinction between training and inference; the transformer architecture in outline and the economics of the buildout that sustains it; retrieval, fine-tuning, and the agentic patterns now emerging; and model risk management in a regulated setting.

The block where the frontier moves fastest and the search-and-verify discipline therefore matters most.

The physical internet, traced from the keypad to the cloud; the journey of a single message and the layered envelopes it travels in; the Domain Name System; submarine cables and the quiet migration of their ownership to the hyperscalers; data centres, the power they draw, and the grid that now constrains them; and the abstraction stack from physical server through virtualisation, containers, and orchestration.

The machinery on which everything else physically runs.

How data is durably persisted and efficiently retrieved; the storage engine and the central divide between the B-tree and the log-structured merge-tree; indexing and what it costs to maintain; replication and sharding as the concrete implementation of the consistency choices first met in Block One; the transactional and analytical divide; and the proliferation of database types, with the judgement of when each is warranted.

The tightest dependency from the systems-architecture block, and the next to be taken.

The human side of the field; how engineering organisations are structured, how they fail, and how they are led; Conway’s Law turned from an observation into a deliberate strategy; the team topologies by which groups are arranged to ship independently of one another; the economics of scarce talent; and what a Chief Technology Officer and a Chief Transformation Officer actually do with their days.

The block that explains why architecture and organisation are so often the same decision viewed twice.

The frameworks that constrain technology in regulated finance; operational resilience under DORA and the United Kingdom’s equivalent regime; model risk under the PRA’s SS1/23 and its American analogues; data sovereignty and residency; third-party and concentration risk as the supervisory lens now trained on the hyperscalers; and the regulator understood as a standing stakeholder in every architecture decision.

The block that binds the technical substrate to the obligations of a regulated firm.