AI systems · transformation · people

I work best before the problem is neat.

I usually enter while the goal is still forming. I talk with the people closest to the work, trace where the friction comes from, and separate the real constraint from the loudest request. Then I bring business, engineering, and leadership into the same decision. We make the tradeoffs visible, build enough to test the idea, and keep learning from delivery. I stay close long enough for the team to understand the system and own what comes next.

Listen before prescribing Make tradeoffs visible Stay close to delivery Share what we learn

3D view unavailable. The rest of the experience still works.

01 / 06

01 · Build the platform

AI Engineering

about

The person behind the work

How I got here

What each stage changed in how I work

The titles matter less than what each role taught me to notice, question, and carry into the next problem.

2017 to 2019 Learned to investigate before prescribing. Infosys, Senior Associate I learned to trace behavior, test assumptions, document what I could prove, and separate symptoms from the source of a problem.
2019 to 2020 Moved closer to the people using the system. Power Objects, Software Engineer Working directly with users, managers, vendors, and technical teams changed what I considered a good solution. The design had to fit the people and the environment around it.
2020 to 2022 Started owning the space between the request and the solution. Procentrix, Senior Software Engineer I spent more time translating needs, surfacing delivery risk, challenging requirements, and helping people make decisions before engineering moved too far.
2022 to now The system became bigger than the software. Cyclotron, Solutions Architect Architecture, AI, governance, delivery, adoption, and organizational change became one connected problem. My work now sits across those boundaries.

What working with me looks like

Trust is built in the work

Listen first

I learn how the team actually works before deciding what the system needs.

Name the tradeoffs

I make assumptions, risks, and competing priorities visible before the decision.

Stay in the work

I prototype, review, and adapt alongside the team instead of disappearing after the diagram.

Teach the pattern

I turn what we learn into reusable guidance and community, so it spreads beyond one project.

What you can expect from me

I earn trust by making the work easier to understand, the decisions easier to see, and the learning easier to share.

Listen first I start with the people doing the work. Their friction usually tells us more than the first requirements document. Make the call clear I name the tradeoffs, risks, and assumptions so people know what they are agreeing to and why. Stay through delivery I build, review, troubleshoot, and adapt with the team. Architecture stays connected to what ships. Share the pattern I turn project lessons into guidance, working sessions, and reusable practices other teams can apply.

Azure AI Foundry AI Gateways MLOps Microsoft Entra Agent Systems Governance Copilot .NET + React