The longer version

I lead Third Party Risk Management, specifically the Applications and Reporting function, at Truist Bank. In the last two years I've led twelve system deployments across that portfolio. That is a high cadence for a heavily regulated environment—one that is only possible because I bridge the gap where most tech implementations fail: the translation layer between business and technology teams who don't quite hear each other. I sit directly on that seam, compressing friction so the roadmap moves faster.

Design on the edge

Alongside our core systems of record, my team designs and builds what I call "alternate solutions." This parallel layer of user-friendly tools, workflows, and business intelligence dashboards addresses critical needs when massive commercial platforms are too slow or expensive to configure.

These are governed assets, not workarounds. They sit inside the exact same controls as our bought systems, ensuring their outputs flow cleanly into systems of record without ever degrading into Shadow IT. Knowing exactly where the buy-versus-build line falls—and executing flawlessly when a custom build is the right answer—has been the defining through-line of my career.

Before Truist

Before Truist, I spent eighteen years at Citi running complex transformation programs: operating model redesigns, global technology implementations, and high-stakes regulatory remediations—including playing a key role in the build-out of a 300-person global operations team in eighteen months. The work I'm proudest of from that era was the long, patient business of moving institutional consensus, designing change frameworks that survived contact with a real organization, and successfully closing critical Third Party Risk matters with the OCC.

In 2019 I stepped away from the work for eighteen months. I used the time to study healthcare technology, specifically the inflection points where business models break and reform. I came back to Citi in 2021, first as a consultant, then again as a Director through 2024. The pull was the same in both cases. I wanted to be closer to execution, and I'd watched too many transformations fail at the seam between strategy and delivery. The Truist role is a continuation of that choice.

What I'm focused on now

The most compelling problem in my work right now is AI implementation—specifically, the structural piece most organizations completely miss. Because the technology is moving so fast, raw technical capability is no longer the bottleneck. The constraint is operating-model design.

Most enterprises attempt to bolt AI onto legacy processes that were explicitly built assuming a human would do the manual labor. That produces corporate theater, not an actual return on investment. The real ROI lives in fundamental process redesign—building workflows that respect current AI limitations (requiring rigorous human oversight) while remaining fluid enough to absorb what's coming next. Agent-to-agent models are arriving rapidly; a process designed around today's constraints will be obsolete tomorrow.

The most common failure mode in transformation is declaring victory at go-live. The platform hits production, the project code closes, and the team celebrates. Then adoption stalls, manual workarounds proliferate, and two years later someone funds a new initiative to fix the exact same problems. True transformation requires staying past the launch party. It requires measuring actual user adoption, tracking second-order operational metrics, and keeping the operating model alive well after the original project team has moved on.

The conversation I'm most useful in is the one that runs from buy/build/hybrid evaluation through to delivered outcomes. That's where the market currently splits. Pure consultants don't build. Pure technologists don't evaluate strategically. Most transformation people haven't gone deep enough on AI to see the architectural commitments hidden inside platform choices. I've spent the last several years closing that gap deliberately, including most of what's on this site.

The pattern I keep seeing

The most common failure mode in transformation work is declaring victory at go-live. The platform is up, the project plan is closed, the team gets promoted. Then adoption stalls, the workarounds proliferate, and two years later someone is running another transformation initiative to fix the same problems with new branding. The discipline that separates work that actually transforms from work that just performs transformation is the willingness to stay past go-live. To measure adoption rather than implementation, to track second-order effects, to keep operating-model changes alive after the original team has moved on.

I bring that same discipline to AI implementation. The questions I ask early are about what humans are still doing, why, and whether that work is what humans should be doing. Those questions are uncomfortable for most stakeholders. They're also the questions that decide whether an AI initiative produces actual return or just an impressive demo.

What I'm like to work with

Patient with the business, impatient with theater. I will fight you on the model and the operating design; I won't fight you on timelines that are within reason. I read more than I talk in early meetings. I take notes. I expect strong opinions to come with strong reasoning, and I'll push back when they don't.

Outside the office

I am an active learner and designer. I build furniture by hand, ride motorcycles on deliberately scenic routes around the world, keep plants (mostly alive), cook extensively, and build custom applications with AI. The rest of this site is where those pursuits live. The cutting boards, the flora, the travel routes, and the code repositories all stem from the same foundational practice: small, disciplined, compounding adjustments applied differently.

Let's connect

Email is best: alex.silvestre@me.com. I read everything. I reply to the conversations that look like they'll be worth both of our time, usually about AI implementation, transformation work, or what the actual operating model needs to be before the technology shows up.