My why

Unsurprisingly,  my “why” and the “why” behind Mechanisms for Resilience are virtually identical.

Helping organizations improve

value delivery and resilience

for navigating the unforeseeable

to thrive in a rapidly changing world

through discrete mechanisms.

I charge A LOT, but don’t cost anything.

My entire life, in the literal sense, has been dedicated to improving things. Obviously this only became apparent after many years of unconsciously doing it. During those years I had great difficulty explaining what I do, even though I had a title like everyone else. Everything made sense once I found the words “I help organizations improve”. That is what I do, that is what gets me up in the morning, that is what excites me, and that is what I am good at, regardless of the specific task, situation or level that I am working at.

The follow-up questions are predictable:

What?

Of all the possible improvement vectors, I optimize for resilience and value delivery, in that order. They are only reversed in my “why” statement because listeners find value delivery easier to grasp than resilience, and grasping value paves the way to explaining resilience, which makes it a more resilient sentence (that was fun.)

Resilience is toughness and the ability to withstand or recover quickly from difficulties. For me, this is everything.

When?

My “why” is best tuned for situations where the unforeseeable has a high probability of happening. Consequently I am more valuable to organizations needing to navigate the unforeseeable. Also, organizations most likely already have lots of people navigating what they can already see coming, and one more of those are unlikely to make a difference.

What is in it for those you work with?

Surviving, even growing, in a changing world is not enough for me. I want, for me and those I work with, to thrive in a rapidly changing world. A rapidly changing world should be a strategic advantage, not a challenge to overcome. Even more so if you can be the driver of rapid change others are trying to cope with.

How?

Pragmatic and hands-on get involved with skin in the game type of help. Using discrete mechanisms, or the right tool for the job. There is no need to use entire frameworks when only a small portion of that framework is all that is needed, and decomposing multiple frameworks into discrete mechanisms allow for an optimal rate of change, maximizing ROI of that improvement. (Buzzword Bingo, but that is the reality.)

How much?

As a young engineer, one of my first mentors, Peter Watts, taught me; “always contribute at least 10x your salary to the bottom line.” That lesson stuck with me and has served me well for many decades. With that mindset, rate is never an issue since you are always earning your own keep, and you don’t “cost” anything.