The Hands-On Imperative: Why Technical Leaders Must Still Code to Drive Innovation, from Fintech to AI

The stereotype of the executive leader, detached from the day-to-day grind, making decisions from an ivory tower, is one I’ve always challenged. For nearly two decades, my journey through the demanding worlds of fintech and systems architecture has reinforced a core belief: true leadership, especially in engineering, demands a hands-on approach. As a Vice President, I don’t just guide strategy; I roll up my sleeves, contribute to architecture, and yes, still write code. This isn’t just a personal preference; it’s an imperative for driving innovation and building resilient, forward-thinking teams.

The Genesis of “Hands-On”: From Wall Street’s Trading Floors

My conviction was forged in the crucible of real-time trading systems at Deutsche Bank. From 2008 to 2017, I led the enterprise messaging middleware group, supporting mission-critical applications where milliseconds meant millions. One of my proudest achievements was spearheading the firm-wide migration from legacy TIBCO Rendezvous to Solace messaging infrastructure.

This wasn’t a project that could be dictated from afar. To understand the intricacies of migrating hundreds of applications, optimizing latency, and ensuring zero downtime in a high-stakes environment, I had to be deeply involved. I needed to understand the nuances of Solace’s guaranteed messaging, topic routing, and performance characteristics at a fundamental level. I had to get my hands dirty, working alongside the teams, debugging, and architecting solutions that would modernize the bank’s trading backbone. This hands-on engagement wasn’t just about technical expertise; it was about building credibility, anticipating challenges, and truly understanding the Total Cost of Ownership (TCO) implications for the business. We weren’t just swapping out a technology; we were redefining how the bank’s nervous system communicated.

Scaling Rapidly at Capital One: Microservices and GoLang

Moving to Capital One as a Software Development Manager, I inherited a new challenge: building agile teams to deliver microservices in AWS for the upmarket credit card business. This was a period of rapid evolution, embracing cloud-native patterns and modern development practices.

My hands-on experience became invaluable here, too. When we architected a high-performance microservices layer in GoLang to streamline integrations with fintech startups, I wasn’t just approving designs; I was diving into the code, helping to optimize for speed and concurrency. I remembered the speed difference when we first moved to GoLang for microservices; it was a game-changer for accelerating the bank’s partnership ecosystem. Similarly, when engineering mission-critical Java Spring Boot services for credit card controls, my ability to understand the underlying code and architectural choices helped us deliver real-time restriction capabilities that significantly enhanced risk management. This direct involvement allowed me to better mentor our engineering interns, guiding them through the complexities of event-driven architectures and microservices, helping them deliver real internal communication tooling. It taught me the importance of not just what we build, but how we build it, and the culture we foster in the process.

Innovation at Solace: The Event-Driven Frontier and Beyond to AI

Today, as Vice President of Systems Engineering for the Americas at Solace, my role has expanded significantly – scaling a team 3x, contributing to product strategy, and being a technical evangelist. Yet, the “hands-on” imperative remains stronger than ever.

Here at Solace, I’ve had the unique opportunity to bridge strategy with execution by contributing directly to the delivery of critical connectors (Databricks, Snowflake, GraphQL, DAPR). This wasn’t just architectural guidance; it involved hands-on coding. Why? Because understanding the subtle challenges of integrating with these platforms is crucial for reducing customer friction and expanding our Total Addressable Market (TAM). It gives me an unfiltered view into what our customers truly need and how our platform can best serve them.

My belief in Event-Driven Architecture (EDA) is not academic; it’s rooted in seeing it work at the scale of a global bank and now evolving with Solace. We’re pushing the boundaries beyond traditional message queues, providing superior features like low latency, sophisticated topic routing, and true event mesh capabilities that allow seamless event flow across complex, distributed environments. This is a significant differentiator, especially when compared to other solutions like Kafka, which often requires more overhead for features like low-latency routing and guaranteed delivery across geo-distributed systems.

Perhaps the most exciting frontier where my hands-on philosophy is critical is in leading the Solutions Engineering effort for Solace Agent Mesh. This breakthrough Agentic AI solution demands a deep dive into market analysis, competitive positioning, and product-market fit validation. To effectively scale a specialized team for this next-generation AI infrastructure platform, I need to intimately understand the technical challenges and opportunities. What does it mean for an event mesh to power intelligent agents? How do we ensure secure, low-latency, and reliable communication for truly autonomous AI systems? These aren’t questions you can answer without a solid technical foundation and a willingness to explore the depths of the technology. My passion for building, extending to full-stack interests like SvelteKit and Cloudflare Workers/Pages/R2, and experiments with Rust, ensures I remain technically sharp and connected to the evolving landscape that shapes our products.

Why It Matters: Bridging Strategy and Execution

So, why does this VP still code? It’s about bridging the gap between strategy and execution.

1. Informed Decision-Making: Direct technical engagement allows me to make better architectural and product decisions. I understand the trade-offs, the complexities, and the real-world implications of our choices.
2. Empathy and Credibility: Being hands-on fosters empathy with my engineering teams. I understand their challenges, celebrate their wins, and can offer practical guidance, not just abstract directives. This builds trust and strengthens culture.
3. Faster Problem-Solving: When critical issues arise, my ability to dive into the technical details accelerates troubleshooting and resolution.
4. Identifying Emerging Opportunities: Staying sharp on evolving technologies – from new programming languages to cutting-edge AI paradigms – helps us identify new market opportunities and contribute to groundbreaking solutions like Agentic AI.
5. Leading by Example: It reinforces my philosophy of servant leadership. I’m here to support, enable, and contribute, not just to manage.

The Hands-On Imperative

In a world where technology evolves at an unprecedented pace, the technical leader’s imperative to remain hands-on is not a luxury, but a necessity. From migrating legacy systems at a global bank to architecting the event-driven backbone for future AI, staying technically sharp has been the constant thread throughout my career. It’s how we innovate, how we scale, and how we truly lead in the complex, exhilarating world of engineering. Let’s continue to build, learn, and lead, one line of code at a time.