How I Work

Regulation defines what you must prove. Everything else follows from that.

Senior technology leadership without the full-time cost. That part is unremarkable — there are forty of us and we all say it, on landing pages that are difficult to tell apart. Take it as read.

Here is the part that isn’t, and the reason the rest of this page exists.

Most technology decisions are made in the wrong order, and the wrong order is expensive in a way that only shows up later, when someone with authority asks a question the estate was never built to answer.

The chain

Watch how a technology decision usually goes. Someone picks a platform — because a competitor uses it, because the demo was good, because a board member had heard of it. Then they discover what the platform can’t tell them. Then they build a spreadsheet to cover the gap. And then, months or years on, a regulator, an auditor, an acquirer or an insurer asks a question, and the answer has to be assembled by hand, over a fortnight, by people who are guessing — because nothing in the estate was ever designed to produce it.

The order that works runs the other way. It runs like this.

Regulation defines what you must prove. Not what you must have — what you must demonstrate. This is the distinction almost everyone misses. DORA does not ask whether you have a resilience framework; it asks you to evidence one, on demand, with dates. The AI Act does not ask whether your model is fair; it asks for the record that shows how you know. Supervisors across every regime that matters have made the same move in the same decade: from reviewing paperwork once a year to demanding verifiable, current evidence whenever they choose to look. That shift — from having to proving — is the whole game, and most technology estates have not noticed it happened.

Proof requires evidence. Real evidence. Dated, attributable, traceable to a specific obligation, produced by a system as a matter of course rather than reconstructed from memory and email in the weeks before an inspection. Evidence that exists whether or not anyone is currently looking, because that is the only kind a supervisor now trusts.

Evidence requires a data model that can carry it. This is where it breaks, every time. You cannot attest to something your systems cannot express. If “customer” means four different things in four different places — and in most organisations it does — then no governance tooling on earth will produce a defensible answer about customer data, because there is no single thing the answer is about. The model either carries the obligation or it doesn’t. No platform purchase will fix a model that doesn’t. It will only add a fifth definition of “customer.”

The tool is whatever serves the model. Once the model is right, the tool becomes an implementation detail — replaceable, negotiable, and no longer the thing your business quietly depends on. That is the goal. Not the best tool. A model good enough that the tool stops mattering.

Read that chain backwards and you have the post-mortem of nearly every failure I get called into. Buy the platform. Discover the model can’t produce the evidence. Assemble the attestations by hand. Survive the audit on adrenaline. Repeat at the next one, having learned nothing, because the lesson lives one layer below where anyone was looking.

Why nobody else says this

Look across the market for the position I’ve just described and you’ll find it empty. That’s worth being honest about, because “empty” means one of two things, and they are not the same thing.

It could mean nobody wants it.

Or it could mean nobody can say it.

A consultant can’t say it, because the consultant hasn’t built the model. Selling days means selling advice about the model — which is a different animal from having designed one, migrated one, and lived downstream of the consequences for two years. Advice is cheap precisely because it never has to survive contact with a data migration. The person who has done the migration talks differently, because they have been wrong in ways that cost money and remember exactly how.

A vendor can’t say it, because the vendor is the tool. No platform company will ever tell you the tool is an implementation detail — their entire commercial logic requires the tool to be the answer, which requires you never to ask the question in the right order. “Regulation → evidence → model → tool” ends with them as a footnote. They cannot afford to hand you that sentence.

A generalist can’t say it, because the position needs three things that rarely travel together: a control framework that separates having a control from proving it; taxonomy discipline deep enough to design a model that actually carries an obligation; and enough regulatory literacy to know what the obligation actually is before you start. Any two of those is common. All three, in one head, is not.

So the position is empty because it takes years to reach, not because it isn’t worth reaching. That’s the difference between a gap and a gift, and it’s a difference you can check rather than take on trust. If I’m wrong, I’m wrong somewhere specific.

What this means when you actually hire me

I lead with architecture, not technology. The first question is never which platform. It’s what the business must be able to prove, to whom, and what model carries that. Technology selection is the last decision in the sequence, not the first — and by the time it arrives, it’s usually obvious, occasionally unnecessary, and never the hard part. If we’re arguing about tools early, we’re arguing about the wrong thing.

I’m vendor-agnostic, and I mean it as a design property, not a virtue. Anyone can claim independence; the claim is worthless on its own. The test is whether someone leads with the model — because you can only be credibly agnostic about tools if the tool isn’t load-bearing. I’ve written publicly, more than once, that the right answer was to buy nothing at all: keep the system you have, fix the model, walk away from the migration. That’s the receipt, and it’s a receipt a vendor structurally cannot produce.

I’ll tell you when the answer is no. No, you don’t need to replace the ERP. No, that isn’t a technology problem — it’s a decision-rights problem wearing a technology costume. No, the AI pilot will not survive contact with your data quality, and I can tell you that before you spend the budget rather than after. The entire value of an independent voice is its willingness to be unwelcome in the room. A voice that only ever agrees is a cost, not a control.

I work where a regulator defines what “good” means. Not out of squeamishness — because evidence needs something to attest against. Where the regulator is absent, or adversarial, or purely political, “prove it” has no referent and my framework has nothing to stand on. Financial services, digital assets, maritime, health data, critical infrastructure: places where an outside party can and will ask you to demonstrate, and where the demonstration is the deliverable. That’s where this way of working earns its keep.

The framework underneath it

None of this is a manifesto. It’s operationalised in the Sixteen Pillars framework — sixteen control areas across four plain questions: can you see your estate, do you govern it, can you run it safely, can it change.

Every pillar is scored twice. Once for how strong the control is. Once for whether you can prove it.

That second axis is this entire page made measurable. Most assessments collapse into a single flattering number that everyone in the room can live with. This one refuses to, on purpose — because the gap between having a control and evidencing it is exactly where organisations discover, always at the worst possible moment, that their data model was never asked to carry the obligation in the first place. The two-axis score finds that gap in an afternoon instead of in an inspection.

See the framework →

Where to go next