Most organizations treat important decisions as if the right answer exists somewhere and just needs to be found. So they study it. Build alignment around it. Weeks turn into months while certainty fails to arrive.

The hardest calls are rarely between a good option and a bad one. They're between two decent options. At that point, the outcome has more to do with what happens after the decision than with the decision itself.

I make decisions quickly. I used to think that was because I was a good guesser. What I do is run experiments, read the signal, and commit. Once committed, I stop questioning the call and start making it work.

Amazon Web Services

Analytics SA org · U.S. CPG field

I built the Analytics Solutions Architecture organization from scratch, then led the U.S. CPG field organization. Different scope each time, same motion: broad interest, cautious action, and a long road from pilot to production.

To cut through the stall in our biggest accounts, I gave the field one goal: Launch Every Workload.

Three words, each chosen on purpose. Launch means shipped, not evaluated and not parked in a final review. Every means all of them, the messy accounts and the underfunded ones and the deals that had stalled for two quarters. Workload means what runs in production, not what lives in a slide. A goal like that decides the small things for you: nobody has to guess the priority or escalate the edge case.

SAP

HANA launch

I helped launch HANA into a market that had been burned by database promises before. The pitch was easy. The trust was not. The work was getting skeptical enterprises from a pilot to something they would actually run.

Oracle

Exadata launch

I helped launch Exadata into a market that wasn't sure it needed it. The technology was real. The work was proving it in production, one account at a time.

Across all three, the enterprise motion looked the same: broad interest, cautious action, and organizational drag dressed up as diligence. The question was never whether the technology was ready. It was whether the customer had a path from pilot to production, and whether anyone was helping them find it.

The technology was never the hard part.

I've watched the same pattern with AI. The models are good. What stalls it is the security review that takes longer than the model stays current, or the governance policy that blocks the exact use case the executives approved one floor up. None of that is a technology problem. It is the distance between what a team can show in a demo and what anyone will run in production.

Closing that gap is field work. It takes technical credibility, pattern recognition, and the ability to hold trust with both the person who signs the paper and the person who has to make it run, through a cycle where both will change their minds at least once.

How I run a week

The operations skills behind my own cadence: a morning brief, pre-meeting prep, an evening account review, and a workflow audit that hunts down busywork.

The operations skills ↗     How this site was built →

FUTURUM · SINE · ARCHITECTURA · PERIT · GT MMXXVI