Support Rep to VP of Engineering: An Unconventional Path
If you landed on the homepage, you already got the bullet-point version of who I am. This is the longer cut.
Key Takeaways
- The path from support rep to VP doesn't show up in most leadership content, but customer-facing roles build stronger engineering intuition than most people realize
- Small teams of curious people consistently outperform large teams. A Nature study found that teams of three or fewer produce 72% of disruptive innovations (Wu, Wang & Evans, 2019)
- The best risk assessment training comes from outside software: IFR flying, backcountry skiing, and the humility to turn around when conditions say no
How Does a Pilot End Up in Engineering?
Code and spaceflight were always part of the same obsession for me. As a kid I was glued to every NASA launch, every mission transcript, every technical document I could find. Most of that research happened on a BBS hosted at the local library, dialing in on my mom's modem and spending hours reading everything the board had. That's also how I learned what long-distance calling charges were, but that's a story for a different post.
According to the Stack Overflow Developer Survey (2024), 82% of developers learned through online resources. For me, code was never something I "taught myself" in isolation. It was part of exploring everything that fascinated me: how systems work, how missions get planned, how things that absolutely cannot fail get built anyway.
That curiosity led me to aerospace engineering at Parks College at Saint Louis University. People assume I ended up in software despite studying aerospace. I think it's the opposite. Aerospace taught me the most important lessons they don't cover in a CS curriculum: security as a first principle, the discipline to say no when the go/no-go checklist fails, the culture of practice and rehearsal before anything goes live, and rigorous process that treats every failure mode as a design input. Those habits shaped how I build software today.
I got my instrument rating in 2007. Single-engine, FAA certified, the whole thing. If you've never flown IFR, here's what it means in practice: you're in the clouds, you can't see the horizon, and you have to trust your instruments over every instinct telling you to pull up or bank left. Flying IFR was my DevOps training before I knew what DevOps was: deploy quickly, deploy safely, deploy reliably, and always with the passenger in mind. Every preflight checklist, every approach briefing, every go-around decision was practice for the engineering leadership decisions I'd make later.
Why does that matter? Because trusting instruments over instinct is exactly what good engineering leadership looks like. You watch the data. You resist the urge to react to noise. You hold course when the dashboard says you're fine, even when your gut is screaming otherwise.
Before all of that, right after high school, I moved to Madrid. Not for a semester abroad. I just went. I minored in Spanish, eventually reached full professional fluency, and spent formative years in a place that rewired how I thought about culture, communication, and what it means to actually listen to someone in their own language. That experience quietly shaped everything I've done since.
How Did Customer Support Become an Engineering Career?
I always knew I had the DNA to be an engineer. The curiosity was there, the systems thinking was there, the obsession with how things work was there. I just needed someone to give me a chance. My first role at Wix was answering support tickets, and that turned out to be exactly the right place to start.
Not because support is a stepping stone. Because I needed to learn the business. I needed to understand scale: what 250 million users actually means for a product, how customers think, where things break when they break at scale. Support taught me all of that faster than any engineering onboarding could have.
From there I moved into QA, then team lead, then Head of Engineering, eventually leading successful engineering and QA teams building tools for a massive user base. Nearly a decade at Wix, and the most important thing I learned wasn't technical. It was that the people closest to the customer usually understand the problem better than anyone in the room with a whiteboard.
Have you ever noticed how the best product decisions come from people who've actually talked to users? That's not a coincidence. It's a pattern I've seen repeat across every team I've built.
What Does Building From Zero Actually Look Like?
Research published in Nature found that small teams of three or fewer produce 72% of disruptive innovations, while larger teams tend to refine existing ideas (Wu, Wang & Evans, 2019). I've lived that finding firsthand, building a startup org from nothing and watching a handful of people outperform what most assumed required an army.
In 2020, Wix spun out a product I'd helped build into a separate company called Wix Answers. TechCrunch covered the launch, and I found myself quoted as a "product solutions expert" explaining the platform to Anthony Ha. Surreal moment. Seeing something you poured years into suddenly become a thing with its own name and press coverage.
But it also clarified something for me: I wanted to build from zero, not iterate on something already at scale.
That's what brought me to Marqii. I joined as VP of Engineering and Product Development with a mandate to build the entire product, engineering, and design organization from scratch. Zero to twenty people across three functions, reporting to the CEO.
We led a strategic pivot from a private-labeled, resold product to an owned platform. That's the kind of architectural bet that keeps you up at night until the retention metrics prove you were right.
We shipped AI-powered features (automated review response, location intelligence, market discovery) back when "we're using LLMs" still raised eyebrows in board meetings. We rebuilt the infrastructure from serverless to Kubernetes. We built our own data platform and ETL tooling in-house. We grew the business by multiples in a few years.
None of that happened because of a brilliant strategy deck. It happened because we hired curious people, gave them ownership, and got out of their way.
I learned early that a small team of curious people will outrun a large team of checkbox-fillers every time. Engineering is a business lever. If your engineering org isn't driving outcomes, something is structurally wrong, and no amount of process will fix it.
Source: Wu, Wang & Evans, Nature, 2019
What Do IFR Flying and Backcountry Skiing Have in Common?
Gallup research shows that employees at smaller organizations report higher engagement than those at large companies (Gallup, 2016). I think the same principle applies to risk assessment: small-scale, high-stakes environments teach you more about decision-making than any corporate training program ever could.
I'm AIARE certified in Wilderness and Remote First Aid. That's a fancy way of saying I spend enough time in avalanche terrain to need formal training on what to do when things go sideways.
Most winter weekends you'll find me skinning uphill somewhere in the Sierra before sunrise, earning my turns the hard way. There's a through-line between flying IFR and backcountry skiing that I think about a lot: both demand honest risk assessment, preparation that borders on obsessive, and the humility to turn around when the conditions say no.
Does that sound like engineering leadership? It should. Every decision to ship or hold, to scale or wait, to hire or reorganize requires the same honest self-assessment. Can I trust the data I'm looking at? Have I prepared enough? Am I making this call because it's right, or because it's comfortable?
Thanks for reading. More soon.