I do not publish identifiable client assignments or a public employment history. What I can show is the structure of the work: the question beneath a proposal, the evidence that matters and how a responsible decision might be made.
The decision patterns below are illustrative, not accounts of engagements or outcomes achieved for named or unnamed clients. They are drawn from common operating challenges in confidential and complex organisations. The ten problems that follow them are from the wider range of the work, written up without the detail that would identify an organisation.
These examples show why CIO and CTO work cannot be reduced to an IT checklist: systems, suppliers, information, teams and decision rights change together. Some material describes anonymised work; some is explicitly illustrative. Both are labelled, so a reader can distinguish experience from a proposed method.
The office needs another dashboard because reports take too long.
The underlying sources, entity definitions, reconciliation steps, exception handling, data ownership and whether the numbers mean the same thing to the people using them.
Resolve the authoritative records and the responsibilities before investing in a presentation layer.
A supplier is reliable, so renewal seems straightforward.
Contracts, data portability, credentials, integrations, key people, business continuity, knowledge transfer and realistic transition costs.
A deliberate decision about the acceptable dependence and a credible exit path.
People exchange documents efficiently by email, but there is no single consistent view of access.
Purpose of sharing, identity verification, permissions, transmission routes, copies held by third parties, retention and revocation.
A documented sharing and approval model that fits the actual professional workflow.
One experienced colleague keeps a complicated process running.
Unwritten procedures, dependencies, access ownership, recovery documentation, approval authority and who can act during absence.
Continuity that has been transferred and tested, not simply written down.
Personal accounts, home systems and business communications have grown into an interconnected arrangement.
Account recovery, device access, delegation, advisers and household service providers, remote access, communications boundaries and specialist escalation needs.
A proportionate set of responsibilities and controls, with specialised protection or incident response assigned to qualified providers where necessary.
A provider and internal team agree on a substantial programme and the board is being asked to approve it.
What is actually being bought, what other approaches exist, real total cost, readiness, evidence of the proposed benefit, risk allocation and exit conditions.
A clear, testable board decision: proceed, reduce scope, stage the commitment, or postpone.
Every one is written the same way: what was happening, why it mattered, what was decided and what came of it. Where the same question arises in a fiduciary or private-office setting, that is noted.
A legacy estate that had to disappear on a deadline. An AI system that needed real limits on its authority. A model that removed a costly step from a real customer process.
Replacing a fragile collection of ageing systems before a failure made the decision for us.
An organisation in the trust and advisory sector was running on systems that had quietly stopped being safe. Documents held with no version history and no record of who changed what. Correspondence sitting on a server the manufacturer no longer supported. Years of scanned paper that could only be found by someone who already knew where it was. And a piece of software that nobody left in the business knew how to rebuild.
None of it had failed yet. That is the normal position and it is the dangerous one. A system can look healthy right up until the moment the one machine, or the one person, keeping it alive disappears. In a regulated business the day it finally goes tends to be an audit or an incident rather than a quiet Tuesday, and by then the choice has been made for you.
Move the whole estate on a fixed deadline rather than repair it piece by piece. Doing it gradually would have meant paying for the old arrangement and the new one at the same time, and carrying the same risk for longer while doing so.
Everything moved, on schedule. The unsupported server went. The software nobody could rebuild was rebuilt, so it no longer depends on a single machine or a single memory. The paper archive became searchable text. Reporting moved onto a platform the organisation itself controls.
Finding a document stopped being a search and became a lookup. Retiring the old systems retired what they cost to license. Most of the intended users were working in the new systems quickly, which is what actually decides whether a migration worked or merely finished. And recovery was not assumed. It was demonstrated in an exercise.
The same question arrives as confidential documents made searchable: staff cannot retrieve old records quickly enough, so an AI archive is proposed. What to examine is document classification, client and entity separation, permissions, traceability of answers, provider processing, retention and human review. A useful decision is a controlled search and retrieval approach that respects access entitlements and makes uncertainty visible.
One component survived only as a compiled artefact, with no source and nobody left who had written it. It was reverse-engineered and containerised, which removed the dependency on one host and made it reproducible from a build file instead of from institutional memory.
The scanned archive went through optical character recognition and was indexed for full-text retrieval. Scan quality varied enormously across it, so the indexing had to tolerate poor source material rather than assume clean text.
Reporting was rebuilt on a cloud analytics platform under the organisation's own tenancy. The licensing reduction came mostly from retiring overlapping products, not from renegotiating any single one of them.
Recovery was tested against a simulated attack, measuring how long a restore actually took and how much recent work it lost, rather than accepting a documented target as evidence that either number was true.
The organisation is not named. Only the problem, the decisions and non-identifying outcomes are described here.
When AI can read company information and take action, its access deserves the same scrutiny as a powerful employee account.
Organisations were connecting AI systems to their own documents, their own tools and, increasingly, to the ability to do things rather than only answer questions. The connection is usually made by whoever is closest to the problem, quickly, and to be helpful.
Giving an AI system access to a tool is much closer to giving a new employee a company account than to installing an application. It can read whatever that account can read and act wherever that account can act, without any of the judgement about consequences that a person brings, and without any reluctance to do something irreversible.
Treat such a system as privileged infrastructure from the beginning rather than as a productivity feature that the rules would catch up with later. In practice that means deciding what it may see, what it may only suggest and what it may actually carry out, before anyone chooses a model.
The questions stop being about the model and start being about authority. Who is this system when it acts? Where do its requests travel, and which other companies handle them on the way? What happens when a document it reads contains instructions written to manipulate it? Can anyone reconstruct what it did afterwards, and stop or reverse it?
Security, identity and AI governance stop being three departments with three budgets and three different answers. Settled in advance, this is an afternoon's conversation. Settled afterwards, it is an incident.
The same question arrives as AI being used before the board has decided: useful tools have appeared in everyday work with no coherent approval route. What to examine is the real workflows, data categories, staff needs, identities, tool terms, action permissions, logs and escalation. A useful decision is an adoption path that makes safe use easier than informal workarounds and reserves consequential authority for the right people.
The control surface is agent authorisation: explicit separation of read, recommend and execute, with a distinct workload identity per agent rather than a shared service account, short-lived credentials and least privilege on every tool binding.
Reconstruction requires telemetry at four points: which model served the request, which tools were called with which arguments, what data was accessed, and what changed as a result. Without the fourth, an investigation can describe intent but not effect.
External content an agent reads is untrusted input that may carry instructions addressed to the agent rather than to the reader. Treating retrieved documents, web pages and email bodies as data rather than as instruction is a design decision, not a filter that can be added afterwards.
Provider governance covers subprocessors, retention, training use and the jurisdiction in which processing happens, and it has to survive the provider changing any of them.
Everyone in the marketplace was waiting on the same thing: somebody driving out to measure the job.
Quoting this kind of work meant sending somebody out to look at it first. The homeowner waited days for a number. The trade firm wrote offers by hand, and most of those offers never became work.
That visit was most of what an estimate cost to produce, and it was being spent on jobs that mostly would not happen. Both sides of the marketplace were paying for it, and both were waiting on it.
Stop trying to predict the price. Predict the size of the job instead. Size is a physical fact recorded on thousands of completed projects. Price is an opinion laid on top of it, and opinions are much harder to learn from.
A model trained on completed projects estimated how big a job was directly from its description, so the scale of the work could be established without anyone travelling to measure it. A second method addressed the other complaint: three quotes arriving with three very different numbers on them.
Evaluating a job became cheaper for the customer, and offers could be issued immediately rather than after days of exchange.
The size model is supervised learning over completed projects, with job size as the target rather than price, which keeps the label objective and removes the pricing behaviour of individual firms from what the model learns.
The convergence method is polynomial interpolation over historic offers, which strips out per-firm bias and narrows the range to something a customer can act on rather than arbitrate between.
Underneath both sits a multi-year data strategy that decided what the models were permitted to learn from. A model predicting job size is only ever as good as the records it was given, and those records are a product decision made years earlier.
Neither method is described in full here, and the company is not named.
Where the technology was the easy half, and the difficulty was in everything around it.
One drone is an engineering problem. A fleet of them holding a shape in the sky is a coordination problem wearing the same clothes.
Flying a single aircraft reliably is a solved problem with parts you can buy. Flying many of them together, in a deliberate pattern, in public, is not.
Almost none of the difficulty is flight. It is knowing precisely where each unit is, keeping the information flowing honestly at distance, and having already decided what happens when one of them stops answering while it is still in the air.
Design the failure behaviour first and the choreography second. What a fleet is allowed to attempt should follow from what it is guaranteed to do when something goes wrong, not the other way round.
Battery capacity sets flight time, flight time sets what patterns are possible at all, and the lights have to be bright enough to read from the ground while staying light enough to carry. Those constraints, taken seriously, decide the design long before any creative choice does.
Venture work, still being built. The interesting part has consistently been everything that has to be true before anyone is permitted to take off.
Centimetre-level positioning, telemetry that stays reliable at range, and power budgets that bound the whole design. The safety model is defined in terms of what each unit does autonomously when it loses contact, not in terms of what an operator will do about it.
Current venture work. Nothing published yet.
Communication data revealed which people actually held the teams together, without the analysis becoming a way to watch anyone.
Every company has a formal structure and a real one. The formal one is published. The real one is visible in who actually talks to whom, and it is usually nobody's job to know it.
Decisions about reorganisation, succession and where to place effort were being made against the published chart, which is the less accurate of the two descriptions and the one that hides its errors.
Map the communication patterns across a large software business, and design the privacy boundary before running the analysis rather than after seeing what it produced.
The map surfaced people holding entire functions together while sitting nowhere near the top of the chart, and showed precisely where information stopped moving between teams.
The same technique is a surveillance tool if handled carelessly. The genuinely hard part was not the analysis. It was building something that could answer questions about the network without ever becoming a way to watch an individual, and that sat inside privacy law rather than alongside it.
The graph is built from message metadata only, never content: who corresponded with whom, how often, in which direction. Structural measures over that graph identify brokers between otherwise weakly connected groups.
The privacy design does the real work. Results are reported at group level with minimum-size thresholds, purpose is fixed before collection rather than discovered afterwards, and no view in the system resolves to a single named person. That constraint removes some analyses entirely, which is the correct outcome.
Why two things moving together does not mean one caused the other, and why product teams lose money to that mistake.
Ice cream sales and murder rates rise and fall together. Nobody concludes that ice cream causes murder, because the summer is obviously causing both.
Product teams make exactly this mistake constantly, with variables where the summer is not obvious. A feature correlates with customers staying, so it gets invested in. The hidden cause is that already-committed customers are the ones who go looking for the feature.
Before spending against a correlation, look for the thing that could be causing both sides of it. This is cheap to do and it is almost never done, because the correlation already agrees with what somebody wanted to build.
Framed this way, most data-driven product work turns out to be the search for hidden causes wearing a different job title.
The mistake is not random. It sends investment in a predictable direction: towards whatever the most engaged customers already do, and away from whatever would have brought new ones.
The formal name for the hidden third variable is a confounder, and the discipline for handling it is causal inference. The practical tools are controlling for the suspected common cause, stratifying the population before comparing, and preferring an experiment over an observation whenever one can be afforded.
Three problems that were not solved by asserting anything. Somebody had to go and take the measurement.
Support teams are sized by last year's headcount plus a percentage. There is arithmetic that answers the question properly.
Operations teams are usually sized by intuition. Last year's headcount, plus something for growth, minus whatever the budget will not carry.
This works until it abruptly does not. Waiting times do not degrade gently as a team gets busier. They hold steady, and then they go vertical, and by the time a backlog is visible on a report it is already structural.
Use the numbers the team already has. How much work arrives, how fast it is handled, and therefore where the cliff is, before anybody drives off it.
The staffing conversation stops being a negotiation about opinions and becomes a calculation with a defensible answer, including the uncomfortable one: that the team is closer to the edge than anyone thought.
Operations teams almost always already hold every number this requires. They very rarely use them to answer the staffing question, which means the cliff is usually found by going over it.
The model is queueing theory: arrival rate, service rate and the resulting utilisation. Waiting time rises non-linearly as utilisation approaches capacity, which is why a team at ninety per cent load behaves nothing like a team at seventy per cent, and why headcount planned on averages fails at the peak.
Two people in the same city, on different providers, whose messages crossed a continent and came back.
Two people in one city, using different internet providers, sending each other a message. The message travelled abroad and returned, because there was nowhere at home for the two networks to meet.
Everything domestic was slower than it needed to be, and every provider was paying a foreign carrier to move local traffic on a long detour.
Build the meeting point. Almost none of the difficulty is technical. It is persuading competitors to sit in the same room and to trust whoever operates the neutral ground between them.
Once it existed, domestic traffic stayed domestic.
Delay fell for everyone in the country at once, and so did the transit bills that had been paying to send local traffic abroad and back.
An internet exchange is a neutral layer-two fabric where networks peer directly rather than paying for transit. The engineering is modest. The governance model, deciding who operates it, on what terms and with what guarantees of neutrality, is what determines whether competitors will connect to it at all.
A national argument nobody could settle, because nobody had taken the one measurement that would have settled it.
A national policy debate assumed the population was barely online. The available statistics could not settle the question either way.
Public money was about to be directed at a problem that might not have existed in the form everyone assumed.
Go and count. The regional roads were driven and the wireless networks in range were counted along them.
Nine per kilometre, on average. Connectivity turned out to be comparable to countries that had never thought to doubt themselves.
The policy question stopped being how to get people connected and became what to do with a population that already was. Almost every argument that cannot be settled turns out to be missing one measurement nobody thought to take, usually because taking it looks like too much trouble.
The survey combined a geographical count of wireless networks observed along regional road transects with household and individual usage sampling, so that a physical measurement could be set against what people reported about themselves. Where the two disagree, the disagreement is usually the finding.
Every business customer sat on one estate, and the estate had to move.
A software service used by business customers in several countries was running on infrastructure that had to be left behind. Every customer sat on the same estate, so there was no quiet corner to practise on and no group who could be moved first without anyone noticing.
A migration done gradually means running two estates at once, paying for both, and keeping them consistent while the business carries on selling. The longer that window stays open, the more of the organisation's attention it takes, and the more places a difference between the two can hide.
Move the whole thing quickly, then change how changes reach it. Speed was not bravado. It was the way to keep the period of two truths short.
The service moved to a new data centre in a matter of months. The single large application it ran on was broken into containers on rented infrastructure, so it no longer depended on the machines underneath it. Releases stopped being occasional large events and became something the team could do continuously. Customers who could not use the shared arrangement were given a private one.
Outages fell, and so did the time people spent waiting on the operations team. The more durable change was that shipping something stopped being an event that needed planning, which is what decides whether a team can respond to a customer in the same week.
The application was containerised with Docker and run on rented infrastructure rather than owned machines, which is what made the estate portable at all. The migration was possible quickly because the target was a known quantity by the time it started, not because the move itself was rushed.
Continuous integration and delivery came afterwards rather than first. The order matters: a pipeline that deploys reliably onto infrastructure nobody trusts mostly produces faster disappointment.
The organisation is not named, and no customer is identifiable from anything here.
Five pieces of work from the wider range, kept because the model was never the hard part in any of them.
AI works best where an enormous amount of material already exists. Smaller languages show what happens when the data simply is not there and has to be created, carefully, by people.
Synthetic voices sound convincing in the major languages because they were trained on an enormous amount of recorded speech. A language spoken by a few million people has a tiny fraction of that, and the regional variety most of them actually speak has less again. Almost everything that makes the problem hard follows from that one shortage.
Start with the standard. The written language is built on one variety; the people who will listen grew up with another, and the two were never fully reconciled. Train a voice on the standard and you get something that is correct on paper and instantly wrong to anyone who grew up with it, a bit like an English voice that had only ever read Victorian novels.
Then the spelling withholds what the voice most needs. The spoken variety carries vowel sounds and vowel lengths that the standard alphabet simply does not write down. The model is handed text that is missing the very information it needs to sound right, and has to infer what nobody wrote.
The alphabet also writes several single sounds as pairs of letters. Software that reads letters one at a time turns one sound into two. The result does not sound like an accent. It sounds like somebody spelling a word out loud.
Ordinary speech then borrows heavily from the neighbouring languages and from English, often several times in one sentence. For each borrowed word the system has to decide which set of pronunciation rules applies, and every wrong guess is audible immediately to a native ear.
None of this can be bought. No provider is going to prioritise a language of a few million speakers, so the recordings, the transcriptions and the pronunciation dictionary have to be built rather than licensed. That is the work: assembling clean speech data, marking the sounds the alphabet leaves out, and teaching the system where one language stops and a borrowed word begins.
And the final test is not a number. Whether it sounds right is settled by people who grew up hearing it, which makes evaluation slow, human, and the most honest part of the whole process.
Before any of it can be sold, the pipeline has to be able to say which model produced a given piece of audio, what it was conditioned on, which provider served the request and what that provider retained. That means formal model evaluation so provider choice is evidenced rather than assumed, provenance carried through every stage rather than reconstructed afterwards, more than one provider so that none becomes too deeply embedded to replace, and close cost control, because inference bills nothing like hosting.
The data work underneath is a pronunciation dictionary and a phonetic annotation layer that records the vowel qualities and lengths the orthography omits, plus digraph-aware tokenisation so that letter pairs are handled as single phonemes rather than as two letters. Borrowed words are tagged by source language so the right pronunciation rules are applied to each.
Venture work. Not published, and the venture is not named.
Some organisations want what modern AI can do without sending confidential records to an outside company. That is a question of how the system is built, not a reason to avoid AI.
Some organisations cannot send their records to anyone else's cloud. Not reluctant to, cannot. The confidentiality obligations are the product, and a third-party processor is a category of risk they are not permitted to accept.
So the interesting constraint is being able to ask a question of decades of documents with nothing at all leaving the premises: the models run on hardware in the building, the scanned paper has to be turned into text before any of it can be searched, and every answer has to point at the document it came from rather than paraphrase it into something plausible.
The measure of success is unusual. Nobody is impressed by the technology. They are impressed that a question about a file from decades ago now takes seconds, and that nothing left the premises to make it happen.
Work under confidentiality. The sector is named; the organisation is not.
The useful model was not the impressive one. It removed a costly step from something a real customer was waiting on.
Inside a consumer services marketplace, owners, trade firms, recruiters, property managers and insurers were all held up by the same thing: somebody driving out to measure the job on site. That visit is most of what an estimate costs, and most estimates never become work.
So the first question was not what the job should cost but how big it is. A supervised machine learning model trained on completed projects predicted job size directly from the record, which removed the visit and much of what evaluation cost the customer.
The second problem was spread: three quotes arriving with three very different numbers on them. A second method read the historic offers, took out the bias of any individual firm and narrowed the range, so a quote could be issued immediately rather than after days of exchange. Underneath both sat a multi-year data strategy, because a model predicting job size is only ever as good as the records it learned from.
Data can show how an organisation really works. The same data becomes surveillance if the privacy boundary is drawn badly, and that boundary has to be drawn first.
Inside a software business, the most interesting model was not customer-facing. It read the company's own communication graph and surfaced the people holding entire functions together while sitting nowhere near the top of the chart.
That technique is a surveillance tool if handled carelessly, so the real work was designing it to answer questions about the network without ever becoming a way to watch an individual. Consent and purpose, settled before the analysis runs rather than after it produces something interesting.
Most of the AI here is invisible. It exists so that strangers can deal with each other safely, and so that something in the air stays inside its limits.
On a consumer platform built around vehicle identity and local services, almost none of the AI work is a feature. It is verification, privacy safeguards, moderation at a volume no team can read, and automation of the service flows underneath, all of which exist so that strangers can transact without either of them being exposed.
On drone fleets it takes a different shape again: AI-assisted deployment and coordination, reusable templates so a show is planned rather than improvised, and automation that has to stay inside hard safety constraints. A model that is merely usually right is not acceptable when the failure mode is airborne.
Current venture work. Nothing published yet.
These patterns demonstrate the questions I believe a responsible adviser should ask. They are not references, testimonials or evidence of a particular engagement. The more direct evidence of my perspective is the range of disciplines I can connect and the way I approach a real question when presented with evidence. Relevant professional background may be discussed privately, within appropriate confidentiality limits.
See how the advisory work is structuredNational systems for ministries, agencies and internationally funded programmes: e-government, labour market, health, foreign affairs, emergency telecommunications. Heavily scrutinised, slow to move, and where the governance habits come from.
Built for a public administration ministry, with the migration, workflow design and business-process definition that a government portal actually consists of.
Designed so that ministries and agencies could actually exchange data with each other, with the legislative review needed to make a shared public data system lawful as well as functional.
Assessment of a national health ministry's systems, then the design of how the data, the network and the services behind a country-wide health portal would fit together.
Auditing information flows, data classification and access levels across a foreign ministry and its diplomatic missions, then designing the security around them.
Analysing a national education-to-employment value chain in technology, then building the interventions and the portal that connected the two.
Radio watch-keeping, vehicle tracking and incident reporting for a humanitarian operation. The first job, and the one that made everything afterwards feel calm.
Funders, agencies and institutions are not named here. They are on request.
Does one of these resemble a decision you face?
A short outline of the issue and timeframe, without private information, is enough to explore whether an independent view would help.