This isn’t a career summary. It’s an account of how repeated exposure to failure shaped the way I design systems.
Learning to Deliver When Failure Was Not an Option
(The Executioner)
“Ideation without execution is delusion.”
Early in my career, this was an operating constraint. Plans, lists, and ideas had no intrinsic value: work either shipped correctly or failed. Waiting for better conditions or perfect clarity was pure avoidance, not caution.
At Ipsos, I became the person projects were handed to when complexity was high and tolerance for error was low. Not because I had the most elegant solutions, but because I could be relied on to get things across the line irrespective of stress, volume, senior leadership involvement, insufficient information.
Over time, that reliability was tested in both fixing broken projects and in delivering clean ones. Some work arrived late, under-scoped, or already failing. Some was so complex, few people could grasp it. I learned quickly that fear of making mistakes was often more damaging than inaction. Progress required committing to decisions, surfacing risks early, and correcting course in motion, and that waiting for certainty spelled doom.
Execution, I learned, depends both on individual effort and on what the system allows. I focused on making work explicit and repeatable: documenting processes, building training paths & VBA powered checklists, revising workflows and keeping things as simple as possible. The goal wasn’t speed for its own sake (that was a great byproduct): it was consistency under pressure.
If execution depended on heroics, the system has already failed. If results varied based on who was present, the process was incomplete.
Everything that came later – strategy, leadership, system design – was built on this foundation. Before you can design better systems, you need to know exactly how and where execution fails.
It’s all a volumes game: pattern recognition
(The Strategist)
“The master has failed more times than the beginner has even tried.”
Moving into management roles forced a shift in how I thought about work. Execution was no longer the constraint, getting replaced by judgment. Problems stopped being isolated and began repeating themselves in different forms.
This is where I learned that success is largely an exposure volume game. With enough work, patterns form, and issues become visible before they turn into problems. Failure, in this phase, is partial, delayed, and often invisible until damage had already accumulated.
My role increasingly became one of pattern recognition – separating signal from noise, identifying which failures were instructive and which were systemic, and teaching others how to reason about tradeoffs, constraints, and second-order effects.
Processes that felt “obvious” needed to be made explicit. Expectations that lived in people’s heads had to be written down. Assumptions had to be challenged continuously, as conditions changed. And most importantly, as I moved through different regions, culture had its own impact that needed to be addressed and adapted to. I learned that consistency comes less from control, and more from shared understanding: when people understand context, they make better decisions without supervision.
This phase refined my understanding of failure as something to study, not avoid. Root cause analysis became less an abstract technique and more a habit to be used diligently. And project management risk analysis techniques made sense.
By the time I moved into roles with broader leverage, it was clear that judgment alone doesn’t scale. If consistency depends on experience, the organization is fragile.
That realization led directly to the next evolution: designing systems where good judgment is no longer optional.
Designing Systems Where the Right Action Is the Default
(The Architect)
“You do not rise to the level of your goals. You fall to the level of your systems.”
By the time I moved into roles with full ownership over operations, one conclusion became unavoidable: judgment does not scale. You cannot rely on people being experienced from day one, fully attentive at all times, or able to remember everything. You also cannot expect engagement to happen without deliberate incentives.
That is not a people problem. It is a design problem.
At Paradigm, my focus shifted from managing outcomes to designing the conditions that produce them. The question stopped being how to execute better and became how to make the correct action the easiest one, while making the incorrect one difficult, invisible, or impossible.
This meant rethinking work at the system level: defaults had to be correct; alerts had to trigger when things drifted off-script. Any place where humans were expected to “just know” became a risk surface. Any situation that required heroics or creativity was evidence of a missing rule.
The same logic applied to respondent engagement. Choice has to exist, but the desired path is designed to maximize desired results. Layouts, flows, and incentives are structured so the most valuable behavior is also the most natural one. The objective is consistency without micromanagement: minimum friction on the right path, maximum resistance everywhere else. Sustainable engagement is not encouraged; it is engineered.
My work now centers on predicting human behavior and designing systems that channel it reliably, repeatedly, and at scale.