Get it right > be right.
What is right is subjective, to the individual, the team, the organization. The job is not to arrive with my version of right and prove it. It is to understand what right looks like for the work in front of us, and reverse-engineer from there.
The Double Diamond.
The model isn't mine. The British Design Council drew it in 2005, after studying how the best teams actually work. But the first time I saw it, it just described how I'm already wired. Two diamonds: in the first you explore the problem wide before you name it; in the second you explore the solution wide before you build it. Each one opens up, then narrows to a point of clarity.
Discover
I spend time in your real week: the mental calorie audit, the friction map. We go wide on purpose, surfacing where the effort actually goes and the friction you've stopped noticing. The diagnostic is the work, not a precursor to it.
Define
Then we narrow to the one problem worth solving first, and what good looks like for it, yours specifically. By the end we both see where AI belongs in your week, and where it does not. This is the moment most people skip.
Develop
Now we open back up on the how. The grounding that holds AI in your context (voice, constraints, handoffs) and an agent, if one earns its place. We explore the shapes a solution could take before committing.
Deliver
We converge on the build that holds in your environment, and you walk out with it, plus the muscle to build the next one. The code transfers to you.
Two failure modes I design against: converging too early and solving the wrong problem beautifully, or never leaving Develop and never shipping at all. The discipline is holding both diamonds, in order: explore, decide, explore, decide.
Four moves, one work.
The grounding is custom every time. The methodology is constant. Identify your good, then reverse-engineer toward it.
Identify your good
What does your week actually look like, and what does AI well-deployed mean for you, specifically? Good is named before anything is built.
Reverse-engineer toward it
Once your version of good is named, the work is structured backward from it. The method is constant; the path is yours.
Build the grounding
Produce the grounding artifacts that hold the AI in your reality: voice, constraints, handoffs, an agent if one is called for.
Transfer the capability
You walk out with the artifacts in hand and the muscle to keep building them. The dependency does not stay.
How an engagement runs.
The same lens, dialed to where you are. Most leaders move through all three over time.
I build the system for you. You define what good looks like; I reverse-engineer the path and build the grounding.
I teach you to build it yourself. Concept to a working agent in one structured session, with the muscle to continue.
I coach you through execution. Ongoing access, monthly working sessions, and on-call time when you hit a wall.
Eight principles.
Each one stands alone, and each one points at the same lens.
Diagnosis before decoration
Every engagement starts with what is actually broken, not with what is being sold. The first deliverable is always a real diagnosis.
Systems before surface
An agent is a system intervention, not a feature. If the workflow underneath cannot absorb it, it will fail no matter how well it is built.
One size fits one
Every workflow is custom, so every build is custom. Even a proven agent off the shelf gets toned to your voice and tuned to your channel until it is yours. The methodology is reusable. The fit never is.
Teach while we build
Capability transfer is a delivery requirement, not an upsell. You work alongside the build, not adjacent to it. The goal is capability, not dependency.
Ground it in your good
Good is subjective to the person, the team, the org. We help you make yours explicit, through handoff docs and prompt libraries, the places we collect the dots to connect the dots, so AI supports you in one-size-fits-one ways.
Hold the line
No PII. No scoring people. No agent standing between a person and a decision that affects their livelihood. The boundary is design, not marketing.
Move at the speed of the buyer
The category window is open. Committee approvals and alignment cycles do not set the pace. The buyer does.
Hope is not a strategy
The practice exists to give people the how, not just the why. Anyone can name a problem. The work is in the path forward.
Your grounding lives in artifacts, not memory.
Plenty of enterprises turn model memory off for security, and assume that puts one-size-fits-one out of reach. It does not. At S&P Global, the work was realizing real AI outcomes with memory disabled, by moving the grounding out of the model and into artifacts the team owns.
Ground it in your good
Your version of good lives in a document you control, not in a memory the vendor can switch off. The model reads it in every time.
Handoff documents
Context travels between sessions, tools, and people, so nothing important is lost at logout, and the next person starts where the last one left off.
Prompt libraries
The reusable moves are captured, shared, and improved over time. We collect the dots so the team can connect the dots, on demand, by anyone.
Every engagement is a dividing line.
If the work does not produce a before and an after for you, it is not a Whiterock Road engagement. That bar is how I know when the work is finished.
AI was a tool I kept meaning to use better.
It is the lens through which my work flows.
Questions about the method.
What method does Whiterock Road use?
The Double Diamond, a design method from the British Design Council. You explore the problem before naming it, then explore solutions before building. It guards against the two failure modes most teams hit: solving the wrong problem beautifully, or never shipping at all.
What is grounding?
The artifacts that hold AI in your context: voice, constraints, handoff documents, and prompt libraries. It lives in files you own, not in model memory. At S&P Global, that was how real AI outcomes happened with memory disabled, by moving the grounding out of the model and into artifacts the team controlled.
Will AI still work if our company turns off model memory?
Yes. Plenty of enterprises turn memory off for security and assume one-size-fits-one is out of reach. It is not. The grounding moves out of the model and into artifacts your team controls, so your context survives logout and security limits.
What do I walk away with?
A working artifact built for your context, plus the skill to keep building. Every engagement is meant to produce a clear before and after.
The method only matters once you begin.
Name the friction you keep hitting. We will start there.