Pillar I Deep dive
Design for the outcome, not for the journey
“Transformation isn’t the goal. The outcome is.”
Organisations spend years on journeys whose destination was never explicitly defined. They set up a Transformation Office and measure progress by activity instead of outcome. The only question that matters: which company do you want to be on January 1, 2030? Work backward from there. Anything that isn’t enforceable from that future to today doesn’t matter yet.
Backward design forces choices. It separates what you must be able to do in five years from what you still enjoy doing today. It exposes legacy optimisation for what it is — comfortable distraction. The choice between reduction (making existing processes better) and addition (designing from a new outcome) determines your market position in ten years, not your quarterly numbers.
I apply this in CTRM migrations, Dutch pension-reform transitions, national rail programmes and global operating-model redesigns. The question is always the same: do you start at the vehicle or at the destination?
Where this lands in your world
Commodities & Trade
CTRM modernisation starts with "what must the desk be able to do in five years?" — not the vendor shortlist.
Maritime & Logistics
Port digitalisation asks for a cargo-flow design across the whole ecosystem — not a single TOS upgrade.
National Infrastructure
Rail-2040 programmes stall without an explicit outcome definition that survives forty years.
Industrial & Engineering
Operating-model transitions in multi-site manufacturing start at global capability — not at site IT.
Pensions & FS
The Dutch pension reform is framed as "moving data". The real question: which fund do you want to be on 1-1-2028?
Pillar II Deep dive
Architecture determines outcome; tools don’t
“Model × Harness × Persistent Memory. Three pillars, or no flywheel.”
Most enterprise AI implementations are better RPA with a language model on top. They look spectacular in demos and collapse in production. The reason is consistent: the architecture is missing two of three pillars.
Model is what demos sell — which frontier model, which prompt strategy, which agent loop. That is one third of the problem. Harness is the orchestration layer that connects the model to tools, data, process and compliance. Memory is the ability to learn over time — what was decided the day before yesterday, what patterns formed over the last six months, which user prefers what. Without memory, your AI restarts every morning like a colleague with amnesia.
The three together form the flywheel: better decisions produce better data, which sharpens the system, which improves the next decision. Miss one, and you have an expensive chatbox.
Where this lands in your world
Commodities & Trade
Trader copilots fail without CTRM coupling (harness) and positions memory. The model alone is theatre.
Maritime & Logistics
Port AI must talk to TOS, customs and carrier systems. Without a harness, it’s a conference demo.
National Infrastructure
The OT/IT bridge is the harness. The asset register is the memory. Miss one and you’re still in the hype phase.
Industrial & Engineering
PLM × MES × ERP × AI is the triangle the Mittelstand keeps underestimating. They buy the model and forget both harness and memory.
Pensions & FS
Scenario engines (model) × administration and supervision (harness) × forty years of participant history (memory). None of them optional.
Pillar III Deep dive
Value lives at the seams
“Incumbents optimise their process. Disruptors optimise the handoff.”
Large companies optimise their own process. Start-ups optimise the customer experience across silo’s. That’s where the waiting time lives. That’s where the errors live. That’s where the friction lives. And that’s where the profit lives — for whoever can see it.
Amazon didn’t disrupt shipping by shipping better. Amazon saw that a shipper’s pain isn’t in a single leg but in the coherence between legs. The same logic holds wherever two systems, two teams or two organisations meet. Front office and middle office. Operator and regulator. Pension board and administrator. Engineering and manufacturing.
Daisy-chaining isn’t a slogan. It’s the discipline of explicitly designing every handoff — latency, data quality, accountability. Skip it and you declare the seams secondary. Do it and you leave the field with the profit.
Where this lands in your world
Commodities & Trade
Front office ↔ middle office ↔ logistics. Most errors, delays and rejections live in those handoffs.
Maritime & Logistics
Liner ↔ terminal ↔ customs ↔ barge/rail/truck. Daisy-chaining is literally the industry.
National Infrastructure
Operator ↔ supplier ↔ regulator. The seams are political, not technical. Which is precisely why they go undesigned.
Industrial & Engineering
Engineering ↔ production ↔ supply chain ↔ aftersales. The digital thread almost always loses a link.
Pensions & FS
Fund ↔ administrator ↔ participant ↔ regulator. The Dutch reform exposes every seam. Few funds have explicitly designed them.
Pillar IV Deep dive
Mastery over method
“A tennis manual doesn’t play the game for you.”
Agile isn’t a goal. Project plans aren’t mastery. Frameworks are tools, not religion. Mistake the tool for the work and you disappear into ritual — stand-ups that move nothing, sprints that don’t sprint, steering committees that don’t steer.
Choosing a method is a question of uncertainty. High uncertainty — unknown problem, unknown solution — needs adaptive cycles. Low uncertainty — known outcome, known path — needs tight execution. Both mistakes are expensive: ritual Agile on a regulatory migration wastes; a rigid Gantt on an AI pilot delays. The question isn’t which method, but which uncertainty.
Mastery lives in judgement. Someone who knows the game picks the stroke per situation — not per manual. That holds for a programme manager on safety-critical infrastructure as much as a product owner on an early AI stack. Context chooses method. Never the other way around.
Where this lands in your world
Commodities & Trade
Trading tech is high uncertainty — Agile works. Regulatory migration is low uncertainty — don’t make it Agile.
Maritime & Logistics
Port programmes frame everything as a "change project". Much of it is just governance — and that isn’t change.
National Infrastructure
Rail and energy already operate safety-first. Layering an Agile cult on top is waste.
Industrial & Engineering
Manufacturing learns from sports teams and coaching, not Scrum certifications. Craft people see through ritual.
Pensions & FS
Pension boards don’t want a burn-down chart. They want certainty of outcome. Dare to say "no Agile" when the work demands certainty.