How I came to this work

I've been doing some version of governance work for twenty years, across organizations of varying size and configurations.

When I was in my mid-twenties, I did the foundational work of my career at a large international architectural and engineering firm (RTKL — long before the Callison merger, around the time of the original ARCADIS acquisition).

I designed and implemented a CRM system firmwide — from nothing. At the time, the firm had no CRM and little in terms of standard marketing process. I implemented standards — marketing governance in truth — across 10+ offices world-wide.

A substantial part of that system held for ten years, through the acquisition and later merger. I know because they invited me back years later to evaluate new modules of the same ERP, and we discussed what had held versus not.

What that project actually was, in retrospect, was a structural governance engagement disguised as a technical implementation.

That pattern — structural engagements disguised systems — repeated across the two decades that followed.

I was brought in to build or fix a system, when what was actually not working was the structure.

Systems don't solve what people think they solve. Systems require stability. They don't create it. They shine a spotlight on every nuance of your incoherence.

Durability is the key measure of success for my work — systems or otherwise.

System durability requires designing for real humans, and real conditions, but looks less rigorous because it contains flex and isn't built on false deterministic promises (like the sort your favorite AI tool feeds you daily).

The question to ask yourself: Are you expecting your system implementation to solve something upstream, process related, that is undefined or unowned?

Working across that many organizations under real operational pressure taught me what breaks first when structure has not been designed to hold.

Structural failures are often blamed on commitment, communication, systems, tooling, or interpersonal issues long before authority, ownership, and decision rights are examined.

But the patterns are consistent and predictable.

• Ambiguous authority means decisions stay open, route sideways, and collapse at the top.
• Unclear ownership means the people doing load-bearing work absorb consequences they did not create.
• Urgency as an operating model redirects capacity into containment that reads, from the outside, as execution failure.

These issues are not about which application you're using or how you're resourced. They are structural.

Once you see structural design, it becomes very hard to unsee — so eventually I stopped offering technical implementations as the entry point for my work.