Questions I get asked

What do you actually do?

I build the layer AI runs on, and the agents on top of it.

Concretely that is four things, in this order: the data foundation, meaning lineage you can audit and definitions people agree on; the context layer, meaning the knowledge your models can actually reach and the evaluation that tells you when it degrades; the agentic systems that act inside the business rather than describing it; and the enablement that makes an organisation able to run all three without me.

I do this as an interim CTO for companies whose product is data or AI, and as a Chief Data and AI Officer for companies that already have scale and lack an operating model.

I also do it as a forward deployed engineer, for companies that know what they want built and have nobody free to build it.

The reason I work bottom-up is that most AI programmes fail one layer below where they get blamed. The agent that hallucinates gets blamed on the model, and the cause is usually that nobody curated the knowledge it can reach. The dashboard nobody trusts gets blamed on the BI team, and the cause is usually two definitions of revenue with no owner for either.

What do you not do?

I do not run general platform engineering, infrastructure, security or SRE.

That matters because I sell an interim CTO role, and “CTO” normally implies all of it. The version I do is narrower and I would rather you know before the first call: I own the layer your AI runs on, meaning the data foundation, the context and retrieval architecture, the agentic systems on top, the governance around them, and the team that builds all four.

If your hard problem is Kubernetes, an incident-response culture, a SOC 2 audit of your infrastructure, or hiring twenty backend engineers, I am the wrong person and I will say so in the first conversation rather than the third.

On the executive engagements I do not write the code. Two or three days a week is enough to own the layer and not enough to build it, and an interim who is half in the codebase does neither job.

The forward deployed engagement is the one where I do write it. Three to four days a week, inside your repository, scoped to AI systems: context, retrieval, evaluation and the agents on top. Those are separate engagements for a reason, and picking both at once is the request I turn down most often.

Are you a CTO or a Chief Data and AI Officer?

Both, and it is the same scope described at two company stages.

Interim CTO is the framing for a younger company whose product is the data or AI system. In that company the context layer, the retrieval architecture, the models and the agents are not a support function, they are the thing you sell. Owning them is the technical core of the business.

Chief Data and AI Officer is the framing for a company that already has scale, a data team, and a cloud bill, and lacks an operating model for any of it. The work is the same. The title changes because the org chart already has a CTO in it and that person owns something else.

What is constant across both: I own the layer AI runs on, and I have shipped agents on top of it in production. What is constant in the other direction: I do not run general platform engineering, infrastructure, security or SRE.

There is a third framing, the forward deployed engagement, where I write the system rather than own the function. See what a forward deployed engineer is if the gap you have is build capacity rather than an empty seat.

What is a forward deployed engineer, and why do you call yourself one?

An engineer who works inside the customer’s codebase, on the customer’s problem, for a fixed period.

The title comes from Palantir and has since been adopted by the AI labs. What it names is a narrow thing: the person who designs the system also writes it, in your environment, against your real data. The usual alternative is an architecture document handed to a team that then discovers which assumptions were wrong.

I call myself one because the claim is testable and the executive titles are not. An interim CTO is judged on an operating model that takes a year to show. A forward deployed engagement runs 6 to 12 weeks and is judged on whether the system is running at the end of it.

The shape is deliberately narrow. I write the context layer, the retrieval, the permission checks that hold at query time, the evaluation harness and the agent. I do not run your platform, your infrastructure, your security or your SRE, on this engagement or on any other. I also do not train models, which is a separate skill I do not claim.

Three of these are running as I write this: the product I am building in stealth, and two customer engagements. I am not naming the customers or their sectors while the work is live.

The honest limit, stated because this site does not get to skip it: none of the three has a case study behind it yet. The systems on the lab page are software I wrote for myself rather than inside a customer’s repository. When a case study exists it will carry its measurement basis and name what did not work, the same as the others do.

What is a fractional Chief Data Officer?

A fractional Chief Data Officer is a senior data executive who owns a company’s data function on a part-time, fixed-term basis, typically two to three days a week for six to twelve months. The scope is the same as a permanent CDO: strategy, budget, hiring, vendor decisions, and board reporting.

The role exists because most companies between 300 and 3,000 people need executive-level data leadership before they can attract a permanent executive, and because the gap left by a departing data leader does more damage in six months than most boards expect.

The difference from a permanent hire is that the engagement has an end date and a named successor built into it from month two.

How is this different from hiring a consultancy?

A consultancy sends a team and leaves a document. An interim executive takes the seat, makes decisions that have consequences, and hires the person who takes over.

There is one of me and I am in your leadership meetings. That is the entire difference, and it cuts both ways: you get accountability and continuity, and you do not get a bench of analysts to throw at a problem in parallel.

If what you need is capacity, hire a consultancy. If what you need is someone to own the decision, hire an interim.

What size company is this for?

Roughly 300 to 3,000 people, Series C through post-IPO or private-equity owned.

Below that there is usually not enough data to govern, and an interim CDO is an expensive way to buy a dashboard. Above that the problem is a permanent executive hire with a large organisation behind them, which is a different job.

The signal that matters more than headcount: you already have a data team of fifteen or more, a cloud bill someone senior asks about by name, and a gap between what that team produces and what leadership trusts.

Will you build the machine learning models?

No.

I have put machine learning into core business processes and measured what it was worth, and sometimes the answer was that it was worth nothing. I can tell you whether yours is worth the money, whether the data underneath it is good enough to justify the attempt, and what it will cost to keep running once the project that built it has ended.

I am not the person who trains it. If someone selling you an interim data leadership mandate also offers to build your models, ask which of the two jobs they will be doing on the days they are with you.

Training a model and building the system around one are separate skills, and I only claim the second. On a forward deployed engagement I write the retrieval, the permissions, the evaluation harness and the agent. The model itself is something I select, measure and replace rather than train.

What do you charge?

The AI readiness teardown is a fixed fee for three weeks, published on the engagement page. You keep the written assessment whether or not you do anything else with me.

Interim and fractional mandates are quoted per engagement, based on days per week and duration. I publish a minimum engagement size rather than a day rate.

The reason is not coyness. A day rate invites comparison against agency-supplied contractors and against internal salary arithmetic, and both comparisons measure the wrong thing. What you are buying is a decision-maker with a mandate, so the number should always arrive attached to the scope.

I do not work through intermediaries on a commission basis.

Do you work in German?

Yes. I work in English and German, and I am based in Berlin.

Most of my clients are in the DACH region or are European scale-ups with a German entity, so the regulatory context I work in daily is the European one: GDPR, Article 28 processing agreements, and EU AI Act risk tiering.

When are you the wrong person to call?

Several situations, and it is cheaper for both of us if you recognise yours here.

You are pre-seed or seed. There is no data to govern yet. You need a competent analyst and a warehouse, not an executive.

You want staff augmentation. On a forward deployed engagement I take one AI system to production and then leave. I do not fill a seat on your team, and I do not write your transformations or your pipelines.

You need a board deck by Friday. Every engagement I run ends with something running, hired, or switched off. None of them ends with a slide.

You want the data to confirm a decision already made. This happens more than people admit, and I am an expensive way to get an answer you have already chosen.

You are hiring for a permanent role. I leave. The leaving is the point, and the last month of every mandate is spent handing over to my successor.