How I got here
I didn't plan this career.
I started in the Army as an aircraft structural repairman, working on helicopters during the 9/11 era. That environment sets your baseline early. There's no room for "probably fine." Either it's right or it isn't, and someone is depending on that being true.
After that I wrote manuals for a composites manufacturer. Then in 2006 I picked up Ruby on Rails because I needed to build wireless field tools for an industrial controls company. No formal training, no roadmap. Just a problem in front of me and a stack of books.
That pattern stuck. Most of my career has been stepping into things I didn't fully know yet and figuring them out because the system needed to work.
What I actually do
I run technology at SSL.com.
That means owning the full stack of what it takes to operate a publicly trusted certificate authority. Software engineering, PKI operations, infrastructure, security, compliance, and the reality that when something goes wrong, it's not contained to you.
We issue and manage digital identity at scale. Certificates that end up sitting in front of production systems, customer traffic, devices, and increasingly, content itself.
It's not theoretical work. It's production, under audit, with external dependencies that don't care why something failed.
Before this I worked on pharmacogenomics platforms processing thousands of genetic tests a day, where bad data has real-world consequences. I built and scaled email infrastructure where deliverability and uptime are everything. I worked on real-time messaging systems where latency and consistency both matter.
Different industries, same pattern. High throughput, tight constraints, and no patience for systems that only work most of the time.
How I think about the job
At this level, most of the job is decision-making.
What gets built. What doesn't. Where to take risk. Where not to.
But I don't believe in leading from a distance.
I still read code. I still review architecture. I still get pulled into production issues when they matter. Not because I need to be in everything, but because it keeps me grounded in what's actually real.
It's easy to build a narrative about how things are going. It's harder to look at the system and see where it's actually fragile.
Most teams don't fail because they lack talent.
They fail because:
- ownership is unclear
- priorities shift faster than execution can keep up
- or no one is willing to make a call when there's risk
I've seen teams try to solve that with more process, more meetings, more layers. That usually makes it worse.
Clear ownership, a real bar for quality, and the ability to make decisions quickly will outperform most "perfect" processes every time.
My job is to create that environment and step in when things start to drift.
Outside of work
I still like building things you can physically interact with.
Home automation, IoT, amateur radio, trunk recorder setups. Things with signals, hardware, and failure modes you can actually observe.
It's a different feedback loop than software, and it keeps me from drifting too far into abstraction.
I also spent a few years running a youth baseball league. Hundreds of kids, a lot of volunteers, and a constant stream of competing priorities.
Different domain, same problems. Ownership, communication, expectations, and the gap between what people say they'll do and what actually gets done.