About

I didn't start in a computer lab. I started in the Marine Corps.

The Corps taught me that a plan is useless without the discipline to execute it. In the field, ambiguity is the enemy. It creates hesitation, and hesitation causes failure.

When I transitioned into technology, I saw the same enemies: vague requirements, siloed communication, and reactive leadership. I realized that great engineering isn't just about writing code; it's about imposing order on chaos. I brought military-grade rigor to software delivery, and I haven't looked back.

I am an engineer first and a Director second.

I reject the idea that leadership means "graduating" away from the tools. I operate as a Player-Coach. To make high-stakes decisions about cloud architecture, you must understand the friction required to build it.

My expertise lies in modernization. I take rigid, legacy systems in regulated industries (Wealth Management, Specialty Pharmacy) and dismantle them into scalable, cloud-native architectures. I don't optimize for "shiny" tools; I optimize for resilience, maintainability, and the elimination of drudgery.

I'm still actively learning. I'm pursuing an MBA at Saint Joseph's University while taking courses in ML engineering and system design. Most Director-level candidates stopped learning years ago. I haven't.

A junior developer deleted our entire production site from Azure. The whole thing. Gone.

We had SEC regulations requiring a live site with investor information. We had backups, but they weren't stored optimally for quick restoration. The team was panicking.

I coordinated the restoration, kept the team focused, and we got the site back up. But the real work started after. We ran post-incident exercises, built guardrails to prevent it from happening again, and redesigned our backup system. We went from hours to minutes for full application restoration.

Leadership isn't about never having problems. It's about how you respond when everything breaks.

The screen is not the real world. Clarity comes from stepping away.

You can usually find me fly fishing for trout in Pennsylvania streams or training with sandbags, kettlebells, and rope flow. When you're reading water or under a heavy load, you can't think about work. You have to be present.

Fly fishing teaches patience with complex systems. You observe, adapt, and refine. Physical training builds resilience. Both translate directly to handling pressure and solving hard problems. The mind stays sharp when the body stays tested.

Engineering leadership is about two things: clarity and trust. Everything else is noise.

I reject the "managers shouldn't code" narrative. That advice comes from people who stopped building things and needed a reason to justify it. If you're making architecture decisions without understanding the friction of implementation, you're making bad decisions. Credibility matters.

My job is not to write more code than my team. My job is to multiply their effectiveness. I optimize for leverage. At SEI, we reduced post-deployment bugs by 73% and cut deployment cycles from monthly to multiple times per week. That didn't happen because I wrote more code. It happened because I removed blockers, automated grunt work, and built systems that let skilled engineers focus on problems that actually require intelligence.

But here's what drives every decision: there is always an end user. Someone who needs what we're building. When I designed CageKeeper, I didn't just track goalie saves. I thought about what goalies actually do and feel during a game. They run the offense, direct the defense, cause turnovers, make clears. They needed a way to show their total contribution, not just one metric. High standards exist because the end user deserves better.

The best leaders serve their teams, not the other way around. I code enough to maintain context, but I lead full-time. That means clearing the path, setting clear standards, and making sure we're solving the right problems. Officers eat last. Architects still code.