Work · Enterprise applied AI · Platform & transformation leadership
Build systems that outlast the builder.
I build governed enterprise systems that turn local success into reusable capability and durable ownership. At AWS, that meant an applied-AI platform; at Uber, a global operating model spanning 40+ business lines and 80+ countries.
Flagship cases
Flagship cases · two different forms of the same work
01 · AWS · 2024–present
From successful local tools to shared production capability.
Useful AI workflows were beginning to reproduce authentication, integrations, deployment, testing, logging, support, and founder dependence. Individual success was creating a shared architectural problem. I redirected the work toward common foundations, explicit production controls, independent builders, and transfer from the start.
Platform architecture
Local success becomes durable only when capability can be reused, governed, shipped, and owned by others.
What I personally owned
Founding architecture, initial implementation, reusable patterns, platform standards, control design, builder enablement, release practice, and transfer design.
The tradeoff
We gave up some local speed and founder control to gain shared reliability, distributed release capability, and systems that could outlast the original builder.
Judgment preserved
A pricing-control workflow returned PASS, FAIL, or UNCERTAIN at the rule level, removing a 24-hour bottleneck while keeping ambiguous cases with specialists.
What remained
Reusable services, explicit operating practices, independent builders, and owners able to run and improve transferred systems.
Evidence boundary: Official title: Business Technical Developer III. “Applied-AI platform leadership” describes functional scope. Portfolio totals are collective; directional capacity estimates are not audited savings.
02 · Uber · 2021–2024
A global operating model, not a software installation.
Agreement work crossed legal, sales, finance, engineering, regional authorities, implementation partners, more than 40 business lines, and more than 80 countries. A software-only intervention would have digitized fragmentation. I led the operating-model redesign that joined decision rights, process, technology, rollout, support, and adoption.
What I personally owned
Operating-model and transformation leadership, governance design, cross-functional alignment, delivery coordination, adoption, and executive communication.
The tradeoff
We standardized the global spine while preserving explicit exception paths where geography, agreement type, business line, or risk required legitimate variation.
Why the result moved
The 35-to-10-day outcome came from coordinated process, governance, templates, approvals, technology, rollout, and operating discipline—not configuration alone.
What it taught me
Architecture, process, governance, adoption, and ownership are not separate projects. That lesson became foundational to the platform model I later built at AWS.
Evidence boundary: The 35→10-day result is a cross-functional organizational outcome with public corroboration from DocuSign; it is not a claim of sole authorship or software-only causation.
The decision model
BoundaryFoundationControlAdoptionTransfer
Across both cases, the same five decisions recur. The model is less a delivery sequence than a test for whether a system can become trustworthy, reusable, usable, and independent of its original builder.
Boundary
What is the decision?Define evidence, accountable authority, exclusions, uncertainty, and escalation before implementation begins.
Foundation
What should be shared?Build reusable services and workflow patterns instead of accumulating bespoke local wins.
Control
What makes it governable?Authentication, tests, logs, observability, rollback, support, review, and release ownership.
Adoption
What makes it usable?Roles, interfaces, training, feedback, operating burden, and specialist review paths.
Transfer
Who owns it afterward?Access, runbooks, release knowledge, change rights, incident duties, and accountable ownership.
The pattern is consistent: consequential work becomes durable when architecture, governance, adoption, and ownership are designed as one system.
Public systems laboratory
Where I test the method publicly.
The legal and clinical demonstrations apply the same model where provenance, uncertainty, review, and legitimate authority matter more—not less. They are public testbeds for bounded outputs and accountable human judgment, not claims of deployed client impact.
Status: public demonstrations, not deployed client systems, professional advice, or evidence of clinical or legal efficacy.
WHERE I FIT
When the system matters more than the tool.
I’m most useful when an organization has moved beyond isolated automation and needs technical architecture, workflow design, production governance, adoption, and long-term ownership solved as one operating problem.
For a separate private advisory relationship, read Private Advisory.